09-02-2021 10:41 AM
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.
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 & 22.214.171.124 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:
09-13-2021 08:24 AM
Hey @nitesharbale ,
I belive this could be caused by the supernetting that I mentioned
- When Palo Alto initiate the tunnel, for phase2 negotiation it will use the network as you have configured them in the proxy-id and Checkpoint will accept that
- But when Checkpoint is initiating the tunnel it is possible that it will try to use a supernet, which is different from what Palo is expecting and it will not accept the proposal.
First you should confirm this by looking at the system logs on the Palo - as it is reponder you should see some explanation why it is failing. If Monitor -> System Logs are not providing such information you can try run a vpn debug on the Palo
- Here you can see how to enable debug for single VPN peer (which you should always to in real life) - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcKCAS
- And here you can see some other commands that can use to troubleshoot vpn. From here you should check where the debug output is located and how to read it. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC
The debug output can be overhelming, but you should be able to see somewhere between the lines what is sent by the Checkpoint.
If my assumtion is correct and you see different range for local or remote encryption you may need to look at how to override this supnetting
09-03-2021 10:46 PM - edited 09-03-2021 10:47 PM
- İ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);
--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.
---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.
09-04-2021 02:48 PM
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
09-06-2021 04:08 AM
@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)
Tunnel is Still not up
Interfaces & Zone:
09-06-2021 01:28 PM
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.
09-07-2021 10:59 AM
@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.
09-07-2021 10:57 PM
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?
09-07-2021 11:24 PM
On PA after issuing this command tunnel seems up.
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.
Peer 10.12.1.1 , SITEB-PA-GATEWAY SAs:
IKE SA <3b9a97149bc884dd,edfb6f9b1501ee78>
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.
09-07-2021 11:53 PM
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)
09-08-2021 01:09 AM
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
--- 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 ??
09-08-2021 01:18 AM
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
09-08-2021 02:01 AM - edited 09-08-2021 02:11 AM
@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
09-08-2021 02:16 AM
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-...
09-08-2021 02:46 AM
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.
09-08-2021 03:30 AM
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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!