New Member

Question

ipv4 Policy not working

Forum|Forum|28 days ago
June 16, 2026
6 replies
63 views

Apologies for what I hope my struggles are merely from being a novice user of Fortigate products. I am now managing my first Fortigate 60E and trying to get port forwarding to work for a specific source. Actually, I do have port forwarding working for a specific source, but only one source. When I try to add any other source to a rule or even a separate rule for the source in question, it doesn’t work. I can’t remember if the source IP address that works was setup in some special way in the past, I am unable to find differences. So, I use the CLI to debug and really do not understand why the differences. First of all, here are the rules, both WebTent and WebTent DC are single IP addresses.

As you can see, I am forwarding port 5022 to an internal IP port 22, this works from WebTent, but not WebTent-DC. So, for the debug, I see this for traffic when coming from WebTent and it works…

FGT60ETK18001521 # diagnose debug flow filter saddr < my WebTent IP address >
FGT60ETK18001521 # diagnose debug flow trace start 100
FGT60ETK18001521 # diagnose debug enable
FGT60ETK18001521 # id=20085 trace_id=267 func=print_pkt_detail line=4903 msg="vd-root received a packet(proto=6, < my WebTent IP address >:3285->< wan address >:5022) from wan2. flag [S], seq 203916275, ack 0, win 65535"
id=20085 trace_id=267 func=init_ip_session_common line=5047 msg="allocate a new session-079fa6dc"
id=20085 trace_id=267 func=fw_pre_route_handler line=182 msg="VIP-192.168.1.50:22, outdev-wan2"
id=20085 trace_id=267 func=__ip_session_run_tuple line=2894 msg="DNAT < wan address >:5022->192.168.1.50:22"

Now, from WebTent-DC…

FGT60ETK18001521 # diagnose debug flow filter saddr < my WebTent-DC IP address >
FGT60ETK18001521 # diagnose debug flow trace start 100
FGT60ETK18001521 # diagnose debug enable
FGT60ETK18001521 # id=20085 trace_id=269 func=print_pkt_detail line=4903 msg="vd-root received a packet(proto=6, < my WebTent-DC IP address >:35125->< wan address >:5022) from wan2. flag [S], seq 3558509990, ack 0, win 65535"
id=20085 trace_id=269 func=init_ip_session_common line=5047 msg="allocate a new session-079fae18"
id=20085 trace_id=269 func=vf_ip_route_input_common line=2583 msg="find a route: flag=80000000 gw-< wan address > via root"
id=20085 trace_id=269 func=fw_local_in_handler line=391 msg="iprope_in_check() check failed on policy 0, drop"

Could someone help me see what I must be missing that doesn’t allow WebTent-DC to connect? I am not aware of any “apply” button and understand the Fortigate should save the configuration automatically.

msanjaypadma

Staff

Hi @rwfitzy ,

I do not observe any DNAT check occurrences in this debug

id=20085 trace_id=269 func=vf_ip_route_input_common line=2583 msg="find a route: flag=80000000 gw-< wan address > via root"
id=20085 trace_id=269 func=fw_local_in_handler line=391 msg="iprope_in_check() check failed on policy 0, drop"

It is possible that an attempt was made to access a different IP within the same subnet or using a different destination port, or dropped in iprope check. Since the traffic is masked, this cannot be confirmed definitively. Typically, the first DNAT check occurs before the routing lookup.

Check any local-in-policy configured ?
show firewall local-in-policy

Could you verify whether the source IP address has been mistakenly configured under the VIP or IP Pool settings?
show firewall ippool | grep -f < my WebTent-DC IP address >
show firewall vip | grep -f < my WebTent-DC IP address >

Possible to collect iprope debug logs, You can share me the logs in Private message if its confidential :

Connect the FGT using SSH, enable logging and collect the below:

>>open putty client, start the session logging

You can start the logging, by following the below document

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-create-a-log-file-of-a-session-using-PuTTY/ta-p/194148?externalID=FD36043

SSH 1:
get sys status
get sys performance status
get router info routing detail <destination>
get router info routing detail <source>
get router info routing all
get sys arp
get router info kernel
diag firewall proute list

SSH 2 :
diag debug reset
diag debug disable
diag debug console timestamp enable
diag debug flow trace stop
diag debug flow filter clear
diag debug flow filter addr x.x.x.x <--- source IP address
diag debug flow show iprope enable
diag debug flow show function-name enable
diag debug console timestamp enable
diag debug flow trace start 9999
diag debug enable

SSH 3:
diag sniffer packet any “host y.y.y.y “ 6 0 l <<<<<<<where y.y.y.y is source ip address

Now initiate traffic from user system.

If you observed error/disconnection in the connection then please stop all traffic on user PC. Wait for it to complete and stop sniffer by hitting 'ctrl+c' on the keyboard and to stop debug enter the below commands in SSH2

diag deb disable
diag deb reset

Thanks, Mayur Padma

R

rwfitzyAuthor

New Member

Thank you. The `show firewall ippool` command shows no output. The `show firewall vip` shows the subject WebTent TrueNAS SSH I posted in the IP where the entry is with src-filter for the source IP that works, but it does not show any entries for the IP that does not work. So, using that latter command with the grep option you suggested shows no output. I have collected the ssh log and will forward in private message.

christian_89_

Explorer II

You already posted the answer without realising it. Your VIP has a src-filter set to the WebTent IP, and show firewall vip shows no entry for the WebTent-DC IP. That is the whole problem.

src-filter restricts which source addresses the VIP applies to. When the source matches (WebTent), the VIP fires and DNAT happens. When it does not match (WebTent-DC), the VIP is simply skipped, no DNAT occurs, and the packet keeps the WAN IP as its destination, which is the FortiGate's own address. So it gets handed to the local-in path and dropped, because nothing permits TCP/5022 to the box itself.

That is exactly what your two debugs show:

WebTent (works): fw_pre_route_handler ... VIP-192.168.1.50:22 then DNAT <wan>:5022->192.168.1.50:22. VIP matched, DNAT applied.
WebTent-DC (fails): no VIP line, no DNAT line, straight to fw_local_in_handler ... iprope_in_check() check failed on policy 0, drop. The "policy 0" local-in drop is the tell that DNAT never happened and the traffic was treated as destined to the firewall itself.

Quick fix, add WebTent-DC to the same VIP's source filter:

config firewall vip
    edit "<your TrueNAS SSH VIP name>"
        set src-filter "<WebTent IP>/32" "<WebTent-DC IP>/32"
    next
end

(src-filter is a list, so list both. On newer builds append src-filter "<WebTent-DC IP>/32" adds without retyping the first.)

Better long-term, do not restrict the source on the VIP at all. Remove the src-filter and control allowed sources in the firewall policy instead:

config firewall vip
    edit "<your TrueNAS SSH VIP name>"
        unset src-filter
    next
end

Then on the policy that uses the VIP as destination, set the source to an address group containing both WebTent and WebTent-DC. The reason is precisely what bit you here: when a source fails a VIP src-filter, the VIP silently does not apply and you get a confusing local-in drop. When you gate the source in the policy instead, a non-matching source is denied by the policy with a clear policy-deny log, which is far easier to reason about and to extend later.

This is also why your separate-rule attempt did nothing. A second VIP or policy does not help as long as the original VIP's src-filter is excluding the new source, since the VIP match happens before your policy logic and the traffic never becomes a DNAT session in the first place.

No apply button needed, you are right that the config is already saved. This is purely the src-filter scope.

CFR_

R

rwfitzyAuthor

New Member

Yes, makes sense, and right you are. Now working. And I now see this in the GUI under Source Address Filter for the Virtual IP. Thank you.

R

rwfitzyAuthor

New Member

I tried sending the private message, but it complains the content is too long. I do not see any attachment option in private messages. The log file has almost 500 lines.

R

rwfitzyAuthor

New Member

One other question, can I set the Source Address Filter using a FQDN? Or other way to filter a FQDN source?

christian_89_

Explorer II

Glad it is working. To your FQDN question: no, the VIP Source Address Filter does not accept an FQDN. That field (src-filter) only takes literal IPv4 addresses, ranges and subnets typed in directly. It is not an address-object reference, so you cannot point it at an FQDN object.

The place to filter a source by FQDN is the firewall policy, which is another reason to do source control there rather than on the VIP. Leave the VIP without a src-filter, create an FQDN address object, and use it as the policy's source address:

config firewall address
    edit "WebTent-DC-FQDN"
        set type fqdn
        set fqdn "webtent-dc.example.com"
    next
end

Then on the policy that uses the VIP as destination, set srcaddr to that object (put both sources in an address group if you want WebTent and WebTent-DC together).

One thing to understand so it behaves as you expect: an FQDN object does not do a reverse lookup on the incoming packet. The FortiGate forward-resolves the hostname to its current IP via DNS and matches the source IP of the traffic against that resolved set. So this only works if the remote site's actual public source IP is what the hostname resolves to. That makes it ideal when the remote end has a dynamic IP but a DDNS hostname, since the FortiGate re-resolves it and updates the allowed source automatically. Caveats: the source IP must match the A record (no good if that site sits behind a different egress IP or CGNAT), there is a brief gap if the IP changes before DNS or the FortiGate refreshes, and it depends on the FortiGate having working DNS. For a remote site with a fixed public IP, a plain IP address object is still the more reliable choice.

Since it is resolved now, you do not need to send that iprope log anymore. For future reference, when console output is too long for a PM, save it as a .txt and share a link rather than pasting inline.

CFR_

R

rwfitzyAuthor

New Member

Yes, I had the FQDN set up as a source on the policy, so all I needed to do is remove the sources from the VIP. All good now. Thank you all!

Sign up

Login with SSO

Login to the community

Login with SSO