IPSEC site to site, virtual IP routing special problem

Question

Hi,maybe someone has an idea, me not, anymore. :( Setuplan port 1, net 172.31.0.0/16 (NAT)|(site 1) Fortigate, WAN with public IP (fiber connected)|IPSEC site to site|(site 2) Fortigate, WAN with public IP (fiber connected)|lan port 1, net 10.20.20.0/24 (NAT) Working / Details- IPSEC is working fine without any bigger problem so far- no additional modem / router is between, because of fiber-connection- computer from site 1 from lan-segment can access computer on site 2 in lan-segment- all policys to route networks 172.31.0.0/16 and 10.20.20.0/24 between the tunnels are setup by the wizard and working well Non-Working- Fortigate CLI on site 1 or site 2 is not able to ping Fortigate on other site, this is quite normal, because PING is disabled on this interface, however, Fortigate is not able to ping any computer in lan-segment on the other site What I want to- On site 1 I want to setup a public IP on my WAN interface, using one of the ip-addresses out of our public network, to setup a virtual server, or IP forwarder over NAT to access a computer on site 2. This is because of many IP addresses we have on site 1, but not on site 2. Normal virtual server or IP forwarder on site 1 is working, if destination is inside lan 1 (172.31.0.0/16). It does not work using a destination on site 2 from lan 10.20.20.0/24. Is this caused by the non-working-problem mentioned above? Or is it kind of routing problem, because site 2 is not knowing how to route back to source public ip from site 1? Any help would be nice from you.Best and thanksRonny

Toshi_Esumi · Answer

Two different issues. But you could have figured out when you used the same troubleshooting method: sniffing (diag debug sniffer packet ....)

1. when you pinged from FG-1 to Site-2-Device, it likely picked the tunnel (phase1) interface IP on FG-1 as its source IP, which you most unlikely specified in Phase2 traffic selector combinations. So ping must have reached Site-2-Device but FG-2 dropped the ping-reply.

2. Similar to No.1, I'm assuming the default route at FG-2 is not pointing into the tunnel to get to Site-1. The inbound packets coming through the DNAT you configured still has the same source public IP you're accessing from. It must have been reaching the Site-2-Device. But returning packets try going out toward the internet source via FG-2, which would be dropped there due to asymmetric routing.

I don't have a definitive solution if you can't change the default route at FG-2. Probably adding a SNAT in addition to DNAT to the policy would mitigate, but I haven't tried before. Somebody else might be able to chime in.

Again, you would see all of these when you sniff it at FG-2 and FG-1. Don't forget to disable asic-offloading at your policies if your FG model is equipped with asics. Otherwise, sniffing might not catch any packets through the encrypted tunnel.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded