| Description | This article describes the configuration to cause traffic from two or more LAN subnets to use different WAN links as default routes. This article also explains how to resolve a LAN-to-LAN connectivity issue while using a policy route. |
| Scope |
FortiGate. |
| Solution |
Example scenario: A user wants the Guest Subnet (10.67.0.0/20) to use WAN1 as its default gateway while VIP Subnet (10.64.0.0/20) uses WAN2 as default gateway. The user has configured a default route for both subnets through policy routes.
When used as a source, the Guest subnet will use WAN1 as its default route:
When used as a source, the VIP subnet will use WAN2 as its default route:
After the creation of the policy routes, an issue occurs where the VIP subnet cannot communicate with the Guest subnet and vice versa, even if a firewall policy from LAN to LAN has already been created. This occurs even if the subnets are present on the routing table and tagged as connected due to the policy route.
Ping from Guest to VIP:
# ping 10.67.0.2 Pinging 10.67.0.2 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Ping statistics for 10.67.0.2: Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),
Sniffer from FortiGate:
diagnose sniffer packet any "icmp" 4 0 1 Using Original Sniffing Mode interfaces=[any] filters=[icmp] 14.050212 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 14.050260 port2 out 10.47.3.235 -> 10.67.0.2: icmp: echo request 18.989966 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 18.989978 port2 out 10.47.3.235 -> 10.67.0.2: icmp: echo request 23.987815 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 23.987828 port2 out 10.47.3.235 -> 10.67.0.2: icmp: echo request
Because the Policy route destination is set to 'all', FortiGate will still forward traffic to the configured outgoing interface on the Policy route even if the destination is a connected subnet on the routing table. This is because the policy route takes precedence over the routing table on routing decisions.
FortiGate's Routing table:
Routing table for VRF=0 S* 0.0.0.0/0 [10/0] via 10.47.15.254, port2, [1/0] [10/0] via 10.47.31.254, port1, [1/0] C 10.47.0.0/20 is directly connected, port2 C 10.47.16.0/20 is directly connected, port1 C 10.64.0.0/20 is directly connected, port4 C 10.67.0.0/20 is directly connected, port3
Option:1 To resolve this, configure another policy route that will stop policy routing when the destination is a LAN subnet with a specific source. Then, place the newly created policy route on top of the default Policy routes.
Or
Option2 (more scalable solution): It is also possible to create a policy route that will stop policy routing when the destination is a connected subnet or LAN Subnets. Create a policy route with the source address of all and destination addresses of all the connected subnets or LAN subnets then select the stop policy routing, Then place the newly created policy route on top of the default Policy routes.
Option1(sample): Example Policy route that will exempt the VIP subnet from policy routing:
Place it on top of the default policy route:
Option2(sample): Example Policy route that will stop policy routing when the destination address is a connected or LAN subnet.
The guest subnet can now reach the VIP subnet since the traffic going to the VIP subnet is now forwarded to the correct outgoing interface, by routing table configuration.
# ping 10.67.0.2 Pinging 10.67.0.2 with 32 bytes of data: Reply from 10.67.0.2: bytes=32 time=1ms TTL=127 Reply from 10.67.0.2: bytes=32 time=1ms TTL=127 Reply from 10.67.0.2: bytes=32 time=1ms TTL=127 Reply from 10.67.0.2: bytes=32 time=1ms TTL=127 Ping statistics for 10.67.0.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1ms
6.576038 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 6.576143 port3 out 10.64.3.84 -> 10.67.0.2: icmp: echo request 103.505880 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 103.505916 port3 out 10.64.3.84 -> 10.67.0.2: icmp: echo request 103.506590 port3 in 10.67.0.2 -> 10.64.3.84: icmp: echo reply 103.506599 port4 out 10.67.0.2 -> 10.64.3.84: icmp: echo reply 104.513900 port4 in 10.64.3.84 -> 10.67.0.2: icmp: echo request 104.513913 port3 out 10.64.3.84 -> 10.67.0.2: icmp: echo request 104.514302 port3 in 10.67.0.2 -> 10.64.3.84: icmp: echo reply 104.514305 port4 out 10.67.0.2 -> 10.64.3.84: icmp: echo reply |
