IPSec Tunnel with NAT configuration

[nitesharbale]

Hello Experts,

I am new to PA and trying to understand how below can be achieved. I am trying to set up IPSec tunnel between checkpoint and PA.

Diag:

I want to establish a IPSec tunnel between CP and PA. On PA side i have 172.16.0.0/24(inside zone) private IP range which i want to NAT to 10.172.0.0/24 and send it to CP side as intresting traffic. I have Phase1 and 2 configuration ready(PSB snap attached)

But i am not sure how to configure routing as 10.172.0.0/24 & 1.1.1.1 is not associated to any of my interface. Do i need Null 0 route ?

Furthermore do i really need to configure seperate zone & IP address for tunnel?

The same scenario i found here :https://live.paloaltonetworks.com/t5/general-topics/nat-over-ipsec-tunnel/td-p/399619

but i didn't understand much.

It would help me to understand and study further if someone could help me provide the config pls.

Current Route Table:

Global Protect IPSec Crypto:

IKE Gateway:

IPSec Crypto:

IKE Crypto:

Thanks

[upelister]

Hello,

- İs tunnel up? (P1 and P2)

-what kind of vpn messages in logs?

-CP is Policy based routing type but Palo Alto is Route Based (Without PBR);

PA Side;

--Palo Alto NAT ip pool range should be in Palo Alto VPN Config>Proxy id as local.

--CP NAT ip pool range should be in Palo Alto VPN Config>Proxy id as remote.

--CP NAT ip pool range should be in Palo Alto Virtual router>Static Routes, for destination interface related tunnel interface next hop should be CP if ip.

info:

---you do not need to assign ip address to tunnel interfaces every time.

--- For my enviroment, i am using NAT in many vpn tunnels because adding an ip address to CP encryption domain sometimes fails tunnel.               (couses Proxy-id mismatch error)

İ mean stright foward s2s tunnel config but both firewall need to know only NAT ip addresses instead of actual ip addresses. Bu setting up with CP another challlange wish you luck.

İf tunnel is working 100% than go to policy tab;

Create Security Rule. 

Create destination NAT rule.

İf you are new i suggest start with basics and get familiar with log messages.

I hope this helps and have a nice day.

[aleksandar.astardzhiev]

Hi @nitesharbale ,

- Assigning IP address to tunnel interface is optional and really only required if you plan to use dynamic routing or path monitor through the tunnel. If you don't need such you can remove the tunnel address.

- Also usually you don't need to specify local and remote id in the IKE Gateway config. If you don't specify anything by standard firewalls will use their IP addresses. You must specify local/remote id, only if you plan to use hide/dynamic NAT for any of the peers

- I would suggest you to create a route on the Palo Alto for 10.172.0.0/24 pointing to tunnel interface and no next hop. You can live without such route, but your NAT rule will look much better if you do, and I will try to explain below.

- When configuring NAT you need to remember that for the original packet you need to specify source and destination before the nat. Because when packet hit the firewall and it is checking if it should apply NAT or not, it will check its routing table to decide what is the destination zone.

    - For traffic palo_lan to cp_lan it is easy: source zone will be the lan/inside and destinatifwon zone will be the zone associated with your tunnel interface (assuming you already have static route for remote network pointing to the tunnel interface (just the interface no need for next-hop address)

    - For traffic cp_lan to palo_lan, as you said such 10.172./24 is not on any interface, but FW will still perform route lookup to check which zone to use as destination. If there is no specific route it will match the default and it  will associate this traffic with destination zone outside (following your default route). I notice that you have 10.172.0.0/16 with discard...I am not sure what will happen in this case but I am suspecting that traffic will be dropped.

    - So as I mentioned earlier it is good idea to create a route for palo nat network - 10.172.0.0/24 pointing to your tunnel interface. That way you can create NAT rule with source AND destination zone IPsec tunnel (remember before the nat the source and destination address of the packet coming from checkpoint are pointing to the tunnel, based on the routing

--- I would also suggest to use separate zone for each IPsec tunnel. This gives you more flexibility when comes to the NATting. That way you can use the bi-direction feature and create single static NAT rule. FW will apply the second rule automatically. - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWBCA0 

So you can configure NAT rule with:

Original: source zone: lan; dest zone: vpn_tunnel: source ip: 172.16.0.0/24; dest ip; 10.192.0.0/24

Translated: source static: 10.172.0.0/24

FW will automatically create the second rule:

Original: source zone: any; dest. zone: vpn_tunnel; source ip: any; dest. ip: 10.172.0.0/24

Translated: destination static: 172.16.0.0/24 

[nitesharbale]

@aleksandar.astardzhiev @upelister  Thankyou for taking out your precious time.

I have made required changes. I have Phase 1 & 2 setting same on CP, still tunnel is not up. Underlay routing is also in place.

I am checking on CP community as well. Just wanted to know do i need any other changes on PA ?

10.168.1.0/24 --> NAT Subnet of CP side. (Original Subnet: 192.168.1.0/24)

10.172.0.0/24 -->NAT Subnet of PA side   (Original Subnet: 172.16.4.0/24)

ROUTING TABLE:

Tunnel is Still not up

Interfaces & Zone:

IKE Gateway:

Phase 1:

Phase 2:

NAT Policy:

Security Policy:

Thanks

[aleksandar.astardzhiev]

Hi @nitesharbale ,

- Your local proxy ID is wrong. You need to use the local NAT range for local proxy ID as well as remote NAT for remote proxy-id.

- However it is strange that phase1 is down (proxy-id should affect phase1 only phase2). So I am wondering if there was any traffic (with no traffic trying to pass the tunnel, both firewalls will not trigger negotiation).

    - Palo Alto firewalls have great CLI command that will trigger tunnel negotiation, that way you can isolate the IPsec config and see if it work, and if it is you can focus on nat, rules and routes.

    - Run the following command (use the auto-complete to fill the tunnel). I would suggest you to test all proxy-ids in the tunnel.
    > test vpn ipsec-sa tunnel <name-of-tunnel>:<name-of-proxy-id1>

    > test vpn ipsec-sa tunnel <name-of-tunnel>:<name-of-proxy-id2>

Above will test phase2 which automatically will try to bring phase1. I prefer to use this one, as you can test both phases with single command. Note the test commands will not generate any output, they will simply initiate tunnel negotiation. After that you can check the GUI if any of the phases is green or they are still down.

- If any of the phases is still down after the test command, I would suggest you to try negotiate the tunnel from the Checkpoint side. The reason is that when peers are failing to negotiate the settings, always the responder will have more detailed logs for the reason why it is failing. If you trigger traffic behind the Checkpoint that will trigger tunnel negotiation you can check Palo Alto logs to see what is the reason. The easiest way is to check System logs under the GUI, but if that is not enough you can check this article to see more detailed logs under CLI - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC 

- I haven't work with Checkpoint in a while, but I remember there was something stupid like - you need to put the original and natted local network (behind CP) in the local encryption domain. 

[nitesharbale]

@aleksandar.astardzhiev local proxy changed now to local and remote NAT, no luck.

https://pdf.ac/rbySN   URL contains .docx file which has CP and PA configs.

Thankyou

[aleksandar.astardzhiev]

Hey @nitesharbale ,

As I mentioned - if you have problems with phase1 fixing the proxy-id will not make any change (you still had to fix those, otherwise you will have problems further with phase2). So what about my other suggestions:

- Have you run the test commands?

- Have you tried to trigger the vpn from the checkpoint and check palo alto logs?

[nitesharbale]

On PA after issuing this command tunnel seems up. 

PHASE1:

PHASE2:

ON CP (below output is when i initiated tunnel from PA)

SITEA-GW> vpn tu

********** Select Option **********

(1) List all IKE SAs
(2) * List all IPsec SAs
(3) List all IKE SAs for a given peer (GW) or user (Client)
(4) * List all IPsec SAs for a given peer (GW) or user (Client)
(5) Delete all IPsec SAs for a given peer (GW)
(6) Delete all IPsec SAs for a given User (Client)
(7) Delete all IPsec+IKE SAs for a given peer (GW)
(8) Delete all IPsec+IKE SAs for a given User (Client)
(9) Delete all IPsec SAs for ALL peers and users
(0) Delete all IPsec+IKE SAs for ALL peers and users

* To list data for a specific CoreXL instance, append "-i <instance number>" to your selection.

(Q) Quit

*******************************************

1

Peer 10.12.1.1 , SITEB-PA-GATEWAY SAs:

IKE SA <3b9a97149bc884dd,edfb6f9b1501ee78>

2

SAs of all instances:

Peer 10.12.1.1 , SITEB-PA-GATEWAY SAs:

IKE SA <1586026f8eeeba33,bdafb0a3bbc94399>
(No IPSec SAs)

But ping didn't work from either end.

[aleksandar.astardzhiev]

Hi @nitesharbale ,

That is good news, this means that VPN settings are good, and now you need to focus on NAT, route or rule.

I was looking again at your screenshots I and for me the route, nat and rule on the palo alto are fine. This means you should see at least "pkt encap" counter to increase in the details for phase2.

Remember that you can statically NAT the whole /24 network, as long as the orignal network is the same size as the translated source. I noticed that you have natted only one host.

- If you try to send ping from the DMZ network behind the palo alto: do you see traffic logs? can you show the details? what about the "pkt encap", does this counter increase? pkt encap will show the number of packets that firewall has encrypted/encapsulated and forward through the tunnel. If you ping from the correct source (the one from the nat rule) you should see this count increasing, and if pkt dencap is not increasing this means that something is wrong with checkpoint and there is no return traffic.

By the way I noticed that you don't have rule for allowing traffic from the tunnel to the DMZ. You still should see pkt dencap counter increasing if traffic from checkpoint is entering the tunnel, even if you don't allow the traffic, but  you need to check what rules do you need - which side of the tunnel will be the initiator of the tunnel (you only need rule in both directions only if you expect each side of the tunnel to be able to initiate connection)

[nitesharbale]

@aleksandar.astardzhiev 

I was looking again at your screenshots I and for me the route, nat and rule on the palo alto are fine. This means you should see at least "pkt encap" counter to increase in the details for phase2 ---> I made few changes in security policy and NAT rule. PSB

NAT RULE: i am initiating traffic from both end so i configured below rule

 If you try to send ping from the DMZ network behind the palo alto: do you see traffic logs? can you show the details? what about the "pkt encap", does this counter increase? --> I dont see any packet encap/decap counter increasing, so first i checked if PA can reach DMZ server or not and yes it is able to ping.

admin@SITE-B-FIREWALL> ping source 172.16.4.254 host 172.16.4.10
PING 172.16.4.10 (172.16.4.10) from 172.16.4.254 : 56(84) bytes of data.
64 bytes from 172.16.4.10: icmp_seq=1 ttl=64 time=0.916 ms
64 bytes from 172.16.4.10: icmp_seq=2 ttl=64 time=0.827 ms
64 bytes from 172.16.4.10: icmp_seq=3 ttl=64 time=0.902 ms
64 bytes from 172.16.4.10: icmp_seq=4 ttl=64 time=1.00 ms
64 bytes from 172.16.4.10: icmp_seq=5 ttl=64 time=0.715 ms
^C
--- 172.16.4.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.715/0.873/1.008/0.103 ms

While i was pinging from DMZ server(172.16.4.10 to NAT IP of CP side 10.168.1.1, which i was unable to ping) , i dont see any packet encap/decap counter increasing not any security logs as well. Do i need to reconfigure NAT rule if packet encap counter not increasing ??

[aleksandar.astardzhiev]

Hey @nitesharbale ,

 - You actually don't need the new NAT rule you have created (from vpn to dmz). This is already covered by the "bi-directional: yes" on the second rule. When you enable bi-directional, firewall will automatically create nat rule for traffic from cp to palo. This rule is not visible in the config, but if you check the with CLI commant > show running nat-policy, you will see it

- If you don't see traffic from the DMZ hitting the firewall (when pinging CP network) it sounds like traffic is not reaching the firewall at all. I believe your NAT is fine, try to traceroute and check routing table on the 172.16.4.10 and confirm that it will send the traffic to the pan fw, when it is trying to reach the cp nat network

[nitesharbale]

@aleksandar.astardzhiev Sorry there is misconfigured def gw on pc.

I am almost close to achieve this now.

On CP it is dropping. I am going through their post related to below issue and hope to find solution soon.

Though traffic reaching to CP, but NAT hits are not increasing

Thanks

[aleksandar.astardzhiev]

My Checkpoint is bit rusty, but it maybe caused by overlapping encryption domains.

It definately have something to do with the NAT - I have never liked how Checkpoint is doing VPN...really hate it.

Have you tried to run this - https://community.checkpoint.com/t5/Security-Gateways/One-liner-to-show-VPN-topology-on-gateways/td-...

[nitesharbale]

Have you tried to run this - https://community.checkpoint.com/t5/Security-Gateways/One-liner-to-show-VPN-topology-on-gateways/td-...   -->No i am afraid to run that, all my configs and troubleshooting done along with you guys would go in vain. And have to start new troubleshooting on CP if any thing goes wrong after running this command.

[aleksandar.astardzhiev]

@nitesharbale,

You can trust the code from the checkpoint community link. As described it will only show the encryption domains but it more readable format. The author of the one-liner is trustworthy and have lots of years of experiance with Checkpoint.

However if you don't want to run it, I can understand you.