DNAT over IPSec-VPN Tunnel

[pronet]

Hi folks,

we are using some Fortinet products since we find them great..

Now we are trying to accomplish the following project (see attached picture):

From ISP1, the incoming HTTPS packets to FW1 should travel across the VPN to the server on the opposit site, called "beta".

So we have to DNAT incoming HTTPS packet from 1.1.1.1 to 192.168.1.2.

What works for now (DNAT without crossing the VPN tunnel):

First case - Site A: Client connects from the Internet over the external IP 1.1.1.1, on port 443 (HTTPS), and is DNAT to 192.168.0.2:443 Incoming Packet flow: WAN-FW1 (1.1.1.1) ==> 192.168.0.1 ==> 192.168.0.2 (using VIP), this is OK. First case - Site B: Client connects from the Internet over the external IP 2.2.2.2, on port 443 (HTTPS), and is DNAT to 192.168.1.2:443 Incoming Packet flow: WAN-FW2 (2.2.2.2) ==> 192.168.1.1 ==> 192.168.1.2 (using VIP), this is OK.

What should work (DNAT crossing the VPN tunnel to the other side):

Second case - Site A: Client connects from the Internet over the external IP 1.1.1.1, on port 8080 (HTTPS), and is DNAT to 192.168.1.2:8080 Incoming Packet flow: WAN-FW1 (1.1.1.1) ==> IPSEC-Tunnel ==> 192.168.1.1 ==> 192.168.1.2

Second case - Site B: Client connects from the Internet over the external IP 2.2.2.2, on port 8080 (HTTPS), and is DNAT to 192.168.0.2:8080 Incoming Packet flow: WAN-FW2 (2.2.2.2) ==> IPSEC-Tunnel ==> 192.168.0.1 ==> 192.168.0.2

So, the packets should be "cross-routed".. this will be like a "external failover" mechanism. In the second case, using the same approach (with a "virtual IP" from the remote subnet) is not working. Fortigate is using the wrong src-address..

Using the internal debug flow function, we can log some "SNAT" records which belong to the DMZ IP-address (10.10.10.1)..?

This is very strange for us..

Is there a possibility to configure this behaviour in a correct way, since it is not running like expected.

-- trace from FW1 --
id=20085 trace_id=239 func=print_pkt_detail line=4793 msg="vd-root received a packet(proto=6, 79.24.20.67:54512->1.1.1.1:443) from ppp1. flag , seq 2283187442, ack 0, win 17520"
id=20085 trace_id=239 func=init_ip_session_common line=4944 msg="allocate a new session-004dba41"
id=20085 trace_id=239 func=fw_pre_route_handler line=182 msg="VIP-192.168.1.2:443, outdev-ppp1"
id=20085 trace_id=239 func=__ip_session_run_tuple line=2810 msg="DNAT 1.1.1.1:443->192.168.1.2:443"
id=20085 trace_id=239 func=vf_ip_route_input_common line=2586 msg="find a route: flag=00000000 gw-10.1.1.6 via FW1-FW2_VPN"
id=20085 trace_id=239 func=fw_forward_handler line=697 msg="Allowed by Policy-8: SNAT"
id=20085 trace_id=239 func=__ip_session_run_tuple line=2796 msg="SNAT 79.24.20.67->10.10.10.1:54512"
id=20085 trace_id=239 func=ipsecdev_hard_start_xmit line=157 msg="enter IPsec interface-FW1-FW2_VPN"
id=20085 trace_id=239 func=esp_output4 line=859 msg="IPsec encrypt/auth"
id=20085 trace_id=239 func=ipsec_output_finish line=498 msg="send to 2.2.2.2 via intf-ppp1"
-- trace from FW1 --

Thank you in advance!

[emnoc · Accepted solution]

I've done exactly what your doing in the past but replace  the  ipsec-vpn-tunnel with a ethernet-link. The problem is going to be that that you need to  change the  SRC of the client to a address within the originating  DataCenter.

This will ensure the  return traffic goes back to that  DC and FW. You made a nice diagram, so I drafted a 10k foot view of what we did using aboundary vdom that terminates our inter-DC-links

enjoy

Ken

[pronet]

Hi Ken,

thank you for your reply..

Sorry - but, how could we configure that on our Fortigate? 

Thanks in advance!

[emnoc]

No different than any other DNAT. The  route-based vpn is a interface the DNAT doesn't carry that the realserver is here or there. The traffic will follow the route-table, if you need to change the  DNAT client address, define a ip_pool and apply that on the firewall-policy for the DNAT.

We use this on the egress side leading to  the cross-ethernet-connection to the other DATACENTER in the 2nd VDOM.