Skip to main content
MaeIstrom
New Member
January 22, 2026
Question

Fortigate is blocking traffic to another DNAT setup

  • January 22, 2026
  • 3 replies
  • 593 views

I have a server running multiple services behind a modem that uses port forwarding to redirect ports on the public ip to an internal ip. So for example homeserver.ddns.net:8123 forwards through to 192.168.1.1:80. This works fine for all computers except the ones behind a fortigate device running FortiOS v7.0.12 (GA). The only relevant firewall rule on the fortigate is one say all traffic from the internal device to the external device should be allowed and NATed. The machines on the internal network can connect to any other ip or port on the internet just not the ones behind my modem, they just timeout. Although I do notice there's an option to preserve the source port that is currently disabled. Would that help or is there anywhere else that this type of traffic is being blocked?

3 replies

MaeIstrom
MaeIstromAuthor
New Member
January 22, 2026

So just did a traceroute from one of the machines and the first hop was the fortinet's internal IP, the second was something other than its public IP. Same subnet but where I would expect to see 44.44.44.44 it's 44.44.44.1. Now my boss is talking about CGNAT which is possible I guess but I could've sworn they had a static IP. Plus the fortinet itself forwards proxmox and ssh ports to an internal IP and that has never not worked. 

funkylicious
SuperUser
SuperUser
January 22, 2026

hi,

from my understanding the DNAT is performed on another device not directly on the FortiGate.

on the FGT is there any traffic/configuration done for this DNAT to work, like a VIP or something or firewall rules ?

a diagram of the setup would help understand better the setup and where to tshoot the problem.

"jack of all trades, master of none"
MaeIstrom
MaeIstromAuthor
New Member
January 29, 2026

192.168.0.11:8193 <--[modem:80] <-- internet --> [fortigate] <-- 192.168.1.1

The modem/DNAT is in a different location and has no 'connection' to the office with the fortigate other than them both being on the internet. There are no specific rules on the fortigate other than it should do NAT (not using VIP) for 192.168.1.0/24. There is a separate DNAT that fortigate is doing for 192.168.1.1 using VIP that works but no machine on 192.168.1.0/24 can connect to  the modems DNATed ports. 

nevan
Staff
Staff
January 22, 2026

Preserved source port is very likely the fix the NAT session handling issues, often fixes this because the modem’s DNAT expects the original source port. Also check that strict source checking is disabled, as FortiGate may drop the return traffic otherwise. 

To troubleshoot in detail, open a TAC ticket as well but be informd that the 7.0 FortiOS version is out of support at the moment. Please try also upgrade to a supported version including engineering support like 7.4, 7.6 and 8.0.

// Kindness is the Key //
MaeIstrom
MaeIstromAuthor
New Member
January 29, 2026

I've tried preserving the source port and disabling strict  source checking and still timing out. I tried viewing the debug for 192.168.1.1 and I'm seeing a lot of messages like...

 

trace_id=71 func=print_pkg_detail line=5844 msg="vd-root:0 received a packet(proto=6, 192.168.1.1:45180->MODEM_IP:80) tun_id=0.0.0.0 from internal. flag [S], seq 3388515585, ack 0, win 64240"

trace_id=71 func=init_ip_session_common line=6023 msg="allocate a new session-00112765, tun_id=0.0.0.0"

trace_id=71 func=vf_ip_route_input_common line=2605 msg="find a route: flag=040000 gw-MODEM_IP via ssl.root"

trace_id=71 func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 0)"

 

I'll see what I can do with the upgrading versions. It's being used by a busy medical clinic that can't afford any downtime and everyone is paranoid about messing with it.

nevan
Staff
Staff
January 29, 2026

Dear MaeIstrom,


In these message the last one is showing there is no valid firewall policy for the specific packet flow. Which is why it was dropped by policy 0.

msg="Denied by forward policy check (policy 0)"

So, try adding a valid firewall policy to allow the traffic. 

Regards.

// Kindness is the Key //