"Drop invalid packets" prevents ssh over lan

My router is a Netgear R6220 running openwrt 21.02. This is the error I get when I try to ssh from my computer to a pi or laptop over lan:

$ ssh 192.168.1.52
kex_exchange_identification: read: Connection reset by peer

If I go to Network > Firewall > General Settings and uncheck the Drop invalid packets box, and save, the ssh connections work fine. If I recheck the box, I get the error again.

So, is there a good way to log which packets are being dropped by this setting?

Post your firewall settings -

cat /etc/config/firewall

/etc/config/firewall

config defaults
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option input 'REJECT'
	option synflood_protect '1'
	option drop_invalid '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

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 src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	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 rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled '0'

config include
	option path '/etc/firewall.user'

config zone
	option name 'slvit'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	list network 'slvit'

config zone
	option output 'ACCEPT'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option name 'gf4'
	option masq '1'
	list network 'gf4'

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

config forwarding
	option dest 'lan'
	option src 'gf4'

config forwarding
	option dest 'wan'
	option src 'gf4'

config forwarding
	option src 'lan'
	option dest 'gf4'

config redirect
	option target 'DNAT'
	option dest 'lan'
	option dest_ip '192.168.7.88'
	option src 'slvit'
	list proto 'tcp'
	list proto 'udp'
	option src_dport '5060'
	option name 'SIP to tga8001-1'

config redirect
	option target 'DNAT'
	list proto 'udp'
	option src 'slvit'
	option dest 'lan'
	option dest_ip '192.168.7.88'
	option src_dport '10000-10100'
	option name 'RTP media to tga8001'

config redirect
	option target 'DNAT'
	option src 'slvit'
	option src_dport '5004'
	option dest 'lan'
	option dest_ip '192.168.7.88'
	option name 'RTP to tga8001-1'
	option dest_port '5004'

config forwarding
	option src 'slvit'
	option dest 'lan'

config forwarding
	option src 'slvit'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'slvit'

config redirect
	option target 'DNAT'
	option name 'Urt to ksx'
	list proto 'udp'
	option src 'gf4'
	option dest 'lan'
	option dest_ip '192.168.7.139'
	option src_dport '27960-27961'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option src 'slvit'
	option src_dport '5012'
	option dest_ip '192.168.7.88'
	option dest_port '5012'
	option name 'RTP to tga8001-2'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'SIP to tga8001-2'
	option src 'slvit'
	option src_dport '5062'
	option dest_ip '192.168.7.88'
	option dest_port '5062'

Also, according to this stackoverflow answer about the ssh error:

When an ssh client connects to an ssh server, the server starts by sending a version string to the client. The error that you're getting means that the TCP connection from the client to the server was "abnormally closed" while the client was waiting for this data from the server, in other words immediately after the TCP connection was opened.

So it seems like the tcp connection opens, but the ssh version string is dropped by owrt as "invalid".

This checkbox adds the -m conntrack --ctstate INVALID -m comment --comment "!fw3" -j DROP in INPUT, OUTPUT, and FORWARD. You can check the logs what is dropped, but most likely you have asymmetric routing. If a packet is marked as invalid, it means that not all packets of the handshake were tracked by the firewall.

2 Likes

I see. Both the laptop and desktop are plugged into the router's lan via ethernet so there should only be one path. Neither computer is on wifi. The routing tables on my computer and router look correct. I haven't touched the routing on the laptop so it should just have a default route to the router.

I noticed this interesting behavior when trying to ping the laptop from the computer. Not sure if it's related or not. It only happens when I ping the laptop from the computer; I can ping the laptop from the router and the router from the computer without errors.

$ ping 192.168.7.135
PING 192.168.7.135 (192.168.7.135) 56(84) bytes of data.
64 bytes from 192.168.7.135: icmp_seq=1 ttl=64 time=1.27 ms
From 192.168.7.1 icmp_seq=2 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=2 ttl=64 time=1.16 ms
From 192.168.7.1 icmp_seq=3 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=3 ttl=64 time=1.18 ms
From 192.168.7.1 icmp_seq=4 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=4 ttl=64 time=1.22 ms
From 192.168.7.1 icmp_seq=5 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=5 ttl=64 time=1.19 ms
From 192.168.7.1 icmp_seq=6 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=6 ttl=64 time=1.34 ms
64 bytes from 192.168.7.135: icmp_seq=7 ttl=64 time=0.999 ms
From 192.168.7.1 icmp_seq=8 Redirect Host(New nexthop: 135.7.168.192)
64 bytes from 192.168.7.135: icmp_seq=8 ttl=64 time=1.13 ms
64 bytes from 192.168.7.135: icmp_seq=9 ttl=64 time=1.21 ms
^C
--- 192.168.7.135 ping statistics ---
9 packets transmitted, 9 received, +6 errors, 0% packet loss, time 8008ms
rtt min/avg/max/mdev = 0.999/1.188/1.342/0.089 ms

I'm really lost about what this reverse IP address could mean. It happens with domain names too, so maybe it's some kind of overzealous rDNS?

$ ping bhp.lan
PING bhp.lan (192.168.7.135) 56(84) bytes of data.
64 bytes from bhp.lan (192.168.7.135): icmp_seq=1 ttl=64 time=1.15 ms
From knr.lan (192.168.7.1) icmp_seq=2 Redirect Host(New nexthop: 192.168.7.135.in-addr.arpa (135.7.168.192))
64 bytes from bhp.lan (192.168.7.135): icmp_seq=2 ttl=64 time=1.20 ms
From knr.lan (192.168.7.1) icmp_seq=3 Redirect Host(New nexthop: 192.168.7.135.in-addr.arpa (135.7.168.192))
64 bytes from bhp.lan (192.168.7.135): icmp_seq=3 ttl=64 time=1.36 ms
From knr.lan (192.168.7.1) icmp_seq=4 Redirect Host(New nexthop: 192.168.7.135.in-addr.arpa (135.7.168.192))
64 bytes from bhp.lan (192.168.7.135): icmp_seq=4 ttl=64 time=1.28 ms
From knr.lan (192.168.7.1) icmp_seq=5 Redirect Host(New nexthop: 192.168.7.135.in-addr.arpa (135.7.168.192))
64 bytes from bhp.lan (192.168.7.135): icmp_seq=5 ttl=64 time=1.20 ms
^C
--- bhp.lan ping statistics ---
5 packets transmitted, 5 received, +4 errors, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.152/1.238/1.361/0.073 ms

iptables is on the frontier of my knowledge, so if you already know the command to get logs on which packets are being dropped, please post it. Otherwise I will do a little more research on this later and post back if I find anything. I am just leaving the box unchecked for now.

Thats not reverse DNS. The router at 192.168.7.1 is telling clients in the same LAN that the gateway to reach 192.168.7.135 is actually 135.7.168.192?

Do you recall making such a config or having 2 routers in your LAN?

1 Like

I didn't set these routes. I mean it exactly reverses the IP for any lan device. Here is my ATA:

$ ping 192.168.7.88
PING 192.168.7.88 (192.168.7.88) 56(84) bytes of data.
64 bytes from 192.168.7.88: icmp_seq=1 ttl=64 time=1.67 ms
From 192.168.7.1 icmp_seq=2 Redirect Host(New nexthop: 88.7.168.192)

There is no other router but there is a load-balancer. The WAN port of the router connects to another owrt device (192.168.7.2) running mwan3 as a load-balancer. That device is then connected to 3 wifi antennas (192.168.7.3-5). All those devices (.2-.5) have static routes in the router. The router serves dhcp to LAN from 192.168.7.10 to 192.168.7.250.

So anyways, from my computer, I can ping any of those devices over the static routes and don't get the errors with reversed IP addresses:

$ ping 192.168.7.4
PING 192.168.7.4 (192.168.7.4) 56(84) bytes of data.
64 bytes from 192.168.7.4: icmp_seq=1 ttl=62 time=1.79 ms
64 bytes from 192.168.7.4: icmp_seq=2 ttl=62 time=1.63 ms
64 bytes from 192.168.7.4: icmp_seq=3 ttl=62 time=1.65 ms
64 bytes from 192.168.7.4: icmp_seq=4 ttl=62 time=1.54 ms

Does openwrt use the same iputils package as ubuntu? Because there is this bug: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1892108

I'm not sure...but why is your router redirecting?

I assume you still wish to solve that.

  • What is its IP?
  • Does it router (i.e. a router)?

You do set gateways though.

I mean I never set routes for the 135... address. It looks like that is a bug in ping and only affects the display though. So when I try to ping 192.168.7.135, it's trying to redirect to 192.168.7.135?

The load-balancer is on 192.168.7.2. The router is 192.168.7.1 on both its lan and wan interfaces. I can disable the wan interface and still get the problem on lan though.

Here's all the routes on the router. (10.7.0.0/16 and 10.4.0.0/16 are VPNs.)

# ip route
default via 192.168.7.2 dev wan  metric 10
10.4.0.0/16 dev gf4 scope link  src 10.4.1.6
10.7.0.0/16 dev slvit scope link  src 10.7.1.6
10.7.0.2 dev slvit scope link
10.7.0.3 dev slvit scope link
10.7.0.101 dev slvit scope link
192.168.7.0/24 dev br-lan scope link  src 192.168.7.1
192.168.7.1 dev wan scope link  metric 10
192.168.7.2 dev wan scope link  metric 10
192.168.7.3 via 192.168.7.2 dev wan  metric 10
192.168.7.4 via 192.168.7.2 dev wan  metric 10
192.168.7.5 via 192.168.7.2 dev wan  metric 10

Oh, you know what, maybe I need to remove the route to 192.168.7.1 via wan...

I ran ip route del 192.168.7.1 dev wan and no longer get the ping errors:

$ ping 192.168.7.135
PING 192.168.7.135 (192.168.7.135) 56(84) bytes of data.
64 bytes from 192.168.7.135: icmp_seq=1 ttl=64 time=1.14 ms
64 bytes from 192.168.7.135: icmp_seq=2 ttl=64 time=1.16 ms
64 bytes from 192.168.7.135: icmp_seq=3 ttl=64 time=1.16 ms

But my ssh connections are still being dropped when the box is checked. Could be caused by having the same IP on two interfaces though... I will try setting a different one later.

1 Like

IPs must be unique and you should not be adding routes if you don't know what they are doing. Restore the proper addresses and everything will work fine.

2 Likes

I didn't add that route, it was added automatically by the wan interface. I don't know what you mean by "proper addresses".

Edit: Oh, you mean unique IPs for each interface? I'm trying this now...

Unique addresses, you cannot have 192.168.7.X on lan and wan.

1 Like

So I changed the lan IP on the router to 192.168.7.6 and the wan is still 192.168.7.1, but the lan is still set to /24. So probably I need to move all the wan devices to a separate network. I don't have time for it today... right now everything works if I leave the box unchecked.