Static IPv6 host in a SLAAC LAN – ping works, SSH connection fails

J

janedenone

My OpenWrt router is configured to advertise an IPv6 ULA prefix ( fd7d:9594:ca69::/48) to the LAN clients. One of these clients is a FreeBSD host to be used as a server with several service jails, so I want to configure it with a static IPv6 subnet. On the router, a route to this subnet is configured like this:

Code: 
config route6
        option interface 'lan'
        option target 'fdf4:aaff:c9ae:80e3::/64'
        option gateway 'fdf4:aaff:c9ae:80e3::1'

On the host, the /64 subnet is split into two /65 subnets, with the router's link-local address as the defaultrouter for the external interface, igb1 (the second /65 subnet will be assigned to a bridge interface for bastille which is not configured yet):

Code: 
ifconfig_igb1_ipv6="inet6 fdf4:aaff:c9ae:80e3::1 prefixlen 65"
ipv6_defaultrouter="fe80::9683:c4ff:feaa:be4e%igb1"
ipv6_gateway_enable="YES"
ipv6_activate_all_interfaces="YES"

With this setup, I can ping the host from any LAN client:

Code: 
# ping6 fdf4:aaff:c9ae:80e3::1
PING6(56=40+8+8 bytes) fd7d:9594:ca69:0:88a:219e:6254:9311 --> fdf4:aaff:c9ae:80e3::1
16 bytes from fdf4:aaff:c9ae:80e3::1, icmp_seq=0 hlim=63 time=14.864 ms
16 bytes from fdf4:aaff:c9ae:80e3::1, icmp_seq=1 hlim=63 time=9.488 ms

But I cannot connect to the host via SSH (connection times out). tcpdump on the host shows this:

Code: 
# tcpdump -i igb1 -vv -nn 'tcp port 22 and host fd7d:9594:ca69:0:88a:219e:6254:9311'
tcpdump: listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:17:10.254052 IP6 (class 0xb8, flowlabel 0x00800, hlim 64, next-header TCP (6) payload length: 54) fd7d:9594:ca69:0:88a:219e:6254:9311.65445 > fdf4:aaff:c9ae:80e3::1.22: Flags [P.], cksum 0x5a7e (correct), seq 1417288109:1417288131, ack 2278129201, win 2053, options [nop,nop,TS val 1910062500 ecr 1517251301], length 22: SSH: SSH-2.0-OpenSSH_10.2
09:17:10.457054 IP6 (flowlabel 0x97e30, hlim 64, next-header TCP (6) payload length: 1111) fdf4:aaff:c9ae:80e3::1.22 > fd7d:9594:ca69:0:88a:219e:6254:9311.65445: Flags [P.], cksum 0x74ef (incorrect -> 0x5005), seq 1:1080, ack 22, win 259, options [nop,nop,TS val 1517253563 ecr 1910061378], length 1079: SSH: SSH-2.0-OpenSSH_10.0 FreeBSD-20250801
09:17:11.418867 IP6 (class 0xb8, flowlabel 0x00800, hlim 64, next-header TCP (6) payload length: 54) fd7d:9594:ca69:0:88a:219e:6254:9311.65445 > fdf4:aaff:c9ae:80e3::1.22: Flags [P.], cksum 0x55f5 (correct), seq 0:22, ack 1, win 2053, options [nop,nop,TS val 1910063661 ecr 1517251301], length 22: SSH: SSH-2.0-OpenSSH_10.2
09:17:11.620062 IP6 (flowlabel 0x97e30, hlim 64, next-header TCP (6) payload length: 1111) fdf4:aaff:c9ae:80e3::1.22 > fd7d:9594:ca69:0:88a:219e:6254:9311.65445: Flags [P.], cksum 0x74ef (incorrect -> 0x4b7a), seq 1:1080, ack 22, win 259, options [nop,nop,TS val 1517254726 ecr 1910061378], length 1079: SSH: SSH-2.0-OpenSSH_10.0 FreeBSD-20250801

And this on the router:

Code: 
# tcpdump -i br-lan -vv -nn 'tcp port 22 and host fd7d:9594:ca69:0:88a:219e:6254:9311 and host fdf4:aaff:c9ae:80e3::1'
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:49:55.903696 IP6 (class 0xb8, flowlabel 0x30b00, hlim 64, next-header TCP (6) payload length: 44) fd7d:9594:ca69:0:88a:219e:6254:9311.50080 > fdf4:aaff:c9ae:80e3::1.22: Flags [S], cksum 0xb484 (correct), seq 3352321667, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3928309193 ecr 0,sackOK,eol], length 0
09:49:55.903912 IP6 (class 0xb8, flowlabel 0x30b00, hlim 63, next-header TCP (6) payload length: 44) fd7d:9594:ca69:0:88a:219e:6254:9311.50080 > fdf4:aaff:c9ae:80e3::1.22: Flags [S], cksum 0xb484 (correct), seq 3352321667, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3928309193 ecr 0,sackOK,eol], length 0
09:49:55.906682 IP6 (flowlabel 0xde79b, hlim 64, next-header TCP (6) payload length: 40) fdf4:aaff:c9ae:80e3::1.22 > fd7d:9594:ca69:0:88a:219e:6254:9311.50080: Flags [S.], cksum 0x8060 (correct), seq 771614619, ack 3352321668, win 65535, options [mss 1440,nop,wscale 8,sackOK,TS val 1941879742 ecr 3928309193], length 0
09:49:55.906725 IP6 (flowlabel 0xde79b, hlim 63, next-header TCP (6) payload length: 40) fdf4:aaff:c9ae:80e3::1.22 > fd7d:9594:ca69:0:88a:219e:6254:9311.50080: Flags [S.], cksum 0x8060 (correct), seq 771614619, ack 3352321668, win 65535, options [mss 1440,nop,wscale 8,sackOK,TS val 1941879742 ecr 3928309193], length 0

And on the client ( tcpdump -i en0 -vv 'tcp port 22 and host fdf4:aaff:c9ae:80e3::1'), the localhost address is mapped to eden.internal in /etc/hosts:

Code: 
tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
18:07:15.643543 IP6 (class 0xb8, flowlabel 0xd0f00, hlim 64, next-header TCP (6) payload length: 44) eden.internal.63497 > fdf4:aaff:c9ae:80e3::1.ssh: Flags [S], cksum 0x676d (correct), seq 3244949679, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2550467794 ecr 0,sackOK,eol], length 0
18:07:15.654294 IP6 (flowlabel 0x1dcb4, hlim 63, next-header TCP (6) payload length: 40) fdf4:aaff:c9ae:80e3::1.ssh > eden.internal.63497: Flags [S.], cksum 0x5efb (correct), seq 36822196, ack 3244949680, win 65535, options [mss 1440,nop,wscale 8,sackOK,TS val 4015278889 ecr 2550467794], length 0
18:07:15.654394 IP6 (class 0xb8, flowlabel 0xd0f00, hlim 64, next-header TCP (6) payload length: 32) eden.internal.63497 > fdf4:aaff:c9ae:80e3::1.ssh: Flags [.], cksum 0x85a4 (correct), seq 1, ack 1, win 2053, options [nop,nop,TS val 2550467805 ecr 4015278889], length 0
18:07:15.655223 IP6 (class 0xb8, flowlabel 0xd0f00, hlim 64, next-header TCP (6) payload length: 54) eden.internal.63497 > fdf4:aaff:c9ae:80e3::1.ssh: Flags [P.], cksum 0xcaac (correct), seq 1:23, ack 1, win 2053, options [nop,nop,TS val 2550467805 ecr 4015278889], length 22: SSH: SSH-2.0-OpenSSH_10.2
18:07:15.776049 IP6 (class 0xb8, flowlabel 0xd0f00, hlim 64, next-header TCP (6) payload length: 54) eden.internal.63497 > fdf4:aaff:c9ae:80e3::1.ssh: Flags [P.], cksum 0xca32 (correct), seq 1:23, ack 1, win 2053, options [nop,nop,TS val 2550467927 ecr 4015278889], length 22: SSH: SSH-2.0-OpenSSH_10.2
18:07:16.009393 IP6 (class 0xb8, flowlabel 0xd0f00, hlim 64, next-header TCP (6) payload length: 54) eden.internal.63497 > fdf4:aaff:c9ae:80e3::1.ssh: Flags [P.], cksum 0xc949 (correct), seq 1:23, ack 1, win 2053, options [nop,nop,TS val 2550468160 ecr 4015278889], length 22: SSH: SSH-2.0-OpenSSH_10.2

I can establish SSH connections to the host ( fdf4:aaff:c9ae:80e3::1) from the router itself. At which point does the routing for SSH connections fail, given that ping works? Could the difference between the between the prefix used for SLAAC clients ( fd7d:9594:ca69::/48) and for the statically routed subnet play a role here?
 
SirDice said:
Why? You have 65536 /64 prefixes available.
Click to expand...
I know, but I closely replicated the setup on one of my VPS, which has a public /64 prefix routed to it, so I had to split it into two /65. I could define an additional static route on the router for a second /64, or a single route for a /63 (and split that into two /64), but I assume this would not make a difference. The setup described in my initial post works as intended on the VPS, and I wonder whether the handling of the static IPv6 rule by my home router is at fault (although it does work for pings and for SSH connections from the router itself).
 
the shorter syn ack packet is returned to client so it's not a routing problem (well, ping works)
just the client never gets the longer ssh-id-string packet
also the server (which runs ssh) says bad checksum for he's own packets / this might be a hwsums/tso offloading missreporting but it does not do it for the shorter packets (the router tcpdump)
it may be that the offload only occurs for longer packets whatever

so lts some problem with long packets or something with tcp cksums or something it escapes me....
 
covacat said:
the shorter syn ack packet is returned to client so it's not a routing problem (well, ping works)
just the client never gets the longer ssh-id-string packet
also the server (which runs ssh) says bad checksum for he's own packets / this might be a hwsums/tso offloading missreporting but it does not do it for the shorter packets (the router tcpdump)
it may be that the offload only occurs for longer packets whatever

so lts some problem with long packets or something with tcp cksums or something it escapes me....
Click to expand...
Thanks for the hint! The connection does work as soon as I revert the server to SLAAC, so client and host can communicate successfully via SSH, just not with the static routing/addresses in place.
 
You must log in or register to reply here.
Back
Top