Ich möchte mich mal wieder um eine Pendenz kümmern.
Und zwar suche ich eine Anleitung oder Erfolgsmeldung zur folgender Aufgabe:
Abo:
Setup:
Ausgangslage:
Weniger gesucht ist eine "Anleitung", bzw Screenshot aus dem Zyxel Frickekeller der Swisscom sondern etwas was live im Feld auch tatsächlich funktioniert. Ersteres habe ich schon.
Freue mich über Antworten.
pfSense scheint da zwei Probleme zu haben:
1. Die Firewall blockiert die einkommenden Antworten vom DHCPv6-Server, da diese von einem zufälligen Quellport kommen, pfSense aber nur Pakete vom Quellport 547 zulässt. Dies kann man in /etc/inc/filter.inc ändern:
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 tracker {$increment_tracker($tracker)} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr'
]}")}"
ersetzen durch
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from fe80::/10 to fe80::/10 port = 546 tracker {$increment_tracker($tracker)} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr'
]}")}"
2. Damit stösst man dann auf das eigentliche Problem: Die CB2 schickt eine Option zur Authentisierung der DHCPv6-Nachrichten, an welcher sich die pfSense verschluckt.
/usr/local/sbin/dhcp6c -D -f -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_vr0.pid vr0
Jan/16/2017 14:13:31: set client ID (len 14)
Jan/16/2017 14:13:31: set identity association
Jan/16/2017 14:13:31: set elapsed time (len 2)
Jan/16/2017 14:13:31: set option request (len 4)
Jan/16/2017 14:13:31: set IA_PD
Jan/16/2017 14:13:31: send solicit to ff02::1:2%vr0
Jan/16/2017 14:13:31: reset a timer on vr0, state=SOLICIT, timeo=6, retrans=68413
Jan/16/2017 14:13:31: receive advertise from fe80::ea74:e6ff:feab:c4f2%vr0 on vr0
Jan/16/2017 14:13:31: get DHCP option client ID, len 14
Jan/16/2017 14:13:31: DUID: 00:01:00:01:20:0f:7d:87:00:0d:b9:12:d3:d0
Jan/16/2017 14:13:31: get DHCP option server ID, len 14
Jan/16/2017 14:13:31: DUID: 00:01:00:01:1f:9c:c7:99:e8:74:e6:ab:c4:f3
Jan/16/2017 14:13:31: get DHCP option identity association, len 46
Jan/16/2017 14:13:31: IA_NA: ID=0, T1=1799, T2=2878
Jan/16/2017 14:13:31: get DHCP option status code, len 2
Jan/16/2017 14:13:31: status code: success
Jan/16/2017 14:13:31: get DHCP option IA address, len 24
Jan/16/2017 14:13:31: IA_NA address: 2a02:121f:26::1:1 pltime=3598 vltime=4798
Jan/16/2017 14:13:31: get DHCP option IA_PD, len 47
Jan/16/2017 14:13:31: IA_PD: ID=0, T1=1799, T2=2878
Jan/16/2017 14:13:31: get DHCP option status code, len 2
Jan/16/2017 14:13:31: status code: success
Jan/16/2017 14:13:31: get DHCP option IA_PD prefix, len 25
Jan/16/2017 14:13:31: IA_PD prefix: 2a02:121f:26:8000::/52 pltime=3598 vltime=4798
Jan/16/2017 14:13:31: get DHCP option authentication, len 28
Jan/16/2017 14:13:31: proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: dc27 457b 8ab9 2094
Jan/16/2017 14:13:31: unsupported authentication protocol: 1
Jan/16/2017 14:13:31: failed to parse options
Da müsste man also entweder den dhcp6c so anpassen, dass er eine unbekannte Auth-Option einfach ignoriert oder er diese versteht. Die einfachere Variante ist, dass der DHCPv6-Server der CB2 diese nicht mehr verschickt. Ich konzentriere mich auf die zweite Variante, da die Authentisierung in der Praxis nicht verbreitet ist.
pfSense scheint da zwei Probleme zu haben:
1. Die Firewall blockiert die einkommenden Antworten vom DHCPv6-Server, da diese von einem zufälligen Quellport kommen, pfSense aber nur Pakete vom Quellport 547 zulässt. Dies kann man in /etc/inc/filter.inc ändern:
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 tracker {$increment_tracker($tracker)} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr'
]}")}"
ersetzen durch
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from fe80::/10 to fe80::/10 port = 546 tracker {$increment_tracker($tracker)} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr'
]}")}"
2. Damit stösst man dann auf das eigentliche Problem: Die CB2 schickt eine Option zur Authentisierung der DHCPv6-Nachrichten, an welcher sich die pfSense verschluckt.
/usr/local/sbin/dhcp6c -D -f -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_vr0.pid vr0
Jan/16/2017 14:13:31: set client ID (len 14)
Jan/16/2017 14:13:31: set identity association
Jan/16/2017 14:13:31: set elapsed time (len 2)
Jan/16/2017 14:13:31: set option request (len 4)
Jan/16/2017 14:13:31: set IA_PD
Jan/16/2017 14:13:31: send solicit to ff02::1:2%vr0
Jan/16/2017 14:13:31: reset a timer on vr0, state=SOLICIT, timeo=6, retrans=68413
Jan/16/2017 14:13:31: receive advertise from fe80::ea74:e6ff:feab:c4f2%vr0 on vr0
Jan/16/2017 14:13:31: get DHCP option client ID, len 14
Jan/16/2017 14:13:31: DUID: 00:01:00:01:20:0f:7d:87:00:0d:b9:12:d3:d0
Jan/16/2017 14:13:31: get DHCP option server ID, len 14
Jan/16/2017 14:13:31: DUID: 00:01:00:01:1f:9c:c7:99:e8:74:e6:ab:c4:f3
Jan/16/2017 14:13:31: get DHCP option identity association, len 46
Jan/16/2017 14:13:31: IA_NA: ID=0, T1=1799, T2=2878
Jan/16/2017 14:13:31: get DHCP option status code, len 2
Jan/16/2017 14:13:31: status code: success
Jan/16/2017 14:13:31: get DHCP option IA address, len 24
Jan/16/2017 14:13:31: IA_NA address: 2a02:121f:26::1:1 pltime=3598 vltime=4798
Jan/16/2017 14:13:31: get DHCP option IA_PD, len 47
Jan/16/2017 14:13:31: IA_PD: ID=0, T1=1799, T2=2878
Jan/16/2017 14:13:31: get DHCP option status code, len 2
Jan/16/2017 14:13:31: status code: success
Jan/16/2017 14:13:31: get DHCP option IA_PD prefix, len 25
Jan/16/2017 14:13:31: IA_PD prefix: 2a02:121f:26:8000::/52 pltime=3598 vltime=4798
Jan/16/2017 14:13:31: get DHCP option authentication, len 28
Jan/16/2017 14:13:31: proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: dc27 457b 8ab9 2094
Jan/16/2017 14:13:31: unsupported authentication protocol: 1
Jan/16/2017 14:13:31: failed to parse options
Da müsste man also entweder den dhcp6c so anpassen, dass er eine unbekannte Auth-Option einfach ignoriert oder er diese versteht. Die einfachere Variante ist, dass der DHCPv6-Server der CB2 diese nicht mehr verschickt. Ich konzentriere mich auf die zweite Variante, da die Authentisierung in der Praxis nicht verbreitet ist.
Problem 1 habe ich im Log gesehen. Kann man handeln.
Problem 2 warte ich gerne bis du eine Lösung meldest.
Ich brauche im LAN des CB Internet Access sonst kann ich vermutlich bald einige interessante Dinge nicht testen 🙂
Merci
Im aktuellsten Sprint soweit mal Eiertanzfertig.
Hat sicher noch Bugs.