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?
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.
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.
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
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.
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.
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.