|
While configuration may differ, a typical topology where the issue occurs the most is when a switch downstream is connected and is sending the traffic towards the FortiGate:
In the topology above, the firewall is being accessed on port Internal_7, the management port. Ports Internal_1 and Internal_2 are configured as a virtual wire pair.
When configured correctly, it should be possible to access the FortiGate. However, there are instances where upgrading the FortiGate causes access to be lost.
This occurs because the FortiGate overlaps the traffic to the virtual wire pair traffic during an access attempt.
Running the sniffer would show the management traffic will overlap with the virtual wire pair:
2024-04-22 10:21:07.275390 internal2 in 10.240.137.113.62965 -> 10.240.104.254.8443: psh 1730862386 ack 4238174702
2024-04-22 10:21:07.688197 internal2 in 10.240.137.113.62965 -> 10.240.104.254.8443: 1730862385 ack 4238174702
2024-04-22 10:21:07.871379 internal2 in 10.240.137.113.62986 -> 10.240.104.254.8443: psh 4112164305 ack 1889223950
2024-04-22 10:21:08.268398 internal2 in 10.240.137.113.62990 -> 10.240.104.254.8443: syn 2572806924
2024-04-22 10:21:08.268526 internal1 out 10.240.137.113.62990 -> 10.240.104.254.8443: syn 2572806924
2024-04-22 10:21:08.268554 internal7 in 10.240.137.113.62990 -> 10.240.104.254.8443: syn 2572806924
2024-04-22 10:21:08.268648 internal2 out 10.240.104.254.8443 -> 10.240.137.113.62990: syn 870543637 ack 257280
Another indicator is the flow debugs, which will send the logs to the IPS:
id=65308 trace_id=25 func=print_pkt_detail line=5831 msg="vd-root:0 received a packet(proto=1, 10.240.137.113:1->10.240.104.254:2048) tun_id=0.0.0.0 from internal7. type=8, code=0, id=1, seq=13158."
id=65308 trace_id=25 func=resolve_ip_tuple_fast line=5914 msg="Find an existing session, id-00009b47, original direction"
id=65308 trace_id=25 func=ip_local_deliver_finish2 line=459 msg="send to ips"
id=65308 trace_id=26 func=print_pkt_detail line=5831 msg="vd-root:0 received a packet(proto=1, 10.240.137.113:1->10.240.104.254:2048) tun_id=0.0.0.0 from internal7. type=8, code=0, id=1, seq=13163."
id=65308 trace_id=26 func=resolve_ip_tuple_fast line=5914 msg="Find an existing session, id-00009b47, original direction"
id=65308 trace_id=26 func=ip_local_deliver_finish2 line=459 msg="send to ips"
id=65308 trace_id=27 func=print_pkt_detail line=5831 msg="vd-root:0 received a packet(proto=1, 10.240.137.113:
1->10.240.104.254:2048) tun_id=0.0.0.0 from internal7. type=8, code=0, id=1, seq=13169."
id=65308 trace_id=27 func=resolve_ip_tuple_fast line=5914 msg="Find an existing session, id-00009b47, original direction"
id=65308 trace_id=27 func=ip_local_deliver_finish2 line=459 msg="send to ips"
id=65308 trace_id=28 func=print_pkt_detail line=5831 msg="vd-root:0 received a packet(proto=1, 10.240.137.113:
1->10.240.104.254:2048) tun_id=0.0.0.0 from internal7. type=8, code=0, id=1, seq=13175."
id=65308 trace_id=28 func=resolve_ip_tuple_fast line=5914 msg="Find an existing session, id-00009b47, original
direction"
It is recommended to always keep the management traffic separate from the virtual wire pair.
- Best practice is to have a separate management VDOM created for management access.
- If a separate VDOM is not feasible, the next easiest fix is to put the management interface in a different VRF.
config system interface
edit interface42
...
set vrf 14
next
end
|
