New Member

Solved

Allow Inbound access to device on 2nd WAN

Forum|Forum|3 years ago
February 21, 2023
5 replies
5050 views

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.

FortiGate

Best answer by gfleming

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.

abarushka

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

Krich124Author

New Member

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

Staff

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

A

Anonymous_User

New Contributor III

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

Krich124Author

New Member

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

Staff

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

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

A

Anonymous_User

New Contributor III

Hi @Krich124 ,

Looking at the information provided, i believe there are no static route for WAN2.
0.0.0.0/0 GW WAN1 Distance 1 Priority 0

0.0.0.0/0 GW WAN2 Distance 1 Priority 5 << you are missing this.

If traffic coming from WAN2, the fortigate respond back using WAN1 which cause "reverse path check failed".

Creating a default route for the WAN2 basically will resolved the routing issue.

The rest, please configure VIP and Policy accordingly.

Krich124Author

New Member

Here is the routing I have configured for both WAN ports. The WAN IPs are in the same subnet thus have the same GW.

FW2# get router info routing-table static
Routing table for VRF=0
S* 0.0.0.0/0 [5/0] via x.x.x.185, port17, [2/0]

Routing table for VRF=1
S* 0.0.0.0/0 [10/0] via x.x.x.185, port18, [5/0]

A

Anonymous_User

New Contributor III

Hi @Krich124 ,

Thank you for the respond.
Please make sure the distance is same. Priority is different between that WAN1 and WAN2.

Make sure you can ping WAN2 interface itself 1st. Then the VIP should be working.

gflemingAnswer

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.

Krich124Author

New Member

Thank you Graham. I'm not sure where the multiple VRFs came into play. I have added the 2nd IP to the primary WAN and I am able to see ICMP traffic coming inbound to the device.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded