I have exhausted days trying to figure out why I am unable to access services over ipv6 port opens with nftables. At this point I feel as if something is not setup right with the development of nftables in regards to ipv6. My rule syntax is correct, are there any other kernel level factors I should look at that might be hindering accessing ports over ipv6 with fw4?
I run
sysctl -a | grep forward
And I get.
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.br-lan.bc_forwarding = 0
net.ipv4.conf.br-lan.forwarding = 1
net.ipv4.conf.br-lan.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eth0.bc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth1.bc_forwarding = 0
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.eth1.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.veth0.bc_forwarding = 0
net.ipv4.conf.veth0.forwarding = 1
net.ipv4.conf.veth0.mc_forwarding = 0
net.ipv4.conf.veth1.bc_forwarding = 0
net.ipv4.conf.veth1.forwarding = 1
net.ipv4.conf.veth1.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.br-lan.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.br-lan.stable_secret': I/O error
net.ipv6.conf.br-lan.mc_forwarding = 0
sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.eth0.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.eth1.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.eth1.stable_secret': I/O error
net.ipv6.conf.eth1.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.veth0.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.veth0.stable_secret': I/O error
net.ipv6.conf.veth0.mc_forwarding = 0
net.ipv6.conf.veth1.forwarding = 1
sysctl: error reading key 'net.ipv6.conf.veth1.stable_secret': I/O error
net.ipv6.conf.veth1.mc_forwarding = 0
jow
October 25, 2022, 7:38am
2
Do you see inbound IPv6 traffic with tcpdump?
1 Like
Jow, So far all I have seen is attempts over IPV4 on the TCP dump. No attempts being made over ipv6, however.
tcpdump -i eth0 udp -p port 51821 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:38.898719 IP (tos 0x20, ttl 55, id 35204, offset 0, flags [DF], proto UDP (17), length 176)
172.58.171.4.37443 > 73.104.49.166.51821: [udp sum ok] UDP, length 148
11:44:43.913120 IP (tos 0x20, ttl 55, id 35821, offset 0, flags [DF], proto UDP (17), length 176)
172.58.171.4.37443 > 73.104.49.166.51821: [udp sum ok] UDP, length 148
11:44:48.967778 IP (tos 0x20, ttl 55, id 36853, offset 0, flags [DF], proto UDP (17), length 176)
172.58.171.4.37443 > 73.104.49.166.51821: [udp sum ok] UDP, length 148
11:44:53.967899 IP (tos 0x20, ttl 55, id 37888, offset 0, flags [DF], proto UDP (17), length 176)
172.58.171.4.37443 > 73.104.49.166.51821: [udp sum ok] UDP, length 148
11:44:58.988026 IP (tos 0x20, ttl 55, id 38807, offset 0, flags [DF], proto UDP (17), length 176)
172.58.171.4.37443 > 73.104.49.166.51821: [udp sum ok] UDP, length 148
jow
October 25, 2022, 11:48am
4
This means no IPv6 is arriving on your system. Even if the firewall rules would be improperly set up, tcpdump should still see the inbound traffic.
jow
October 25, 2022, 11:52am
6
This port resides on the router itself?
yes on the router itself. I open the ports on both ipv4 and ipv6 to test. I am able to establish a connection over ipv4, how ever I am not on ipv6. I am connecting to a local site tunnel at that port.
ppmm
October 25, 2022, 12:06pm
8
How did you test? Make sure traffic is seen by tcpdump first.
1 Like
I am going to try to take away the DDNS service address and attempt to connect to the ipv6 address directly inside the tunnel.
Okay so it appears to be an issue with the DDNS service provider.
Here is my TCP dump using the address directly,
12:10:29.277731 IP6 (hlim 63, next-header UDP (17) payload length: 136) 2001:558:6043:31:b495:7e2f:dfc6:4d79.51821 > 2607:fb90:1267:8155:6c58:5508:e934:4899.49966: [udp sum ok] UDP, length 128
12:10:29.288903 IP6 (hlim 63, next-header UDP (17) payload length: 216) 2001:558:6043:31:b495:7e2f:dfc6:4d79.51821 > 2607:fb90:1267:8155:6c58:5508:e934:4899.49966: [udp sum ok] UDP, length 208
12:10:29.300560 IP6 (hlim 63, next-header UDP (17) payload length: 296) 2001:558:6043:31:b495:7e2f:dfc6:4d79.51821 > 2607:fb90:1267:8155:6c58:5508:e934:4899.49966: [udp sum ok] UDP, length 288
12:10:29.354043 IP6 (class 0x20, flowlabel 0x3c667, hlim 245, next-header UDP (17) payload length: 104) 2607:fb90:1267:8155:6c58:5508:e934:4899.49966 > 2001:558:6043:31:b495:7e2f:dfc6:4d79.51821: [udp sum ok] UDP, length 96
12:10:29.354043 IP6 (class 0x20, flowlabel 0x3c667, hlim 245, next-header UDP (17) payload length: 136) 2607:fb90:1267:8155:6c58:5508:e934:4899.49966 > 2001:558:6043:31:b495:7e2f:dfc6:4d79.51821: [udp sum ok] UDP, length 128
Thanks for you help!. At-least I figured something out. I need a better DDNS service provider, hah.
