Forigate 80C Dual WAN issue with inbound traffic on WAN2

[incarnate]

I have a Foritgate 80C which I recently upgraded to v5.2.3 build 670.  I am hoping to test this configuration with this unit before purchasing a Forigate 100D or 200D firewall.

Issue: I have 2 ISP's and utilizing both WAN1 and WAN2.  When WAN1 is active, I cannot receive traffic inbound (such as a ping test) over WAN2.  If I shutdown WAN1, the traffic (the ping test as well as RDP and other tests) start to work right away over WAN2.  If I activate the WAN1 connection again, the traffic inbound on WAN2 stops as soon as the interface is up.

It would appear that while WAN1 is active, inbound connections to WAN2 are not allowed.

Basic Config / Testing (IP's are fake):

(Please read this from top to bottom, basically this is me working logically through the configuration w/ my results as I progress)

Internal1 (LAN) Mailserver for testing - 172.16.5.10

WAN1 - Static IP Address - Have 5 Static IP's I can use Interface has IP Address 10.0.0.2 and GW of 10.0.0.1

WAN2 - Static IP Address - Have 5 Static IP's that I can use Interface has IP Address 192.168.1.2 and a GW of 192.168.1.1

Static Route - 0.0.0.0 / 0.0.0.0 Device (WAN1) Gateway 10.0.0.1 Administrative Distance 10

Static Route - 0.0.0.0 / 0.0.0.0 Device (WAN2) Gateway 192.168.1.1 Administrative Distance 20

Firewall Policy1: Incoming: Internal LAN1, 172.16.5.0/24 Outgoing WAN1, ALL, ALWAYS, ALL, ACCEPT NAT On, Use Outgoing Interface Address

Firewall Policy2: Incoming: Internal LAN1, 172.16.5.0/24 Outgoing WAN2, ALL, ALWAYS, ALL, ACCEPT NAT On, Use Outgoing Interface Address

At this point in the configuration my mailserver will connect out the internet via WAN1 and have a public IP of 10.0.0.2 (FW WAN1 address).

I then add a policy route: Incoming Interface (Internal1 (LAN)) Source 172.16.5.10/255.255.255.255 Destination 0.0.0.0/0.0.0.0 Forward Traffic - Outgoing Interface WAN2 192.168.1.1.

At this point in the configuration, the mailserver will connect to the internet via WAN2 and have a public IP of 192.168.1.2 (FW WAN2 address).

Add a Virtual IP: External 192.168.1.5 (one of my usable external statics) mapped to 172.16.5.10 (NO port forwarding)

At this point in the configuration, the mailserver still connects to the internet via WAN2 with a public IP of 192.168.1.2 (FW WAN 2 Address).

I then add a FW policy, WAN2 - Internal: Incoming Interface WAN2, source ALL, Outgoing Interface Internal1(LAN) Destination Address (Virtual IP 192.168.1.5 --> 172.16.5.10) ALWAYS, Service ALL (just as test!) ACCEPT, NAT OFF

At this point my mailserver will connect to the internet via WAN2 and have a public IP of 192.168.1.5 (Virtual IP mapping working).  However at this point in the configuration, I cannot connect from the outside to 192.168.1.5. If I do a administrative shutdown of the WAN1 interface, I can then connect into WAN2 via the virtual IP address as configured.  As soon as I activate WAN1 again, I lose connectivity.  (Also trying NAT ON vs NAT OFF makes no difference)

Is this a limitation of the firewall?  An unsupported configuration?  Am I missing something?

Thank you for taking the time to read all of this.  I appreciate any and all help!

[Christopher_McMullan · Accepted solution]

Could you try changing the administrative distance of the WAN2 route to 10 to match the route for WAN1, but give it a higher integer for priority? That way, it's at least in the routing table as a feasible reverse path, even if it's not the preferred path.

[incarnate]

Christopher,

THANK YOU!!!!!

I had played around with setting the distance to equal 10 for both connections, but traffic would almost always default to go out WAN2.  I recently upgraded from an old version (Version 4) in testing this and never saw the priority setting :(.

This was spot on.  Setting the distance as equal and the priority for WAN1 as 10 and WAN2 as 20 kept everything that was working, working the way it was and allowed WAN2 inbound traffic.

I am very happy it was just a setting I missed!  Thank you again Christopher!!!!

--Matt

[Christopher_McMullan]

No problem!

The issue in OS 4.x makes sense, since we didn't add priority until 4.3.