- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-02-2021 10:41 AM
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
09-08-2021 03:38 AM
Below is what i got
Info: VPN Domain for Gateway Communities are currently not displayed correctly by this tool!
VPN Gateway > 10.12.1.1
Encryption domain
10.12.1.1 - 10.12.1.1
10.172.0.0 - 10.172.0.255
VPN Gateway > 192.168.1.1
Encryption domain
10.11.1.0 - 10.11.1.0
10.11.1.1 - 10.11.1.1
10.11.1.2 - 10.11.1.63
192.168.0.253 - 192.168.0.253
192.168.1.0 - 192.168.1.0
192.168.1.1 - 192.168.1.1
192.168.1.2 - 192.168.1.255
Info: VPN Domain for Gateway Communities are currently not displayed correctly by this tool!
[Expert@SITEA-GW:0]#
09-08-2021 05:03 AM
You can try to add the CP local NAT network to the local encryption domain And check again.
09-08-2021 09:15 AM
@aleksandar.astardzhiev Finally it is working now. Checkpoint is really tricky.
On CP i added both local and original subnet under object group
Thankyou very much for helping and making me this understand. On youtube i found simple S2S vpn. This LAB helped me understand the concept in much better way.
09-08-2021 11:01 AM
Hey @nitesharbale
Great! Yeah I really hate working with VPN and Checkpoint... they do lot of unnecessary complications.
And other hand VPN is one of the main reason I love Palo Alto, tunnel setup is straight forward and really easy to understand the concept.
By the way you definately need to check:
- By default Checkpoint is doing "super-netting" which could breat phase2 negotiation. For example if you have couple of /24, CP will automatically start using /16 or /8 which will cover all subnets with all peers, no matter.
- In previous version CP was defining the local encryption domain globaly for the firewall, and it was using all local networks for all peers. For example if you want one tunnel to use only local 10.10.10/24 and another tunnel to only use 10.10.20.0/24 - CP will allow both peers to negotiate for both networks. They have finally fix this... but I am not very familiar with this - https://www.youtube.com/watch?v=X0O7Z6mJXwY
Keep learning!
09-08-2021 11:41 AM
@aleksandar.astardzhiev Thankyou.. though the issue is not completely resolved. Ping from PA to CP worked fine, but CP to PA is failing. I have static NAT (like i did in PA) and have correct security policy as well. phase 2 shows like this.
2
SAs of all instances:
Peer 10.12.1.1 , SITEB-PA-GATEWAY SAs:
IKE SA <fef1591def15bc75,e45b67b52d88ed60>
(No IPSec SAs)
[Expert@SITEA-GW:0]# fw ctl zdebug + drop | grep "10.168.1.1"
@;45251;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=1 10.168.1.1:2048 -> 10.172.0.10:50919 dropped by fw_ipsec_encrypt_on_tunnel_instance Reason: No error - tunnel is not yet established;
@;45251;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=1 10.168.1.1:2048 -> 10.172.0.10:676 dropped by fw_ipsec_encrypt_on_tunnel_instance Reason: No error - tunnel is not yet established;
@;45252;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=1 10.168.1.1:2048 -> 10.172.0.10:27231 dropped by fw_ipsec_encrypt_on_tunnel_instance Reason: No error - tunnel is not yet established;
@;45252;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=1 10.168.1.1:2048 -> 10.172.0.10:59929 dropped by fw_ipsec_encrypt_on_tunnel_instance Reason: No error - tunnel is not yet established;
I am waiting for their reply and let me see what new comes up in checkpoint now to resolve this.
Again thanks for the help sir.
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-13-2021 12:35 PM
@aleksandar.astardzhiev Finally after a week of troubleshooting, it started working. Thanks for your valuable suggestion, it wont be possible without your help.
I will put the changes i made in steps below, so that it would help other folks as well.
First read 4-B here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut.... Below are snaps.
Step 1:
changed from "true to "false"
Step 2: changed to false
Step3: changed to false
On PA: Go to Network TAB-->IPSec Tunnel-->Open the tunnel-->inside proxy ID i defined 200.1.1.1(PA local NAT IP, earlier it was 10.172.0.0/24, while troubleshooting i changed to 200.1.1.x) and remote as 10.168.1.1(CP IP). Earlier it was whole subnet i.e 200.1.1.0/24 and 10.168.1.0/24
@aleksandar.astardzhiev because i have static nat, do i always need to define /32 as proxy ID ?
Thanks
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!