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

Assistance getting double NAT port forwarding working properly on Fortigate 61F running 7.2.11

I'm currently trying to get some port forwarding setup on my Fortigate 61F running 7.2.11 build 1740 but am running into some issues because I'm having to run the Fortigate behind another SOHO router (long story). The Fortigate has been added to the DMZ of the SOHO router and its interface is being assigned an ip from the router via DHCP. 

 

I started by configuring the port forwarding like I normally would do by creating a VIP using the following details:

External Ip address is set to 192.168.123.45

Internal ip address is set to 192.168.21.2

Both Internal and external ports are set to desired port numbers

 

Once the VIP was created, I then created the firewall rules to allow traffic to flow, not realizing at first that the traffic was going to have the local_in policy applied to it instead.  Once I determined that it was being treated as local_in traffic, I created a local_in policy for the traffic as follows:

 

interface is set to internal3 

srcaddr is set to all

dstaddr is set to 192.168.123.45

action is set to accept

services are set to the needed services

schedule is set to always

 

Here are the symptoms I am seeing:

 

VIPs are showing hits

canyouseeme.org is reporting that the desired ports are closed

packet capture on internal3 shows incoming syn packets

flow debug shows the following

 

id=65308 trace_id=143 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=6, 52.202.215.126:36066-192.168.123.45:1194) tun_id=0.0.0.0 from internal3. flag [S], seq 3991047574, ack 0, win 26883"
id=65308 trace_id=143 func=init_ip_session_common line=5995 msg="allocate a new session-086bd2a9"
id=65308 trace_id=143 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-192.168.123.45 via root"
id=65308 trace_id=143 func=fw_local_in_handler line=606 msg="iprope_in_check() check failed on policy 0, drop"

 

The issue appears to be that the traffic is being dropped by policy 0.  I did a bunch of Googling and tried the following with no change

 

disabled arp replies on the VIPs

changed dstaddr and service to all in my local_in policy (this has been since changed back)

 

I'm sure I am missing something simple but haven't been able to locate the issue on my own yet.  I appreciate any advice that can be provided.


Raymond  

 

 

4 REPLIES 4
ozkanaltas
Valued Contributor III

Hello @rnorthcott ,

 

In your firewall rule, do you use an address object or vip object? When you are working with vip you should use it in a firewall policy. 

 

Can you try to create your policy with vip object? 

 

 

If you have found a solution, please like and accept it to make it easily accessible to others.
NSE 4-5-6-7 OT Sec - ENT FW
If you have found a solution, please like and accept it to make it easily accessible to others.NSE 4-5-6-7 OT Sec - ENT FW
rnorthcott

Thanks for your reply @ozkanaltas.

 

Are you referring to the local-in firewall policy?  If so, I don't see the VIP object as an option for use when choosing the dstaddr.  If you are referring to other firewall policies, then that should already be configured.

ozkanaltas
Valued Contributor III

Hello @rnorthcott ,

 

Normally, you don't need local-in-policy for these types of traffic. Because local-in-policy is related to which connection that wants to establish a connection directly to the FortiGate interface. 

 

If you use the same IP address for both vip and interface configuration, can you try to change the vip address to a new IP address from the same subnet?

If you have found a solution, please like and accept it to make it easily accessible to others.
NSE 4-5-6-7 OT Sec - ENT FW
If you have found a solution, please like and accept it to make it easily accessible to others.NSE 4-5-6-7 OT Sec - ENT FW
rnorthcott

Doesn't seem to have made a difference.   I noticed that the interface I was using wasn't assigned the WAN role, so wondered if that was causing the issue.  I did successfully update the interface role but that also hasn't resolved the issue.  Any further suggestions would be appreciated.

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors