Dhcpv6 client doesn't complete negotiation, no delegated prefix

trendy · December 29, 2020, 5:24pm

Sorry for the delay, family obligations and I needed to verify a few things before I reply.

You are right. However with fw3 stop I get this:

Summary

root@magiatiko / > iptables-save -c 
# Generated by iptables-save v1.8.4 on Tue Dec 29 17:25:03 2020
*raw
:PREROUTING ACCEPT [643:303654]
:OUTPUT ACCEPT [79:8611]
COMMIT
# Completed on Tue Dec 29 17:25:03 2020
# Generated by iptables-save v1.8.4 on Tue Dec 29 17:25:03 2020
*nat
:PREROUTING ACCEPT [91:9384]
:INPUT ACCEPT [65:7100]
:OUTPUT ACCEPT [3:156]
:POSTROUTING ACCEPT [13:754]
:dnshijack - [0:0]
[14569:2968604] -A dnshijack -j DNAT --to-destination 10.0.2.2
[0:0] -A dnshijack -j DNAT --to-destination 10.0.2.2
COMMIT
# Completed on Tue Dec 29 17:25:03 2020
# Generated by iptables-save v1.8.4 on Tue Dec 29 17:25:03 2020
*mangle
:PREROUTING ACCEPT [645:303866]
:INPUT ACCEPT [116:16343]
:FORWARD ACCEPT [513:285837]
:OUTPUT ACCEPT [80:8755]
:POSTROUTING ACCEPT [593:294592]
COMMIT
# Completed on Tue Dec 29 17:25:03 2020
# Generated by iptables-save v1.8.4 on Tue Dec 29 17:25:03 2020
*filter
:INPUT ACCEPT [2:212]
:FORWARD ACCEPT [2:173]
:OUTPUT ACCEPT [3:276]
:banIP - [0:0]
[0:0] -A banIP -o pppoe-wan -m conntrack --ctstate NEW -m set --match-set whitelist dst -j RETURN
[0:0] -A banIP -o tun2 -m conntrack --ctstate NEW -m set --match-set whitelist dst -j RETURN
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set whitelist src -j RETURN
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set whitelist src -j RETURN
[0:0] -A banIP -p udp -m udp --sport 67:68 --dport 67:68 -j RETURN
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set blacklist src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set blacklist src -j DROP
[0:0] -A banIP -o tun2 -m conntrack --ctstate NEW -m set --match-set blacklist dst -j REJECT --reject-with icmp-port-unreachable
[0:0] -A banIP -o pppoe-wan -m conntrack --ctstate NEW -m set --match-set blacklist dst -j REJECT --reject-with icmp-port-unreachable
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set tor src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set tor src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set threat src -j DROP
[33:1452] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set threat src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set debl src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set debl src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set myip src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set myip src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set yoyo src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set yoyo src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set sslbl src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set sslbl src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set feodo src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set feodo src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set dshield src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set dshield src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set proxy src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set proxy src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set iblocklist src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set iblocklist src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set drop src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set drop src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set edrop src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set edrop src -j DROP
[0:0] -A banIP -i tun2 -m conntrack --ctstate NEW -m set --match-set bogon src -j DROP
[0:0] -A banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set bogon src -j DROP
[0:0] -A banIP -o tun2 -m conntrack --ctstate NEW -m set --match-set bogon dst -j REJECT --reject-with icmp-port-unreachable
[0:0] -A banIP -o pppoe-wan -m conntrack --ctstate NEW -m set --match-set bogon dst -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Tue Dec 29 17:25:03 2020

which means that banIP chain should not be used, because it is defined but never called.

The interesting detail I found out is that the fw3 stop doesn't have effect in ip6tables, can someone confirm this too?

I can verify now that the culprit for the dropped packets is bogon6 ipset. I added this logging line:
ip6tables -I banIP -i pppoe-wan -m conntrack --ctstate NEW -m set --match-set bogon_6 src -j LOG --log-prefix "BOGON6 :"
since that was the only entry in the banIP chain with increasing hits.
Turns out it is indeed dropping:

Tue Dec 29 18:02:58 2020 kern.warn kernel: [586990.009710] BOGON6 :IN=pppoe-wan OUT= MAC= SRC=fe80:0000:0000:0000:0000:0000:0000:010c DST=fe80:0000:0000:0000:4415:b44e:6dea:2350 LEN=161 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=547 DPT=546 LEN=121
Tue Dec 29 18:03:02 2020 kern.warn kernel: [586994.245495] BOGON6 :IN=pppoe-wan OUT= MAC= SRC=fe80:0000:0000:0000:0000:0000:0000:010c DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=187 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=5678 DPT=5678 LEN=147
Tue Dec 29 18:04:02 2020 kern.warn kernel: [587054.231104] BOGON6 :IN=pppoe-wan OUT= MAC= SRC=fe80:0000:0000:0000:0000:0000:0000:010c DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=187 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=5678 DPT=5678 LEN=147
Tue Dec 29 18:04:57 2020 kern.warn kernel: [587108.795173] BOGON6 :IN=pppoe-wan OUT= MAC= SRC=fe80:0000:0000:0000:0000:0000:0000:010c DST=fe80:0000:0000:0000:4415:b44e:6dea:2350 LEN=161 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=547 DPT=546 LEN=121

The only hits I can see are for 8000::/1 which includes the link local addresses.
This is bad aggregate as it won't let the dhcp replies from link local address.
As a workaround I have added the fc00::/6 in whitelist. Maybe something you could consider @dibdot to avoid any future problems and be in line with the default firewall rule, which allows the same for dhcp6 purposes.
Still I didn't understand why did it work sometimes and sometimes it didn't...

anon50098793 · December 30, 2020, 5:29am

still finding this unusual... but can confirm enabling the service also brought down my wan6 ( eventually ), great work trendy tracking it down... and apologies for all the wild goose chases!

dibdot · December 30, 2020, 7:55am

Thanks for the pointer! Currently I'm working on a new release and DHCPv6 is one of multiple things on my todo list. Said that this morning the new code base runs for the first time on my test device ...

root@2go_ar750s:~$ /usr/bin/banip.sh
debug banIP-0.7.0-alpha[15512] f_conf  ::: chain: banIP, log_chains (src/dst): banIP_log_src/banIP_log_dst, targets (src/dst): DROP/REJECT, lan_inputs (4/6): input_lan_rule/input_lan_rule, lan_forwards (4/6): forwarding_lan_rule/forwarding_lan_rule, wan_inputs (4/6): input_wan_rule/input_wan_rule, wan_forwards (4/6): forwarding_wan_rule/forwarding_wan_rule
info banIP-0.7.0-alpha[15512] temp base directory is '/tmp'
debug banIP-0.7.0-alpha[15512] f_temp   ::: tmp_base: /tmp, tmp_dir: /tmp/tmp.BLbIEB, pid_file: /var/run/banip.pid
debug banIP-0.7.0-alpha[15512] f_bgserv ::: status: stop, bg_pid: -, ban_realtime: true, log_service: /etc/banip/banip.service
debug banIP-0.7.0-alpha[15512] f_jsnup ::: status: running, setcnt: 0, cnt: 0
info banIP-0.7.0-alpha[15512] start banIP processing (start)
info banIP-0.7.0-alpha[15512] backup directory is '/mnt/data/banIP'
debug banIP-0.7.0-alpha[15512] f_env   ::: fetch_util: /usr/bin/curl, fetch_parm: --connect-timeout 20 --silent --show-error --location -o, ssh_daemons:  dropbear, interfaces:  trm_wwan trm_wwan6, devices:  wlan1, all_devices: eth0 br-lan eth0.1 eth0.2 wlan0 wlan1 wg0 , subnets:  192.168.254.194/24
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_4, mode: initial, chain: banIP, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_4, mode: initial, chain: banIP_log_src, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_4, mode: initial, chain: banIP_log_dst, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_6, mode: initial, chain: banIP, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_6, mode: initial, chain: banIP_log_src, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial_6, mode: initial, chain: banIP_log_dst, out_rc: 0
debug banIP-0.7.0-alpha[15512] f_ipset ::: name: initial, mode: initial, out_rc: 0

I'll contact you for testing in 2021!

trendy · December 30, 2020, 8:52am

Did you check by any chance the

?

anon50098793 · December 30, 2020, 9:24am

just tested and it worked with some delay... restarting the banip service results in rules being entered them removed again... ( which i'd guess would also be triggered on/off by subsequent ifEVENTS )

prefer to use '/etc/init.d/firewall disable; /etc/init.d/firewall stop' but i'm not sure if that would change anything here...

seems the service runs independently to the firewall... which is semi-understandable... mwan3 had some recent PR discussions about if it's possible to detect a user '/etc/init.d/firewall restart' or similar...

most services you can just /etc/init.d/banip stop... but it seems to want to be disabled first or similar so perhaps something is a little whacky with it's state machine...

in summary...

/etc/init.d/banip disable; /etc/init.d/banip stop; sleep 15
/etc/init.d/firewall disable; /etc/init.d/firewall stop #OR fw3 stop #and or maybe flush #which is less permanent than disable due to triggers

EDIT... looks like somethings gone whacky now and init.d/PROCD is not happy ( messed up the state machine somehow );

################### /etc/init.d/banip start
banIP processing failed, fatal iptables error(s) during subshell processing (Raspberry Pi 4 Model B Rev 1.1, OpenWrt SNAPSHOT r15323-7ba2f5c96f)

using the script still works;

/usr/bin/banip.sh start

dibdot · December 30, 2020, 2:30pm

@anon50098793 bottomline you'll need something like that?

Chain banIP (4 references)
 pkts bytes target     prot opt in     out     source               destination         
    1   106 RETURN     udp      *      *       fc00::/6             fc00::/6             udp spt:546 dpt:547
    0     0 DROP       all      eth3   *       ::/0                 ::/0                 ctstate NEW match-set blacklist_6 src
    0     0 REJECT     all      *      eth3    ::/0                 ::/0                 ctstate NEW match-set blacklist_6 dst reject-with icmp6-port-unreachable
[...]

anon50098793 · December 30, 2020, 2:34pm

yeah that's pretty close... there are some icmp6 typically link-local but i'm not sure thats always the case;

[6:400] -A banIP -d fe80::/64 -p ipv6-icmp -j RETURN
[1:72] -A banIP -s fe80::/64 -p ipv6-icmp -j RETURN

Warning: fe80::2a2:ff:feb2:c2 is in set bogon_6
GWIP REMOVING fe80::2a2:ff:feb2:c2 from bogon_6 > GWIP ADDING fe80::2a2:ff:feb2:c2 to bogon_6_not

( fc00::/6 above prefix was 'dynamic' ) I think some more selective jumping from input_rule to weed all all the local<->local... probably best its own chain/whitelist... ( i.e. GWIP above )

dibdot · December 30, 2020, 2:52pm

OK, added another rule ...

Chain banIP (4 references)
 pkts bytes target     prot opt in     out     source               destination         
   10  1514 RETURN     udp      *      *       fc00::/6             fc00::/6             udp spt:546 dpt:547
    0     0 RETURN     icmpv6    *      *       fe80::/64            fe80::/64           
    0     0 DROP       all      eth3   *       ::/0                 ::/0                 ctstate NEW match-set DoH_6 src
[...]

If this OK I'll open a PR to fix the current version.

anon50098793 · December 30, 2020, 3:01pm

looks pretty good... thanks very much!

i think the standard is fe/7 but check with trendy or he can test the PR and report back to speed things up...

dibdot · December 30, 2020, 3:18pm

Thanks, fixed in 0.3.13 - feel free to test the new version before merge, PR see here

trendy · December 30, 2020, 5:52pm

The ports are incorrect, source is 547 and destination 546. Also it seems that there are a couple of multicast packets dropped from the same capture sent to ports 5678. Also not to forget that icmp6 needs to be allowed as well.

dibdot · December 30, 2020, 6:43pm

Thanks! Swapped the ports, extend the link local range for icmpv6 and added port 5678 (is this another discovery port/protocol or a common DHCPv6 port)?
Now it looks like this:

Chain banIP (4 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     udp      *      *       fc00::/6             fc00::/6             multiport sports 547,5678 multiport dports 546,5678
   20  1368 RETURN     icmpv6    *      *       fe80::/10            fe80::/10           
[...]

trendy · December 30, 2020, 6:49pm

After a bit of research I found it is the Mikrotik neighbour discovery protocol, so we can ignore it. Moreover it wouldn't pass from the default firewall rules anyway. Sorry for the false alarm!

dibdot · December 30, 2020, 7:05pm

Thanks, I've updated the PR accordingly.

system · July 15, 2022, 7:36pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.