Allow Inbound access to device on 2nd WAN

[Krich124]

We have a host in a VLAN that needs to be openly accessed by an outside provider through a 2nd WAN port. We've followed Fortinet documentation on port forwarding and 1:1 NAT but we aren't able to ping the host. The configuration is as follows:

We have a default route to our primary WAN on port 1 with a static public IP x.x.x.200. We have a 2nd WAN connection on port 18 with a static public IP of x.x.x.199. We have an internal VLAN (DMZ) with a gateway of 10.200.80.1 and a host at 10.200.80.2. We need any traffic hitting our 2nd WAN (x.x.x.199) to be forwarded to the 10.200.80.2 host.

We have a a virtual IP configured to map the 2nd WAN to 10.200.80.2 (x.x.x.199 -> 10.200.80.2). We also have firewall policy stating [ SRC INT: WAN2 - DST INT: DMZ  SRC: Any - DST: VIP (x.x.x.199 -> 10.200.80.2) SERVICE: ALL  NAT: Dynamic IP Pool (One-One, x.x.x.199) Preserve Source Port  ]

We aren't able to ping the host or pass any traffic to 10.200.80.2 when we hit x.x.x.199.

[abarushka]

Hello,

In case NAT is not configured you may consider to collect debug flow traces

diagnose debug flow filter saddr <source IP address>

diagnose debug flow show function-name enable
diagnose debug flow trace start 10

diagnose debug enable

and traffic sniffer

diagnose sniffer packet any 'host <source IP address>' 4 0 a

[Krich124]

Thank you for the response. I ran the provided commands and noticed the logs returning 'msg="reverse path check fail, drop" . I have a static route back to the IP we are testing from but it still doesn't seem to work.

[gfleming]

I don't think you want to have NAT enabled on your inbound FW policy. Can you try disabling NAT there?

[Krich124]

NAT disabled returns the same result. I created a static route to the IP we are testing from, but when I run a packet capture it says the source IP we are pinging from is unreachable.

[abarushka]

Hello,

I suspect that there is no default route via wan2. You may consider to configure default route for wan2 and if necessary tune default route preference by different route priorities. Therefore, there will be 2 routes in the routing table and only one will be used for outbound traffic.

https://community.fortinet.com/t5/FortiGate/Technical-Note-Routing-behavior-depending-on-distance-an...

[vsahu]

Please remove the Source NAT in the policy, it seems incorrect, Can you explain the requirement on why you've enabled it ?

Also, share the output of the session table after initiating the traffic.

diag sys session filter src <source IP address>

diag sys session list

[Krich124]

We created a source NAT so that inbound traffic to the x.x.x.199 IP would be mapped to the 10.200.80.2. With source NAT disabled, the output for the provided commands give 'total sessions 0' while traffic is initiated

[gfleming]

As someone else pointed out you also likely are missing a default route back pointing out your port18. Without that route, no sessions will work (unless you have SNAT enabled which you really shouldn't have in this case). And without that route you will get RPF errors.

[kvimaladevi]

Also,  you can cross check the route again using the command "get router info routing-table details 0.0.0.0" to check if wan2 has an active route to internet. Could you confirm if both wan1 and wan2 are configured to do load balancing or if it is configured for fail over.

Usually, RPF errors come up when there is no active route through the interface that you want the return traffic to take. 

Regards,

Vimala