Fortigate 7.6.7

Hi ​@HS08 

When you say ADVPN, are you talking about spoke to spoke traffic.

Can you share diagram of the connection when it is accessible and when it is not.

Take a sniffer on the FGT when it is not working

Hello,
After the FortiGate upgrade, it appears that HTTPS traffic destined for the Dedicated Management Interface IP is no longer being processed as local-in traffic.

As a test, could you please create a local-in policy to allow HTTPS access?

I noticed the following difference in the debug logs:

Working Log:
msg="find a route: flag=80000000 gw-0.0.0.0 via Internet"

Not Working Log:
msg="find a route: flag=00000000 gw-10.107.151.2 via To Core Switch"

Also, is Dedicated Management enabled on the MGMT interface?

Best Regards

Hi ​@HS08,

From the debug flow, the ADVPN path itself appears to be working.

For the failed HTTPS test to the management IP 10.107.200.2:15443, the packet arrives correctly through the ADVPN shortcut tunnel from 10.100.50.168:

10.100.50.168:62128 -> 10.107.200.2:15443
tun_id=18.18.9.1 from WAN-1_0

The packet matches firewall policy 15 and is allowed. However, the FortiGate does not treat 10.107.200.2 as a local IP in the VDOM where the debug was collected. Instead, it performs a routing lookup and forwards the packet toward the core switch:

find a route: flag=00000000 gw-10.107.151.2 via To Core Switch
Allowed by Policy-15

My assumption is that the dedicated management interface/IP belongs to a different VDOM, such as the management VDOM, or is otherwise separated from the traffic VDOM. In that case, traffic arriving through the ADVPN tunnel in the Internet VDOM would not terminate locally on 10.107.200.2. It would be routed through the core switch toward the management network instead.

This is different from the working test to 10.107.151.1:15443. In that trace, FortiGate recognizes the destination as one of its own local interface IPs:

find a route: flag=80000000 gw-0.0.0.0 via Internet

It then processes the connection as local-in traffic and accepts the session:

iprope_in_check
policy-4294967295 is matched, act-accept
ip_session_confirm_final

So the behavior appears to be:

Working:
ADVPN -> local interface IP in the same VDOM -> local-in processing -> accepted

Not working:
ADVPN -> management IP not local to this VDOM -> routed to core switch -> no return packet shown

The failing trace only shows the SYN being forwarded toward the management network. It does not show a SYN-ACK returning from 10.107.200.2, so the likely issue is on the return path, possibly asymmetric routing through the dedicated management gateway or management VDOM.

Can you confirm:

1. Did access to the management IP work before the upgrade?

2. Which FortiOS version did you upgrade from?

3. Is the dedicated management interface assigned to a separate management VDOM?

4. Can you compare the pre- and post-upgrade configuration for the management interface, management gateway, VDOM assignment, static routes, policy routes, and local-in policies?

It would also help to run a sniffer while testing:

diagnose sniffer packet any 'host 10.100.50.168 and host 10.107.200.2 and port 15443' 4 0 l

The key point is to verify whether the SYN-ACK is generated by the management IP and which interface/path it uses for the reply.

hi ​@sjoshi i believe the localor LAN traffic will not hit the policy. Lan from spoke1 if connect to the mgmt of FGT spoke 1 then will use local-in policy maybe, am i right? The firewall rule existimng now only for traffic from LAN to internet or to otehr spokes.

hi,

can you try this?

config system global
 set gui-cdn-usage disable
end