Ipsec Vpn with NAT'ed partner gateway

[costerbrink]

Hi folks,

we are already running several ipsec vpn successfully, but now we have a problem.

the partner gateway nat their internal networks due to ip conflicts to the external public ip address of the vpn gateway (which works on a checkpoint gateway without any problems).To move it to the PA5050 I configured the external IP as gateway ip and as the regarding proxy id along with our internal destination network.

phase1 and phase2 went up successfully but I can see no traffic passing. When I take a paket capture in the receive layer, i see both the encrypted esp paket and the decrypted original paket.  When I make a capture in the drop layer I can see the decrypted pakets beeing dropped. No entries in any palo logfiles for this, only the paket capture.

if I route the external partner ip address explicitly in the corresponding tunnel-interface the pakets get decrypted and appear in the policy log but the phase1 sa's get instantly deleted because I assume that all traffic including the ike/ipsec traffic are routed to the tunnel interface and gets dropped.

so, is anybody out there running such a scenario that the partner network is nat'ed behind the partners vpn gateways' ip address?

regards,

Christian

[pkruse]

Please look at the attached file and tell me, is this the setup your describing?

If yes there is not a good reason for dropped packets originating from or destine for the broadcast domain local to your inside interface. Configuration would be the logical area to review and viewing the system logs may reveal any proxy id issues. If you are unable to resolve this problem in a timely manner on your own I would direct you to open a case with support so that can help you resolve your problem quickly and efficiently.

Thank you,

Phil

[costerbrink]

Hi Phil,

thanks for your answer. The scenario ist not exactly what you describe in the attached picture.

regarding the picture, the gateway b on the right hand side  is hiding the network b behind its public ip address. So the gateway ip is also the ip for the proxy id.

Unfortunately the gateway b is only able to NAT behind the public address and on our Checkpoint this works without any problem.

- phase1 and phase2 come up successfully which means that gateways talk to each other and proxy id's do match

-the ipsec tunnel is assigned to a tunnel interface

- the tunnel interface is assigned to a zone and the zone is assigned in a security rule to allow traffic from the "vpn" zone to the internal system in network A (btw there is no more nat in network a).

- I can see the encrypted esp paket and the decrypted paket in a paket capture in the recieve layer

- although there is a security rule, the decrypted paket gets dropped silently (I can see the decrypted paket in a capture in the drop layer).

we already discuss this problem with our distributor who will open a ticket, but currently we are still discussing some aspects of how gateways treat ipsec traffic....

I asked here in the knowlwedge point because we can't believe that nobody other in the paloalto community isn't  using such a scenario. It is quite common that internal networks collide for vpn usage. So the most simple solution is to nat the initiator network behind their unique public address and than encrpyt these nat'ed pakets in an ipsec tunnel....

regards,

Christian

[msiegel]

Christian,

Sorry this post may come a little late, but perhaps someone else will find it useful.

If you are NATing to the outside interface of the Palo Alto, it's a simple static NAT.  It works across the tunnel fine. However, in the scenario you describe the remote end is doing the NATing.  To get this to work you must use Policy Based Forwarding.  Essentially, you want the IPsec traffic to follow your default route out to the Internet, however you want IP addresses in the tunnel to go across the tunnel.

So use PBF with the local proxy ID in source, remote proxy id (remote gateway in this case) in destination and then set Forwarding to push it out the tunnel interface.

cheers,

-Mike