Update2: Fortigate IPv6 SIT-Tunnel von Hurricane Electric hinter AVM fritz.box

Da AVM es bis heute nicht geschafft hat, das Problem zu lösen, habe ich meinen alten DrayTek Vigor 130 Router aus dem Schrank geholt. Läuft alles einwandfrei. Beim IGMP Proxy musste ich allerdings per telnet eine Einstellung setzen:

ip igmp ppp 1 (Was immer das heißt, eine Doku habe ich nicht gefunden)

Gegenüber dem Zyxel VMG1312 hat der Vigor den Vorteil, dass man eigene DynDNS Profile erzeugen kann. Damit wird dann auch der IPv6 Tunnel nach einem Neustart wieder richtig konfiguriert.

Fortigate IPv6 SIT-Tunnel von Hurricane Electric hinter AVM fritz.box

Interessante Sache … Ich betreibe die fritz.box (FB) rein mit IPv4. Die Fortigate (FG) ist als exposed host freigegeben. Die config der FG sieht so aus:

config system sit-tunnel
edit “HE”
set destination 216.xx.yy.zz
set ip6 2001:470:aaaa:bbbb::2/64
set interface “outside”
next
end

config router static6
edit 1
set device “HE”
next
end

Das funktioniert so weit ganz gut, aber NUR wenn ich auf der FB im Support-Interface (/support.lua) einen Paketmitschnitt auf dem Internet-Interface mache.

Hier ein kurzer Trace, was die FG sieht, wenn der Paketmitschnitt aus ist:

id=20085 trace_id=1594 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, SERVER:22->CLIENT:62426) from HE.”
id=20085 trace_id=1594 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, reply direction”
id=20085 trace_id=1594 func=ipv6_fast_cb line=58 msg=”enter fast path”
id=20085 trace_id=1595 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, CLIENT:62426->SERVER:22) from lan.”
id=20085 trace_id=1595 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, original direction”
id=20085 trace_id=1595 func=ipv6_fast_cb line=58 msg=”enter fast path”
id=20085 trace_id=1596 func=resolve_ip6_tuple_fast line=3286 msg=”vd-root received a packet(proto=6, SERVER:22->CLIENT:62426) from outside.”
id=20085 trace_id=1596 func=resolve_ip6_tuple_fast line=3311 msg=”Find an existing session, id-00000149, reply direction”
id=20085 trace_id=1596 func=vf_ip6_route_input line=898 msg=”reverse path check failed, drop”

Die FG glaubt, das Paket käme aus dem Interface “outside” anstatt aus dem Interface “HE” (im Gegensatz zu dem ersten Paket, was richtig aus HE kam). Daher greift der Spoofing-Algorithmus und dropped das Paket.

Ein wenig Abhilfe brachte der folgende Workaround:

config system settings
set asymroute6 enable
end

Damit konnte ich mich zumindest per SSH auf dem Server anmelden. Allerdings stirbt die Session nach kurzer Zeit wieder, weil keine Pakete mehr empfangen werden.

Ich vermute, das Ganze hat was damit zu tun, dass der tcpdump auf der FB das Interface in den promiscuous mode setzt. Entsprechende Tickets hab ich bei AVM, Hurricane Electric und Fortigate offen. Mal sehen was zurück kommt 🙂

Novell Zenworks 11 Agent mit IPv6

Die Kommunikation der Zenworks Server kann gestört sein, wenn auf den verwalteten Geräten IPv6 verfügbar ist. Bei uns führte das dazu, dass der Satelliten-Server keine Befehle mehr empfangen hat. Unter Linux kann man in der Datei /etc/init.d/novell-zenworks-xplatzmd die Zeile mit EXTRA_OPTS um folgenden Prameter erweitern:
-Djava.net.preferIPv4Stack=true

Exchange OWA IPv6

Interessantes Phänomen:

http[s]://<IPv4 Adresse CAS Server>/owa wird perfekt auf /auth/login.aspx weitergeleitet (bei Standard-Authentication)

http[s]://<IPv6 Adresse CAS Server>/owa wird nicht weitergeleitet

aber

http[s]://<IPv6 Adresse CAS Server>/owa/auth/login.apsx funktioniert einwandfrei

Suchzeit: 2 Stunden

Cisco ASA – LDAP Bug

Wer seine VPN-Benutzer gegen ein Microsoft AD authentifizieren will, bekommt Spaß im Zusammenspiel einer Cisco ASA und IPv6 …

  • Die Konfiguration von LDAP Authentication gegen ein AD ist oft genug beschrieben
  • Bei Verwendung von DIGEST-MD5 SASL Authentication ist zu beachten, dass es nicht mit IP-Adresse funktioniert, da der Windows Server eine URI mit Servernamen erwartet
  • Wenn der Server aber einen IPv6 AAAA-Record im DNS hat, findet die ASA den Server nicht mehr
  • Ping von der ASA löst IPv6 auf und ist efolgreich, LDAP Auth leider nicht
  • Besonders spannend wird es, wenn man kurzzeitig die IPv6 Adressen von der ASA entfernt, dann geht LDAP wieder … auch wenn die Adressen danach wieder konfiguriert werden

Suchzeit: 2-3 Stunden