resolved -- Dual WAN - inbound NAT on second WAN

Welcome to the forums. What exactly is your goal?

Please try again, leaving the ' Gateway Interface' field empty (no IP). You can test by tracert' ing from the server to some host on the ' net - and see the WAN2 byte counter incrementing. Then, try to reach the server from outside and observe the reply traffic.

Thanks for the replies. An OpenVPN server is sitting on the LAN behind the Fortigate. We want to use the second WAN for only OpenVPN traffic. I use port 8080 as a simple test case in the LAB before I deploy the device. yes, I know the FTG offers a VPN service - this is a legacy implementation that we need t continue to support for the foreseeable future. Ede, never thought of doing what you are suggesting - thanks, I will test and feed back. Riaan

Thanks Bob. Can we specify the openvpn ports in the routing policy? Do not want other services form the Openvpn server (e.g. Squid) also being routed out via the 2nd WAN. I' ll test all suggestions tomorrow when I get into the office. Riaan

Hi Well, I can get outbound policy based routing to work - but still not the inbound NAT. To clarify, I have 3 WAN connections, one point to point on WAN1, ADSL on WAN2 and another ADSL connection on the DMZ port. All of these have static IP addresses. one vdom only - root I have setup a Virtual IP as follows: ext IP - x.x.x.107 int IP - 192.9.200.200 Port Fwd - enabled. Ext Service port - 3389 int service port - 3389 (yes, testing with RDP now, my lab changed slightly) I have a firewall policy for this as follows: Source Interface - DMZ Source address - any source destination - internal 1 (LAN port) dest Addr: VIP name Allow all, always NAT enabled (this policy is never hit - the counter does not increase) Policy route: Protocol: 0 incoming interface: internal1 source addrs: 192.9.200.200/32 destination: 0.0.0.0/0.0.0.0 dest ports: 1 to 65535 TOS settings left alone Force traffic to: outgoing interface: DMZ Gateway addr: x.x.x.105 (2nd ADSL gateway IP) diagnose sniffer for port 3389: 6.521034 dmz in X.X.X.91.59595 -> X.X.X.107.3389: syn 2703900281 9.540947 dmz in X.X.X.91.59595 -> X.X.X.107.3389: syn 2703900281 15.520676 dmz in X.X.X.91.59595 -> X.X.X.107.3389: syn 2703900281 X.X.X.107 is the external IP on the 2nd ADSL connection. So, it looks like the inbound traffic is not allowed through even though I have a policy allowing the traffic (which is not hit as per above) What I can not figure out is why the incoming traffic is not allowed. Thanks for your help - hope the information above is not too confusing. Riaan

This is a debug trace on port 3389 when I try and RDP in on the 2nd ADSL connection. Is the highlighted line the issue? capetown (root) # id=36870 trace_id=16 func=resolve_ip_tuple_fast line=3403 msg=" vd-root received a packet(proto=6, 196.211.62.91:53784->196.214.69.107:3389) from dmz." id=36870 trace_id=16 func=resolve_ip_tuple line=3526 msg=" allocate a new session-000405b4" id=36870 trace_id=16 func=get_new_addr line=1755 msg=" find SNAT: IP-192.9.200.200(from IPPOOL), port-3389" id=36870 trace_id=16 func=fw_pre_route_handler line=127 msg=" VIP-192.9.200.200:3389, outdev-dmz" id=36870 trace_id=16 func=__ip_session_run_tuple line=1853 msg=" DNAT 196.214.69.107:3389->192.9.200.200:3389" id=36870 trace_id=16 func=rpdb_srv_match line=423 msg=" Match policy routing: to 192.9.200.200 via ifindex-9" id=36870 trace_id=16 func=ip_route_input_slow line=1267 msg=" reverse path check fail, drop" id=36870 trace_id=17 func=resolve_ip_tuple_fast line=3403 msg=" vd-root received a packet(proto=6, 196.211.62.91:53784->196.214.69.107:3389) from dmz." id=36870 trace_id=17 func=resolve_ip_tuple line=3526 msg=" allocate a new session-000405b5" id=36870 trace_id=17 func=get_new_addr line=1755 msg=" find SNAT: IP-192.9.200.200(from IPPOOL), port-3389" id=36870 trace_id=17 func=fw_pre_route_handler line=127 msg=" VIP-192.9.200.200:3389, outdev-dmz" id=36870 trace_id=17 func=__ip_session_run_tuple line=1853 msg=" DNAT 196.214.69.107:3389->192.9.200.200:3389" id=36870 trace_id=17 func=rpdb_srv_match line=423 msg=" Match policy routing: to 192.9.200.200 via ifindex-9" id=36870 trace_id=17 func=ip_route_input_slow line=1267 msg=" reverse path check fail, drop" id=36870 trace_id=18 func=resolve_ip_tuple_fast line=3403 msg=" vd-root received a packet(proto=6, 196.211.62.91:53784->196.214.69.107:3389) from dmz." id=36870 trace_id=18 func=resolve_ip_tuple line=3526 msg=" allocate a new session-000405b8" id=36870 trace_id=18 func=get_new_addr line=1755 msg=" find SNAT: IP-192.9.200.200(from IPPOOL), port-3389" id=36870 trace_id=18 func=fw_pre_route_handler line=127 msg=" VIP-192.9.200.200:3389, outdev-dmz" id=36870 trace_id=18 func=__ip_session_run_tuple line=1853 msg=" DNAT 196.214.69.107:3389->192.9.200.200:3389" id=36870 trace_id=18 func=rpdb_srv_match line=423 msg=" Match policy routing: to 192.9.200.200 via ifindex-9" id=36870 trace_id=18 func=ip_route_input_slow line=1267 msg=" reverse path check fail, drop"

Hi, the highlighted line indicates that the packets going out dont come back on the same interface, the fortigate will then drop them.

Thanks I have figured out what I have been doing wrong. I did not add a default route out for the second ADSL connection. I added a static route of 0.0.0.0 for the 2nd ADSL with a priority of 10. I was under the impression that the policy based route would negate the need for this. This technote details how to route inbound traffic via secondary WAN connection: http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD31240 Thanks all! Riaan

The reason why you need a second default route here is the following: as an anti-spoof measure the FGT will reject incoming traffic to which it does not have a valid route back. A default route ' clears' all incoming traffic. BUT, you should give the secondary default route a higher priority (= less preference) than the primary default route via wan1. If you look at the routing monitor you should see both default routes but only one (the primary) will be used for egress traffic. The secondary default route is mentioned in the cited KB article, alas without any explanation why it' s needed (keyword: anti-spoof). They just write that it will ' allow packet ingressing wan2 from the internet' .

Thanks for the explanation Ede