• Der Fragesteller hat diesen Beitrag als gelöst markiert.
  • Geschlossen

my KMU Office Centro Busines IPv6 PD im LAN / DMZ Anleitung

Tux0ne
Level 9
1 von 4

Ich möchte mich mal wieder um eine Pendenz kümmern.

Und zwar suche ich eine Anleitung oder Erfolgsmeldung zur folgender Aufgabe:

 

Abo:

  • my KMU Office mit mehrerern fixen IP's
  • DHCPv6-PD im LAN oder DMZ für Router/FW
  • Betriebsmodus zuerst mal egal, soll ja angeblich in jedem Modus funktionieren
  • Bevorzugter Modus: DMZ Modus auf LAN 1 des CB

Setup:

  • IPv6 PD eines Routers/FW im LAN oder DMZ
  • Bevorzugt: FW pfsense, aber ich nehm sonst auch alles andere

Ausgangslage:

  • Angeblich ist PD mit einem /52 Netz möglich.
  • Bisherige Versuche erfolglos. FW bezieht nur IP über SLAAC und kein PD
  • Alternative PPPoE Passthrough mit /48 Bezug und Verteilung mehrere /64 Netze sonst erfolgreich und äusserst stabil in Betrieb (seit monatelangem Bugfixing durch Swisscom)

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.

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
HILFREICHSTE ANTWORT1

Akzeptierte Lösungen
IPv6@swisscom
Level 1
2 von 4

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.

3 Kommentare 3
IPv6@swisscom
Level 1
2 von 4

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.

Tux0ne
Level 9
3 von 4

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

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
Tux0ne
Level 9
4 von 4

Im aktuellsten Sprint soweit mal Eiertanzfertig.

Hat sicher noch Bugs.

 

2017-04-07 19_07_39-pfSense.tuxone - Status_ Dashboard.png

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
Nach oben