Probleme mit DHCPv6 über FortiGate Firewall und 2x Kabel Business im Bridge Mode

[Raudi1]

Hallo,

ein sehr komplexes Anliegen, welches ich heute habe. Ich habe es schon telefonisch versucht, aber da komme ich irgendwie nicht wirklich weiter. Ist halt kein Standard Problem.

Ich habe hier eine FortiGate 100D Firewall mit 2 WAN Interfaces. Jedes WAN Interface ist an einem SAGEMCOM Kabel Modem angeschlossen, welches im Bridge Mode läuft.

Ich habe hier "2" Business Kabelanschlüsse mit fester IP Adresse.

Im Bereich IPv4 ist alles wunderbar und funktioniert problemlos. Das Problem ist IPv6, hier sagt der Firewall Hersteller, dass der DHCP Server bei Vodafone sich nicht RFC Konform verhält.

Aktiviere ich auf dem ersten WAN Interface IPv6, so bekomme ich eine WAN IP und ein Client Prefix zugewiesen, welches ich auch im Online Portal einsehen kann. Dieses Prefix kann ich für die Clients verwenden und alles funktioniert problemlos.

Nun aktiviere ich aber auf dem zweiten WAN Interface IPv6, also über das andere Modem, über den anderen Vertrag, dann bekommt auch dieses Interface eine IP und ein Prefix zugewiesen, auch das welches im Online Portal hinterlegt ist.

Für ein paar Minuten funktioniert alles normal.

Nun fragt aber die Firewall über das erste WAN Interface noch mal nach und möchte das Lease erneuern. Dabei bekommt sie aber die Info, dass IP und Prefix abgelaufen und ungültig sind. Sie bekommt dann eine neue IP und ihr wird dann plötzlich das Prefix des anderen Interfaces zugewiesen.

Wir haben es im Trace, der DHCP Server von Vodafone weist dem ersten WAN Port das Prefix zu, welches eigentlich dem anderen WAN Port gehört.

Die Ursache ist vermutlich diese:

Die Fortigate nutzt für beide DHCP Anfragen die gleiche DUID, nur die Interface ID (IAID) ist unterschiedlich. Wir vermuten nun, dass der DHCP Server bei Vodafone die IAID ignoriert und bei den anfragen mit der gleichen DUID durcheinanderkommt.

Ich kann hier die Packet-Traces und erklären vom Fortinet Support gerne weiterleiten.

Fortinet sagt nun, die Fortigate würde sich hier RFC Konform verhalten, ein Client habe eine eindeutige DUID und die Schnittstellen dieses Clients würden über die IAID identifiziert.

Der Vodafone Support sagt nun, alles was hinterm Modem ist, sei nicht deren Problem, aber ein nicht RFC Konformes Verhalten eines DHCP Servers ist eigentlich nicht hinterm Modem...

Wie komme ich hier nun voran?

Viele Grüße

Stefan

EDIT: Beitrag in das passende Board verschoben // Dave

[reneromann]

Das Problem dürfte hier die Sonderkonstellation mit 2 WAN-Interfaces mit zwei unterschiedlichen Anschlüssen sein.

Und soweit ich das auf die Schnelle richtig herausgelesen habe, dient bei DHCPv6 die DUID sehr wohl alleinig (und nicht in Kombination mit der IAID) dazu, das System zu identifizieren. Mit der IAID wird lediglich das Interface an diesem System adressiert - sinnvollerweise erhalten alle IAIDs einer DUID das gleiche Präfix zugeteilt, weil zwei IAIDs in einem DHCPv6-Netz darauf hinweisen, dass die beiden Ports im selben Netz im Failover-Modus betrieben werden.

Das du beide Beine über zwei unterschiedliche Kundennummern und zwei unterschiedliche Anschlüsse betreibst, ist so sicherlich nicht im Sinne des Erfinders gewesen - da wäre ein unterschiedlicher DUID deutlich besser. Vielleicht bekommst du ja den Hersteller der Firewall dazu, optional für das 2. Interface eine separate DUID zu verteilen...

[Mal von den Problemen auf Clientseite, die zwei öffentliche Präfixe mit sich bringen, ganz abgesehen...]

Außerdem:

Wenn VF dir hier schon 2x das gleiche Präfix zuweist - werden dann seitens VF die Pakete wenigstens auch über beide Leitungen geroutet? Wenn ja, hast du da ja schon dein Load-Balancing...

Mal davon abgesehen:

2 Anschlüsse über die gleiche Technologie helfen Null Komma Null gegen einen Ausfall - und da du dir im Segment die Bandbreite mit allen anderen Kunden teilst, gewinnst du in der Regel auch so gut wie keine Geschwindigkeit durch solche Manöver. Besser wäre es, auf eine 2. Technologie (und da reicht selbst ein popeliger 1 MBit/s-DSL-Anschluss) zu setzen, die im Fall des Ausfalls der Kabel-Leitung als Failover einspringen kann (und auch wirklich als solcher dient).

[Raudi1]

Ja, mit dem Hersteller der Firewall bin ich am diskutieren, denn bei einem LANCOM funktioniert das und im Netz habe ich ein KB Artikel gefunden, wo bei Juniper die DUID pro Routing Instanz zu konfigurieren ist, also auch nicht Systemweit.

Die meinen jedoch sie verhalten sich nach RFC 3315 konform. Ich solle einen Feature Request stellen.

Ich habe hier 2 Anschlüsse um einfach bestimmten traffic zu trennen und damit ich 2 öffentliche IP's habe. DSL gibts hier nur 768 KBit/s.

Also auf der Client Seite habe ich mit den 2 Prefixen keine Probleme, eines wird automatisch zugewiesen an Clients die es anfordern. Das andere ist Fix, da habe ich bei Windows Servern die autmatismen deaktiviert und eine IP aus dem Prefix fest eingetragen. In der Firewall ist dann so eingestellt: Quelle Prefix 1 route nach WAN1, Quelle Prefix 2 route nach WAN2. Klappt...

Nur dass Problem dass ich halt auf WAN1 das Prefix von WAN2 aktiv bekomme, dann klappt natürlich das Routing nicht mehr.

Aber jemand von Vodafone hat sich heute Abend gemeldet und er hat mir eine Mail Adresse genannt, wohin ich die Traces und Infos vom Hersteller schicken soll. Mal schauen...

[Raudi1]

Und noch was gefunden:

https://www.juniper.net/documentation/en_US/junos/topics/concept/dhcpv6-duplicate-client-duid.html

Das klingt doch ziemlich nach dem Verhalten was ich habe, wenn die gleiche DUID kommt überschreibt die zweite die Infos der ersten. Man muss erst ein besonderes Feature aktivieren um doppelte DUID's zu erlauben, erst dann wird die IAID mit ausgewertet.

Evtl. ist dieses bei dem Vodafone DHCPv6 Server ja ähnlich.

Der Server DUID nach setzt Vodafone Cisco ein und ich habe auch noch einen Cisco Bug gefunden, keine Ahnung, ob Vodafone nun gerade solche Komponenten einsetzt, aber hier gibt es auch Probleme mit doppelten DUID's im DHCPv6 Relay Agent:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvg03094

Also ein komplexes Problem...

Ich bete ja noch, dass der Firewall Hersteller ein einsehen hat und was einbaut...

[Raudi1 · Accepted solution]

Hallo,

so habe letzte Woche mit einem netten Techniker telefoniert, er hat mir erklärt, dass dieses leider by design ist und sich nicht ändern lässt, da in einer Datenbank die Verbindung Kundendaten <-> DUID gespeichert wird. Doppelte DUID's sind leider nicht möglich.

Er konnte das Verhalten auf auch dem Server nachvollziehen, WAN1 aktiv, hat eine IP bezogen vernüpft mit Kunde 1. WAN 2 aktiviert, hat gleiche DUID genutzt, was dazu führte, dass alte IP von WAN1 für ungültig erklärt wurde und WAN2 hat neue IP bekommen. Gleichzeitig ist die DUID auch zu Kunde 2 rüber gewandert.

Also muss ich auf ein einsehen von Fortinet hoffen, dass die hier was einbauen, damit das hier funktioniert...

Viele Grüße

Stefan

[Raudi1]

Hallo,

ein Nachtrag:

Heute habe ich von Fortinet die Info bekommen, dass dieses Problem in der OS Version 6.0.3 behoben sein wird, ab dann bekommt jedes DHCPv6 Interface seine eigene DUID.

Viele Grüße

Stefan