This article describes scenarios if there is a requirement to forward internet traffic for a specific subnet over an IPsec remote tunnel.
Scope
FortiGate.
Solution
Step 1: It is necessary to create the site-to-site VPN tunnel between two sites。
Step 2: Define the IP address on the created site-to-site VPN tunnels to forward traffic using a remote site IPsec gateway.
Site B:
Tunnel configuration.
Tunnel name: remote.
Tunnel IP: 172.16.10.1/32 and Remote IP 172.16.10.2/32.
Note: make sure to include the gateway IP in phase 2 selectors of the tunnel to allow traffic.
Site A:
Tunnel configuration.
Tunnelname: internet.
Tunnel IP: 172.16.10.2/32 and Remote IP 172.16.10.1/32.
In the below example, it is desired to forward the specific subnet traffic 192.168.20.0/24 from Site B to the Internet via Remote Site A FortiGate.
Topology:
192.168.20.0/24 -> Site B FTG -> IPsec Tunnel -> Site A FTG -> Internet.
Site B:
Firstly, on Site B it is necessary to create a policy route to route the traffic for the internet via IPSEC Tunnel for source subnet on Site B 192.168.20.0/24. The remaining sources will match the Kernel Routes (FIB) [default wan routes] for forwarding the traffic and hence they will exit via Local WAN for internet access.
In the above example, it is possible to choose the LAN interface as port3 and source 192.168.20.0/24 forwarding via the Tunnel name: remote using gateway IP of the remote Site A Tunnel IP 172.16.10.2.
CLI configuration:
config router policy edit 1 set input-device "port3" set src "192.168.20.0/255.255.255.0" set gateway 172.16.10.2 set output-device "remote" next end
Note: it is possible to only choose a single IPsec interface as the policy route cannot choose the SD-WAN zone
Also, it is necessary to have a Default route (static route) in the Routing Table with the IPSec tunnel as the Gateway. It is possible to create a default static route with the same distance as the existing default route but with a Higher Priority value (the higher the priority, the route is least preferred).
This will make sure to have two default routes existing in the routing table, but the preferred one will be over the local WAN.
Verify the default route on the routing table:
Step 4: Verify, if the required policy is in place. From Site B, make sure to allow access from the source subnet 192.168.20.0/24 to the IPSec tunnel with the Destination Address as ‘ALL’.
Site B:
Site A:
On Site A, it is necessary for the policy to allow traffic from the IPSec tunnel interface to its WAN (Internet) with NAT enabled. Site A should also have the route back to Site B’s internal IP address via the Tunnel.
Verifying connection:
Try to ping from a PC behind Site B to the internet.
Traceroute: it is possible to see the traffic is forwarded via the gateway 172.16.10.2 which is the gateway IP of the remote Site A tunnel.
On FortiGate run debug flow and sniffer to verify.
Sniffer:
diagnose sniffer packet any "host 192.168.20.2 and host 8.8.8.8" 4 0 l
Site B:
Site A:
CTRL + C to stop sniffers.
Debug flow:
di de reset di de flow filter addr 192.168.20.2 8.8.8.8 and di de flow filter proto 1 di de flow trace start 999 di de console timestamp en di de flow show function-name en di de flow show iprope en di de en
di de disable --> To stop the debugs.
Site B: Debug logs :
Challenger-kvm91 # 2024-07-27 09:43:55 id=65308 trace_id=62 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=1, 192.168.20.2:1->8.8.8.8:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=55."
2024-07-27 09:43:55 id=65308 trace_id=62 func=init_ip_session_common line=6127 msg="allocate a new session-0013a5c4"
2024-07-27 09:43:55 id=65308 trace_id=62 func=rpdb_srv_match_input line=1148 msg="Match policy routing id=1: to 172.16.10.2 via ifindex-22"
2024-07-27 09:43:55 id=65308 trace_id=62 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=00000000 gw-10.9.10.166 via remote"
2024-07-27 09:43:55 id=65308 trace_id=62 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=62, len=2"
2024-07-27 09:43:55 id=65308 trace_id=62 func=fw_forward_handler line=997 msg="Allowed by Policy-1:"
2024-07-27 09:43:55 id=65308 trace_id=62 func=ip_session_confirm_final line=3141 msg="npu_state=0x100, hook=4"
2024-07-27 09:43:55 id=65308 trace_id=62 func=ipsecdev_hard_start_xmit line=662 msg="enter IPSec interface remote, tun_id=0.0.0.0"
2024-07-27 09:43:55 id=65308 trace_id=62 func=_do_ipsecdev_hard_start_xmit line=222 msg="output to IPSec tunnel remote, tun_id=10.9.10.166, vrf 0"
2024-07-27 09:43:55 id=65308 trace_id=62 func=esp_output4 line=917 msg="IPsec encrypt/auth"
2024-07-27 09:43:56 id=65308 trace_id=62 func=nipsec_set_ipsec_sa_enc line=945 msg="Trying to offload IPsec encrypt SA (p1/p2/spi={remote/remote/0xb8ccfadb}), npudev=-1, skb-dev=port1"
2024-07-27 09:43:56 id=65308 trace_id=62 func=nipsec_set_ipsec_sa_enc line=994 msg="IPSec encrypt SA (p1/p2/spi={remote/remote/0xb8ccfadb}) offloading-check failed, reason_code=2."
2024-07-27 09:43:56 id=65308 trace_id=62 func=ipsec_output_finish line=676 msg="send to 0.0.0.0 via intf-port1"
2024-07-27 09:43:56 id=65308 trace_id=63 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=1, 8.8.8.8:1->192.168.20.2:0) tun_id=10.9.10.166 from remote. type=0, code=0, id=1, seq=55."
2024-07-27 09:43:56 id=65308 trace_id=63 func=resolve_ip_tuple_fast line=6030 msg="Find an existing session, id-0013a5c4, reply direction"
It is possible to see the requests and replies between site A and site B and the policy route that has been created is working as expected.