Technical Tip: Traffic from switch go to switch interface instead of underlying vlan interface

Description

This article describes the behavior of traffic from the switch go to switch interface instead of underlying vlan interface, caused the intermittent connection between the client and server

Scope

FortiSwitch, FortiGate.

Solution

1. In this setup, EMB is the vlan (ID=113) interface, under 'Lan' switch (which has port2 as a member). client [ip = 192.x.x.2] need to communicate to server [ip=192.y.y.72]:

client [192.x.x.2] ===vlan113=== Switch === [EMB / Lan / port2] Firewall [port1] ===  ipsec === [192.y.y.72] Server.

2. However sometimes the client could not ping to the server,  packet sniffer only shows incoming ICMP requests on 'Lan' and 'port2' interface:

2026-07-31 10:46:51.133850 port2 in 192.x.x.2 -> 192.y.y.72: icmp: echo request
2026-07-31 10:46:51.133850 Lan in 192.x.x.2 -> 192.y.y.72: icmp: echo request
2026-07-31 10:46:55.709775 port2 in 192.x.x.2 -> 192.y.y.72: icmp: echo request
2026-07-31 10:46:55.709775 Lan in 192.x.x.2 -> 192.y.y.72: icmp: echo request

The correct behavior is the traffic should be received on EMB interface:

2026-07-31 10:47:10.711874 EMB in 192.x.x.2 -> 192.y.y.72: icmp: echo request
2026-07-31 10:47:10.711913 [ipsec] out 192.x.x.2 -> 192.y.y.72: icmp: echo request
2026-07-31 10:47:10.773820 [ipsec]  in 192.y.y.72 -> 192.x.x.2: icmp: echo reply
2026-07-31 10:47:10.773826 EMB out 192.y.y.72 -> 192.x.x.2: icmp: echo reply

3. Compare the packet sniffer, there are the differences:
   
   

• In non-working case:
  
  

2026-07-31 10:46:51 id=65308 trace_id=2914 func=print_pkt_detail line=5906 msg="vd-root:0 received a packet(proto=1, 192.x.x.2:2->192.y.y.72:2048) tun_id=0.0.0.0 from Lan. type=8, code=0, id=2, seq=35030."
2026-07-31 10:46:51 id=65308 trace_id=2914 func=resolve_ip_tuple_fast line=5994 msg="Find an existing session, id-00ecfd48, original direction"
2026-07-31 10:46:51 id=65308 trace_id=2914 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop"
2026-07-31 10:46:51 id=65308 trace_id=2914 func=ip_session_handle_no_dst line=6178 msg="trace"

• In working-case:
  
  

2026-07-31 10:47:07 id=65308 trace_id=2944 func=print_pkt_detail line=5906 msg="vd-root:0 received a packet(proto=6, 192.x.x.2:54784->192.y.y.72:80) tun_id=0.0.0.0 from EMB. flag [.], seq 361549190, ack 164521
0412, win 255"
2026-07-31 10:47:07 id=65308 trace_id=2944 func=resolve_ip_tuple_fast line=5994 msg="Find an existing session, id-00ed54a3, original direction"
2026-07-31 10:47:07 id=65308 trace_id=2944 func=iprope_fwd_check line=768 msg="in-[EMB], out-[ipsec], skb_flags-02000000, vid-0, app_id: 15893, url_cat_id: 0"
2026-07-31 10:47:07 id=65308 trace_id=2944 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=77, len=2"
2026-07-31 10:47:07 id=65308 trace_id=2944 func=__iprope_check_one_policy line=2033 msg="checked gnum-100004 policy-27, ret-matched, act-accept"
.......
2026-07-31 10:47:07 id=65308 trace_id=2944 func=ipsec_output_finish line=641 msg="send to A.B.C.D via intf-port1"

4. When checking the packet sniffer on the Switch, it shows that the vlan-id of the incoming packet was already changed to 1 before reaching the Firewall. That's why the packets are sent to 'Lan' switch interface, instead of 'EMB' vlan interface.
   
   

It is expected that the packets should stay in vlan-113 for proper connection:

In this case, further investigation should be done on the downstream switch or endpoint, to understand why the vlan-id was changed before reaching the Firewall.