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.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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
Created on 02-21-2023 07:50 AM Edited on 02-21-2023 07:52 AM
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.
I don't think you want to have NAT enabled on your inbound FW policy. Can you try disabling NAT there?
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.
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.
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
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
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.
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1560 | |
1034 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.