Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Krich124
New Contributor

Allow Inbound access to device on 2nd WAN

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.

1 Solution
gfleming
Staff
Staff

OK so you are using different VRFs... that is key information here.

 

Is the DMZ interface in VRF 1 or 0?

 

Why are you using VRFs?

 

Why are both your WAN IPs in the same subnet? Are they actually different circuits or is it a single shared circuit that you are trying to use differetn IP addresses on?

 

If it's the latter, you do not need to use multiple interfaces. Just have your primary WAN interface with IP address X. Then use VIPs for the other public IP addresses you own. They will enable ARP on the WAN interface to respond to those other IP addresses.

Cheers,
Graham

View solution in original post

15 REPLIES 15
abarushka
Staff
Staff

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

FortiGate
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?

Cheers,
Graham
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...

FortiGate
vsahu
Staff
Staff

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

Regards,
Vishal
Krich124
New Contributor

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.

Cheers,
Graham
kvimaladevi
Staff
Staff

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

Labels
Top Kudoed Authors