Problem with routing of NATted reply packets over IPSEC tunnel

[djr]

I have an IPSEC tunnel to another organisation, they have two endpoints at the other end on addresses which conflict with our networks.  We can just focus on one to keep it simple.

• We have an IPSEC tunnel set up and passing traffic fine (tunnel.3 interface on the untrust zone).
• The external endpoint’s native address (at the other end of the tunnel) is 172.31.40.40 and I source NAT their traffic into 172.16.12.5 so it doesn’t clash on our network.
• I have a static route to 172.16.12.0/27 with the next hop as the tunnel.3 interface (unnumbered)
• I can see that route propagating through our network (statics are redistributed via OSPF)
• I can see inbound packets from 172.31.40.40 being NATted to 172.16.12.5 so that's working

--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
172536 ping ACTIVE FLOW NS 172.31.40.40[578]/untrust/1 (172.16.12.5[578])
vsys1 172.17.5.17[49784]/trust (172.17.5.17[49784])

• I can see these packets hit the server and responses being sent
• I can see the responses hitting the firewall (S:172.17.5.17, D:172.16.12.5)

Then it all goes dark – the responses are not received by the endpoint and they say they can’t see them ingressing their firewall on the tunnel.

So I can’t work out what is missing, but I suspect the routing.  My route is for the NATted address of the endpoint and that is pointing at the tunnel.

According to the Palo documentation, returned packets (i.e. packets matching a session) are un-NATted before they get forwarded which suggests that the firewall would needs a route to the native address of the endpoint, but if I create a static route to their endpoint’s real address, then that will clash with that address on my network and NAT becomes pointless.

[aleksandar.astardzhiev]

Hi @djr ,

You need to move he NAT at the other end of the tunnel. As you correctly concluded - the static route pointing to the tunnel (for the return traffic to take correct path back), should not match your internal network.

So:

- The NAT 172.31.40.40 -> 172.16.12.5 should be applied on the other end of the tunnel

- Which means that you also have to change the remote proxy-id to match the already nat-ed network

- Not sure how your rule is configured, but review it as well and update it to use the nat-ed address

- Keep the static route for 172.16.12.0/27 pointing to the tunnel

I would also recommend you to use different zone for the VPN tunnel interface. From the output below I believe you are using the "untrust" zone for the vpn tunnel, which probably is the same zone for the firewall outside interface. If you configure ipsec tunnel to use separate zone can be benefitial for simpler NAT configuration (ex. you will not need NO-NAT rule for traffic sourced from your lan to the tunnel)

[Regana]

Hi,

I would like to establish a ipsec site-to-site vpn GATEWAY between my home office and a remote site.

home: FortiGate 50E device v5.6.3, connection: LTE natted with private dynamic ip assigned remote: FortiGate-VM64 v5.4.6, connection: 1 GB with static IP

I would like my home device to connect to the remote VM unit, Allowing certain traffic to run through that VPN connection, using it as its gateway. Example: run all traffic from internal IP 10.0.0.30 through this VPN tunnel (purpose: avoiding geoblocking)

Can someone please help me to get this up and running? I am Cisco CCENT certified, currently studying for the CCNA SEC, So I am trying to get this up and running.

question: how do I set this up?

Your help is very appreciated.

[djr]

Thanks @aleksandar.astardzhiev, I had already asked the company at other end to do the source NAT but they are saying they don't want to do it.  The more I look at it, the more I agree with you that it should be a very simple NAT policy for them to source NAT as the packet egresses on the tunnel interface.

I am surprised that the Palo looks to its standard routing after NAT for this, as it does mean it can't work without the route at my end, but I guess source NAT on arrival of a packet is unusual as it is usually done on egress.  It would have worked if PANOS used the session table to route, or if they routed first then NATted, but I guess they have their reasons.

Thanks for your help