Problem with routing of NATted reply packets over IPSEC tunnel

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem with routing of NATted reply packets over IPSEC tunnel

L4 Transporter

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 and I source NAT their traffic into so it doesn’t clash on our network.
  • I have a static route to 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 being NATted to 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[578]/untrust/1 ([578])
vsys1[49784]/trust ([49784])


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

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.



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.



- The NAT -> 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 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)

L0 Member


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 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.

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

  • 3 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!