Allow rule seems to get ignored on the first try

I have a LAN as well as a VLAN ("exposed"), and am trying to setup a Firewall rule wherein I can connect to a specific LAN device on port 22 from my VLAN. It works partly, but first let me provide the configuration before explaining what's wrong.


This works as you would expect, I cannot access any lan devices from exposed without a Traffic Rule.

Below is my entire /etc/config/firewall file:

/etc/config/firewall
config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        list network 'lan'
        option forward 'REJECT'
        option log '1'
        option log_limit '30/second'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config zone
        option name 'exposed'
        list network 'exposed'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'REJECT'

config forwarding
        option src 'exposed'
        option dest 'wan'

config redirect
        option dest 'exposed'
        option target 'DNAT'
        list reflection_zone 'lan'
        list reflection_zone 'exposed'
        option src 'wan'
        option src_dport '443'
        option dest_ip '192.168.3.50'
        option dest_port '443'
        option name 'nginx-https'

config redirect
        option dest 'exposed'
        option target 'DNAT'
        list reflection_zone 'lan'
        list reflection_zone 'exposed'
        option src 'wan'
        option src_dport '80'
        option dest_ip '192.168.3.50'
        option dest_port '80'
        option name 'nginx-http'

config redirect
        option dest 'exposed'
        option target 'DNAT'
        list reflection_zone 'lan'
        list reflection_zone 'exposed'
        option src 'wan'
        option src_dport '81'
        option dest_ip '192.168.3.50'
        option dest_port '81'
        option name 'nginx-admin'
        option enabled '0'

config rule
        option src 'exposed'
        option target 'REJECT'
        option name 'Block VLAN Router Input'

config rule
        option name 'Allow-VLAN-DHCP'
        option src 'exposed'
        option dest_port '67-68'
        option target 'ACCEPT'
        list proto 'udp'
        option src_port '67-68'
        list dest_ip '192.168.3.1'

config rule
        option name 'Allow-VLAN-DNS'
        option src_port '53'
        option dest_port '53'
        option target 'ACCEPT'
        option src 'exposed'
        list dest_ip '192.168.3.1'

config rule
        option name 'VLAN To Server SSH'
        option target 'ACCEPT'
        option dest 'lan'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip '192.168.3.15'
        option src 'exposed'
        list dest_ip '192.168.1.21'
        option dest_port '22'

The most notable rule is the following:

config rule
        option name 'VLAN To Server SSH'
        option target 'ACCEPT'
        option dest 'lan'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip '192.168.3.15'
        option src 'exposed'
        list dest_ip '192.168.1.21'
        option dest_port '22'

I would expect this to fully allow traffic from 192.168.3.15 (on "exposed") to access 192.168.1.21 on port 22. However, upon using a command like telnet 192.168.1.21 22, half the time I get a connection refused, and the other half it works. Bizarre
Using SFTP also only works half the time, and notably it seems to work the second try in quick succession. Once I get SFTP to connect, there is no issue with that connection either.

After enabling logging for "lan", I do see that it is getting rejected when I get the connection refused message:

Reject Log

kern.warn kernel: [13398.131800] reject lan out: IN=br-lan OUT=br-lan MAC=b0:b9:8a:5b:ec:9c:00:a0:98:1d:e7:e5:08:00 SRC=192.168.3.15 DST=192.168.1.21 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=27327 DF PROTO=TCP SPT=40342 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

I have tried the following:

  1. In Firewall > General Settings, setting Forward to accept for the top lan Zone. This DOES work, with no more connection refused messages, however obviously now any device from the VLAN can access anything on lan, which is a problem.

  2. Changing the ports and destination IP on the traffic rule, same issue with whatever target lan device or port.

  3. Changing the protocol to "Any" on the traffic rule.

I find this very odd, hopefully one of you knows better than I do.

For sake of completion, I'll include the switch configuration below as well.

Switch Config


VLAN ID 3 (eth1.3) is used by the exposed interface.

/etc/config/network:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fde1:8cba:118e::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'
        option type 'bridge'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '6t 4 3 2'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0t 5'
        option vid '2'

config interface 'exposed'
        option device 'eth1.3'
        option proto 'static'
        option ipaddr '192.168.3.1'
        option netmask '255.255.255.0'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '3'
        option ports '6t 1'

Are you certain there is proper vlan segregation?
What is the output of uci export network ?

1 Like

My second comment has the output of uci export network, as well as the visual switch config.
I'll include it here too:

uci export network

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fde1:8cba:118e::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1.1'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
option type 'bridge'

config interface 'wan6'
option device 'eth0.2'
option proto 'dhcpv6'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '6t 4 3 2'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 5'
option vid '2'

config interface 'exposed'
option device 'eth1.3'
option proto 'static'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'

config switch_vlan
option device 'switch0'
option vlan '3'
option vid '3'
option ports '6t 1'

Thanks for pointing that out, it is odd that OUT is also from br-lan, when the exposed interface uses device eth1.3.

Note that I'm not using Bridge VLAN Filtering, but the old switch method with zones. Perhaps I should change that.

Right, I didn't notice it earlier.
Anyway the configuration in the switch is not correct as it is mixing swconfig and DSA.
Either you'll delete the br-lan device and use device eth1.1 in lan ...
... or you'll convert it to DSA for all the interfaces.
What is the output of ubus call system board ?

ubus call system board
{
        "kernel": "5.10.176",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 0 (v7l)",
        "model": "Netgear Nighthawk X4S R7800",
        "board_name": "netgear,r7800",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.5",
                "revision": "r20134-5f15225c1e",
                "target": "ipq806x/generic",
                "description": "OpenWrt 22.03.5 r20134-5f15225c1e"
        }
}

Okay, so I tried the DSA method, however that doesn't seem very viable since there is no lan1, lan2, lan3, lan4 devices, but instead only the VLAN devices from the Switch config.
As stated in a comment on this post, that means that my router does not actually support DSA.

Using eth1.1 as the lan device works... however my wireless (wlan0 and wlan1) then no longer work, even though they are still set to the lan interface.

I'm confused on how to move forward, since I can't seem to bridge the wlans to eth1.1, neither using a Bridge device (only allows for VLANs), nor using a Static Address interface, as there is no Physical settings tab, and only allows for one device.

Note that switching the lan interface back to a Bridge device with Bridge """ports""" eth1.1 causes the wlans to work again.

Seems strange to me that it's like half DSA and half not in the UI.

To add to this, the random rejects still continue even when I do set the lan device to eth1.1:

Tue Sep 19 12:52:59 2023 kern.warn kernel: [29363.743048] reject lan out: IN=eth1.1 OUT=eth1.1 MAC=b0:b9:8a:5b:ec:9c:00:a0:98:1d:e7:e5:08:00:45:10:00:3c SRC=192.168.3.15 DST=192.168.1.21 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=56820 DF PROTO=TCP SPT=56578 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

A quick way, to check, if the problem is related to an potential improper migration from switchdev to DSA:

  • Make a config backup
  • reset OpenWRT to default config
  • manually add your 1 firewall rule and test the rule
  • revert, by reimporting your old config

Is the .3.15 device getting settings from DHCP or static?
Is it working fine to connect to the internet?
If you try to ping from .3.15 to 1.1.1.1 do you see in tcpdump ingress interface as eth1.3?

Internet works perfectly. Here is the tcpdump log when monitoring eth1.3 while pinging 1.1.1.1 from 192.168.1.15:

tcpdump
15:13:29.217691 IP 192.168.3.15 > one.one.one.one: ICMP echo request, id 7, seq 18, length 64
15:13:29.221210 IP one.one.one.one > 192.168.3.15: ICMP echo reply, id 7, seq 18, length 64
15:13:30.221713 IP 192.168.3.15 > one.one.one.one: ICMP echo request, id 7, seq 19, length 64
15:13:30.224729 IP one.one.one.one > 192.168.3.15: ICMP echo reply, id 7, seq 19, length 64

Also, here's the tcpdump log when I get connection refused when telnetting 192.168.1.22 port 22:

tcpdump eth1.3

15:14:52.147700 IP 192.168.1.21.22 > 192.168.3.15.47774: Flags [R.], seq 0, ack 3203592001, win 0, length 0

tcpdump eth1.1

192.168.3.15.35762 > 192.168.1.21.22: Flags [S], seq 3211513631, win 64240, options [mss 1460,sackOK,TS val 3781619202 ecr 0,nop,wscale 7], length 0

(Different attempts, thus the different source port)

Likewise when it does work:

tcpdump eth1.3
15:15:47.659652 IP 192.168.3.15.58406 > 192.168.1.21.22: Flags [S], seq 2620986458, win 64240, options [mss 1460,sackOK,TS val 3781338896 ecr 0,nop,wscale 7], length 0
15:15:47.660138 IP 192.168.1.21.22 > 192.168.3.15.58406: Flags [S.], seq 2315671920, ack 2620986459, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3839190920 ecr 3781338896], length 0
15:15:47.661051 IP 192.168.3.15.58406 > 192.168.1.21.22: Flags [.], ack 1, win 502, options [nop,nop,TS val 3781338897 ecr 3839190920], length 0
15:15:47.672071 IP 192.168.1.21.22 > 192.168.3.15.58406: Flags [P.], seq 1:31, ack 1, win 1027, options [nop,nop,TS val 3839190932 ecr 3781338897], length 30
15:15:47.672731 IP 192.168.3.15.58406 > 192.168.1.21.22: Flags [.], ack 31, win 502, options [nop,nop,TS val 3781338909 ecr 3839190932], length 0
tcpdump eth1.1

15:21:49.186948 IP 192.168.3.15.58342 > 192.168.1.21.22: Flags [S], seq 221179047, win 64240, options [mss 1460,sackOK,TS val 3781700430 ecr 0,nop,wscale 7], length 0
15:21:49.187285 IP 192.168.1.21.22 > 192.168.3.15.58342: Flags [S.], seq 2333633393, ack 221179048, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2336439281 ecr 3781700430], length 0
15:21:49.188442 IP 192.168.3.15.58342 > 192.168.1.21.22: Flags [.], ack 1, win 502, options [nop,nop,TS val 3781700432 ecr 2336439281], length 0
15:21:49.199203 IP 192.168.1.21.22 > 192.168.3.15.58342: Flags [P.], seq 1:31, ack 1, win 1027, options [nop,nop,TS val 2336439293 ecr 3781700432], length 30
15:21:49.200186 IP 192.168.3.15.58342 > 192.168.1.21.22: Flags [.], ack 31, win 502, options [nop,nop,TS val 3781700444 ecr 2336439293], length 0

Actually this makes more sense. The packet towards the SSH server is getting there but for some reason the server is refusing the connection, hence the response with a reset bit set.

That still doesn't explain the reject log:

Reject Log

kern.warn kernel: [43981.071579] reject lan out: IN=bridge OUT=bridge MAC=b0:b9:8a:5b:ec:9c:00:a0:98:1d:e7:e5:08:00 SRC=192.168.3.15 DST=192.168.1.21 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=56031 DF PROTO=TCP SPT=41258 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

(bridge is br-lan, renamed)

Or can a server rejection cause a log like that on the router too? I did test with other destination IPs and ports with the same issue, so I'm not convinced that it's fully server side.
I just tested setting the Firewall rule to my Windows device on port 80 (with a website hosted), and got the same rejection randomness.

You can get rid of these by changing the forward to allow in lan zone.

However it is not normal to see the same ingress and egress interface in the firewall logs when they are different in tcpdump.

1 Like

That allows for my VLAN to be able to access any device on my LAN, which is a major problem, but it does fix the rejection randomness.

Any other ideas?

I take that back, only some devices can be accessed, not sure why.
Specifically it seems to be my server 192.168.1.21 that is accessible on any open port when lan Forward is set to accept, however I then have the randomness there, with it rejecting half the time.

I tried disabling all non-default Firewall rules too, and could still access my server on any open port, with the randomness.

Is this normal to have 2 CPU ports 0t and 6t on the same switch0?

Check the output:

swconfig list; swconfig dev switch0 show

I'm pretty sure it's normal on some routers, a screenshot in here shows an almost identical setup minus the VLAN:

swconfig list; swconfig dev switch0 show
Found: switch0 - 37000000.mdio-mii
Global attributes:
        enable_vlan: 1
        ar8xxx_mib_poll_interval: 0
        ar8xxx_mib_type: 0
        enable_mirror_rx: 0
        enable_mirror_tx: 0
        mirror_monitor_port: 0
        mirror_source_port: 0
        arl_age_time: 300
        arl_table: address resolution table
Port 0: MAC b0:b9:8a:5b:ec:9d
Port 1: MAC 00:a0:98:1e:6e:96
Port 1: MAC 98:ee:cb:56:f2:d1
Port 1: MAC 00:a0:98:12:46:a1
Port 1: MAC 00:25:90:2d:08:46
Port 1: MAC 02:25:90:54:55:8d
Port 1: MAC 00:a0:98:16:13:95
Port 1: MAC 00:a0:98:1d:e7:e5
Port 1: MAC 80:2b:f9:ac:27:1d
Port 1: MAC 50:d4:f7:f8:62:d0
Port 1: MAC 32:31:4f:be:1a:aa
Port 1: MAC c8:d0:83:e0:8b:20
Port 2: MAC 50:d4:f7:f8:62:d0
Port 2: MAC c8:d0:83:e0:8b:20
Port 3: MAC 02:25:90:54:55:8d
Port 3: MAC 00:a0:98:16:13:95
Port 3: MAC 00:a0:98:1d:e7:e5
Port 3: MAC 00:a0:98:1e:6e:96
Port 3: MAC 00:a0:98:12:46:a1
Port 3: MAC 00:25:90:2d:08:46
Port 3: MAC 00:25:90:2c:de:0b
Port 4: MAC 98:ee:cb:56:f2:d1
Port 5: MAC f6:b5:2f:a2:09:9a
Port 6: MAC 80:2b:f9:ac:27:1d
Port 6: MAC b0:b9:8a:5b:ec:9c
Port 6: MAC 32:31:4f:be:1a:aa

        igmp_snooping: 0
        igmp_v3: 0
Port 0:
        mib: ???
        enable_eee: ???
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex
Port 1:
        mib: ???
        enable_eee: 0
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 3
        link: port:1 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 2:
        mib: ???
        enable_eee: 0
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 1
        link: port:2 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 3:
        mib: ???
        enable_eee: 0
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 1
        link: port:3 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 4:
        mib: ???
        enable_eee: 0
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 1
        link: port:4 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 5:
        mib: ???
        enable_eee: 0
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 2
        link: port:5 link:up speed:1000baseT full-duplex auto
Port 6:
        mib: ???
        enable_eee: ???
        igmp_snooping: 0
        vlan_prio: 0
        pvid: 0
        link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
        vid: 1
        ports: 2 3 4 6t
VLAN 2:
        vid: 2
        ports: 0t 5
VLAN 3:
        vid: 3
        ports: 1 6t
1 Like

Temporarily allow forwarding and try capturing like this:

# Router
tcpdump -evnni any icmp

# Host 192.168.3.15
ping -c 1 192.168.1.21
1 Like

I have a theory, perhaps it has to do with my source device (192.168.3.15) using the same NIC as my server (192.168.1.21), as it's a VM inside the server using the second interface/port. Perhaps some tomfoolery is going on there. I theorize this because it's only that device which 192.168.3.15 can seem to access. Not sure how to test that.
I can also access my separate Windows device on 192.168.1.240 port 80, but not my other services like 192.168.1.45:8080 (qBittorrent).

Anyways, here's what you requested with lan Forward set to accept and no Firewall rules @vgaetera:

tcpdump -evnni any icmp
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
17:48:48.819907  In 00:a0:98:1d:e7:e5 ethertype 802.1Q (0x8100), length 104: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 15005, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.3.15 > 192.168.1.21: ICMP echo request, id 10, seq 1, length 64
17:48:48.819907  In 00:a0:98:1d:e7:e5 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 15005, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.3.15 > 192.168.1.21: ICMP echo request, id 10, seq 1, length 64
17:48:48.819907  In 00:a0:98:1d:e7:e5 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 15005, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.3.15 > 192.168.1.21: ICMP echo request, id 10, seq 1, length 64
17:48:48.820050 Out b0:b9:8a:5b:ec:9c ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 15005, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.3.15 > 192.168.1.21: ICMP echo request, id 10, seq 1, length 64
17:48:48.820068 Out b0:b9:8a:5b:ec:9c ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 15005, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.3.15 > 192.168.1.21: ICMP echo request, id 10, seq 1, length 64
17:48:48.820535  In 00:25:90:2d:08:46 ethertype 802.1Q (0x8100), length 104: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.21 > 192.168.3.15: ICMP echo reply, id 10, seq 1, length 64
17:48:48.820535  In 00:25:90:2d:08:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.21 > 192.168.3.15: ICMP echo reply, id 10, seq 1, length 64
17:48:48.820535  In 00:25:90:2d:08:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.21 > 192.168.3.15: ICMP echo reply, id 10, seq 1, length 64
17:48:48.820600 Out b0:b9:8a:5b:ec:9c ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.21 > 192.168.3.15: ICMP echo reply, id 10, seq 1, length 64

Note that all pings work perfectly, it's only when I try to make a connection with telnet/ssh/browser that it rejects randomly. I tried with telnet 192.168.1.21 22 too, but no tcpdump icmp readings for that at all.

1 Like

It arrives as tagged VLAN 1 from the MAC mapped to ports 1 and 3:

Why the same MAC is mapped to ports on different VLANs?
Try to cold boot the router.

1 Like