You are not logged in.
Hello,
I'm trying to setup working IPv6 and nftables but router solicitation not working until I disable firewall. This Arch linux is KVM VM with dhcpcd.
Here is my NFT inet filter:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy accept
ct state invalid drop
ct state related,established accept
iifname lo accept
ip6 nexthdr icmpv6 meta nftrace set 1
ip6 nexthdr icmpv6 accept
ip protocol icmp icmp type echo-request accept
ip protocol icmp drop
ct state new tcp dport 22 accept
ct state new tcp dport 80 accept
ct state new tcp dport 443 accept
ct state new udp dport 51820 accept
reject with icmpx type no-route
}
chain forward {
type filter hook forward priority 0; policy drop
iifname wg0 oifname ens18 accept
iifname ens18 oifname wg0 ct state related,established accept
counter
}
chain output {
type filter hook output priority 0; policy accept
}
}
When I try to monitor icmpv6 I can see this:
trace id 09532288 inet filter input packet: iif "ens18" ether saddr c4:b2:39:14:28:3f ether daddr 33:33:00:00:00:01 ip6 saddr fe80::c6b2:39ff:fe14:283f ip6 daddr ff02::1 ip6 dscp cs7 ip6 ecn not-ect ip6 hoplimit 255 ip6 flowlabel 0 ip6 nex
thdr ipv6-icmp ip6 length 64 icmpv6 type nd-router-advert icmpv6 code no-route icmpv6 parameter-problem 1086850824 @th,64,96 16893106
IDK what's wrong because without nftables everything works fine. Router is Catalyst 9500
Can somebody help me?
Many thanks
Offline
I couldn't find out why, but workstation and server examples on archlinux nftables page use ipv6-icmp AND icmpv6 .
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
As already stated by @Lone_Wolf, you need to enable neighbour solicitation.
Here's the relevant excerpt (last line) from our (Debian) server:
table inet filter {
chain input {
type filter hook input priority 0; policy accept;
ct state { established, related } accept
ct state invalid drop
ip protocol icmp accept
ip protocol ipv6-icmp accept
icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } ip6 hoplimit 255 counter packets 5111 bytes 339072 accept
Last edited by schard (2020-11-12 13:05:26)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
As already stated by @Lone_Wolf, you need to enable neighbour solicitation.
Here's the relevant excerpt (last line) from our (Debian) server:table inet filter { chain input { type filter hook input priority 0; policy accept; ct state { established, related } accept ct state invalid drop ip protocol icmp accept ip protocol ipv6-icmp accept icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } ip6 hoplimit 255 counter packets 5111 bytes 339072 accept
So the main problem is that I haven't enabled nd-neighbor-solicit in "default" types of ICMPv6?
Okay, I will try and give you a feedback
Offline
My default route disapeared again
# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2001:718:2:40::/64 dev ens18 proto ra metric 202 mtu 1500 pref high
fe80::/64 dev ens18 proto kernel metric 256 pref medium
I have a lot of parameter problems in `nft monitor trace` too
trace id d6d869ab inet filter input packet: iif "ens18" ether saddr c4:b2:39:14:28:3f ether daddr 33:33:00:00:00:01 ip6 saddr fe80::c6b2:39ff:fe14:283f ip6 daddr ff02::1 ip6 dscp cs7 ip6 ecn not-ect ip6 hoplimit 255 ip6 flowlabel 0 ip6 nexthdr ipv6-icmp ip6 length 64 icmpv6 type nd-router-advert icmpv6 code no-route icmpv6 parameter-problem 1086850824 @th,64,96 16893106
Offline
My default route disapeared again
# ip -6 r ::1 dev lo proto kernel metric 256 pref medium 2001:718:2:40::/64 dev ens18 proto ra metric 202 mtu 1500 pref high fe80::/64 dev ens18 proto kernel metric 256 pref medium
I have a lot of parameter problems in `nft monitor trace` too
trace id d6d869ab inet filter input packet: iif "ens18" ether saddr c4:b2:39:14:28:3f ether daddr 33:33:00:00:00:01 ip6 saddr fe80::c6b2:39ff:fe14:283f ip6 daddr ff02::1 ip6 dscp cs7 ip6 ecn not-ect ip6 hoplimit 255 ip6 flowlabel 0 ip6 nexthdr ipv6-icmp ip6 length 64 icmpv6 type nd-router-advert icmpv6 code no-route icmpv6 parameter-problem 1086850824 @th,64,96 16893106
What I'm doing wrong?
I've tried both types of rules:
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept
and
ip6 nexthdr ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept
... but it only works when I disable `nftables` filtering. It's happening even on Debian 10. Routers are Cisco 9000 series. I think I'm doing something wrong but IDK what.
Thank you for any help
Offline
Normally routes don't change unless network connections change, let's look at your network setup .
What dhcp client / network management tool are you using ?
Static or dynamic ip-addresses, are there temporary connections like those used for vpns ?
post
$ ip link show
$ ip address show
# journalctl -b -g route
If desired you can blank out parts of public ip addresses ( 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255 and 192.168.0.0 to 192.168.255.255 are private and don't need blanking).
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Normally routes don't change unless network connections change, let's look at your network setup .
What dhcp client / network management tool are you using ?
Static or dynamic ip-addresses, are there temporary connections like those used for vpns ?post
$ ip link show $ ip address show
# journalctl -b -g route
If desired you can blank out parts of public ip addresses ( 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255 and 192.168.0.0 to 192.168.255.255 are private and don't need blanking).
This setup is KVM VM with dhcpcd. I have static IPv6 but I can do it both ways bcs we have a DHCPv6 server.
I have this server also as WG "VPN server".
# ip l sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether f6:89:ba:4e:98:31 brd ff:ff:ff:ff:ff:ff
altname enp0s18
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
# ip a sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether f6:89:ba:4e:98:31 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 147.32.30.41/25 brd 147.32.30.127 scope global dynamic noprefixroute ens18
valid_lft 584sec preferred_lft 359sec
inet6 fe80::f489:baff:fe4e:9831/64 scope link
valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.181.191.1/24 scope global wg0
valid_lft forever preferred_lft forever
# journalctl -b -g route
-- Logs begin at Fri 2020-04-03 23:33:49 CEST, end at Fri 2020-11-20 14:28:21 CET. --
Nov 19 14:08:59 dusatvoj-vm systemd-sysctl[217]: Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
Nov 19 14:08:59 dusatvoj-vm systemd-sysctl[217]: Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
Nov 19 14:09:03 dusatvoj-vm dhcpcd[278]: ens18: soliciting an IPv6 router
Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: Router Advertisement from fe80::c6b2:39ff:fe14:283f
Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: no global addresses for default route
Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: adding route to 2001:718:2:40::/64
Nov 19 14:09:09 dusatvoj-vm dhcpcd[278]: ens18: adding route to 147.32.30.0/25
Nov 19 14:09:09 dusatvoj-vm dhcpcd[278]: ens18: adding default route via 147.32.30.1
Nov 19 14:18:13 dusatvoj-vm dhcpcd[278]: ens18: adding default route via fe80::c6b2:39ff:fe14:283f
Nov 19 16:18:13 dusatvoj-vm dhcpcd[278]: ens18: deleting default route via fe80::c6b2:39ff:fe14:283f
Offline
Nov 19 14:09:03 dusatvoj-vm dhcpcd[278]: ens18: soliciting an IPv6 router
Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: Router Advertisement from fe80::c6b2:39ff:fe14:283f
Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: no global addresses for default route
Nov 19 14:18:13 dusatvoj-vm dhcpcd[278]: ens18: adding default route via fe80::c6b2:39ff:fe14:283f
Nov 19 16:18:13 dusatvoj-vm dhcpcd[278]: ens18: deleting default route via fe80::c6b2:39ff:fe14:283f
There appear to be two problems (that could have the same cause)
disable nftables temporarily, disconnect & reconnect network (or reboot) .
run journalctl -b -g route again and compare the outputs.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I couldn't find out why, but workstation and server examples on archlinux nftables page use ipv6-icmp AND icmpv6 .
"ipv6-icmp" is the layer 4 protocol while "icmpv6 type ..." allows to filter by type. To simply allow ICMPv6, this should be enough (all type will be allowed):
meta l4proto ipv6-icmp accept
And the wiki uses "meta l4proto" is used instead of "ip6 nexthdr" because the matched ICMPv6 type may not be inside the "next header". See https://ao2.it/en/blog/2018/04/27/nftab … ons-header .
Offline
Nov 19 14:09:03 dusatvoj-vm dhcpcd[278]: ens18: soliciting an IPv6 router Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: Router Advertisement from fe80::c6b2:39ff:fe14:283f Nov 19 14:09:04 dusatvoj-vm dhcpcd[278]: ens18: no global addresses for default route
Nov 19 14:18:13 dusatvoj-vm dhcpcd[278]: ens18: adding default route via fe80::c6b2:39ff:fe14:283f Nov 19 16:18:13 dusatvoj-vm dhcpcd[278]: ens18: deleting default route via fe80::c6b2:39ff:fe14:283f
There appear to be two problems (that could have the same cause)
disable nftables temporarily, disconnect & reconnect network (or reboot) .
run journalctl -b -g route again and compare the outputs.
I've done reboot with systemctl disable nftables.service fail2ban.service.
There's a result:
~# journalctl -b -g route
-- Logs begin at Fri 2020-04-03 23:33:49 CEST, end at Sun 2020-11-22 15:11:20 CET. --
Nov 21 18:59:08 dusatvoj-vm systemd-sysctl[222]: Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
Nov 21 18:59:08 dusatvoj-vm systemd-sysctl[222]: Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
Nov 21 18:59:10 dusatvoj-vm dhcpcd[278]: ens18: soliciting an IPv6 router
Nov 21 18:59:11 dusatvoj-vm dhcpcd[278]: ens18: Router Advertisement from fe80::c6b2:39ff:fe14:283f
Nov 21 18:59:11 dusatvoj-vm dhcpcd[278]: ens18: no global addresses for default route
Nov 21 18:59:11 dusatvoj-vm dhcpcd[278]: ens18: adding route to 2001:718:2:40::/64
Nov 21 18:59:13 dusatvoj-vm dhcpcd[278]: ens18: adding default route via fe80::c6b2:39ff:fe14:283f
No route deleted
Offline
Lone_Wolf wrote:I couldn't find out why, but workstation and server examples on archlinux nftables page use ipv6-icmp AND icmpv6 .
"ipv6-icmp" is the layer 4 protocol while "icmpv6 type ..." allows to filter by type. To simply allow ICMPv6, this should be enough (all type will be allowed):
meta l4proto ipv6-icmp accept
And the wiki uses "meta l4proto" is used instead of "ip6 nexthdr" because the matched ICMPv6 type may not be inside the "next header". See https://ao2.it/en/blog/2018/04/27/nftab … ons-header .
Thank you, good point.
I think I've tried that but I will try next time.
Offline
Same with meta l4proto
trace id 3a1e9d49 inet filter input packet: iif "ens18" ether saddr c4:b2:39:14:28:3f ether daddr 33:33:00:00:00:01 ip6 saddr fe80::c6b2:39ff:fe14:283f ip6 daddr ff02::1 ip6 dscp cs7 ip6 ecn not-ect ip6 hoplimit 255 ip6 flowlabel 0 ip6 nexthdr ipv6-icmp ip6 length 64 icmpv6 type nd-router-advert icmpv6 code no-route icmpv6 parameter-problem 1086850824 @th,64,96 16893106
trace id 3a1e9d49 inet filter input rule meta l4proto ipv6-icmp meta nftrace set 1 (verdict continue)
trace id 3a1e9d49 inet filter input rule meta l4proto ipv6-icmp accept (verdict accept)
... with nft rules:
meta l4proto ipv6-icmp meta nftrace set 1
meta l4proto ipv6-icmp accept
Offline
Same with meta l4proto
trace id 3a1e9d49 inet filter input packet: iif "ens18" ether saddr c4:b2:39:14:28:3f ether daddr 33:33:00:00:00:01 ip6 saddr fe80::c6b2:39ff:fe14:283f ip6 daddr ff02::1 ip6 dscp cs7 ip6 ecn not-ect ip6 hoplimit 255 ip6 flowlabel 0 ip6 nexthdr ipv6-icmp ip6 length 64 icmpv6 type nd-router-advert icmpv6 code no-route icmpv6 parameter-problem 1086850824 @th,64,96 16893106
trace id 3a1e9d49 inet filter input rule meta l4proto ipv6-icmp meta nftrace set 1 (verdict continue)
trace id 3a1e9d49 inet filter input rule meta l4proto ipv6-icmp accept (verdict accept)
... with nft rules:
meta l4proto ipv6-icmp meta nftrace set 1
meta l4proto ipv6-icmp accept
Offline
Sorry for the late reply to a zombie thread, but after ripping my hair out over this same issue for an entire day, I figured I'd contribute the seemingly simple solution for any other poor souls:
This did the trick for me:
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
meta l4proto ipv6-icmp accept
ip6 ecn not-ect accept
}
}
Notice that the packet you captured is an ECN packet, just like mine (except mine had ip6 hoplimit 1 from a link-local fe80::/10 saddr, while yours has ip6 hoplimit 255). It seems this packet must be accepted in order to get assigned an IPv6 block by my ISP (Spectrum Broadband), and perhaps you're having similar difficulties related to these ECN packets.
Offline