IPv6 auf WAN nicht erreichbar

[robgnu]

Hallo zusammen,

ich habe mich hier heute registriert, da ich seit ein paar Tagen als pfSense Umsteiger mit OPNsense experimentiere. Ich bin nun leider an einem Punkt angelangt, an dem ich nicht weiter komme und Hilfe benötige.

Situation:
- Hardware APU2 mit OPNsense 20.1.4 (aktuell) an einem Vigor 130 VDSL-Modem.
- Einwahl über die Telekom (Feste-IP) im Dualstack Modus. (Prefix /56; Send prefix hint; Use IPv4 connectivity sind angehakt).
- Das WAN Interface bekommt eine IPv6 Adresse, die LAN und VLAN Interfaces bekommen ebenfalls eine IPv6 Adresse.
- Ausgehender IPv6 Verkehr ist möglich und alles sieht gut aus.
- Der SSH Zugriff auf einen Host hinter der OPNsense in einem VLAN über das Internet ist möglich.
- Ping vom Internet auf die öffentliche IPv4 und IPv6 Adresse sind möglich.

- Firewallregeln (WAN):
- Allow IPv6 ICMP
- Allow TCPv6 / This Firewall / SSH Port 22
- Allow TCPv4 / This Firewall / SSH Port 22
- Allow UDPv6 / This Firewall / OpenVPN Port 1194
- Allow UDPv4 / This Firewall / OpenVPN Port 1194
- Allow TCPv6 / <EIN HOST HINTER DER OPNSENSE> / SSH Port 22

Das Problem:
Über das WAN Interface kann ich Dienste (SSH / OpenVPN) nicht per IPv6 erreichen, jedoch per IPv4.

Wenn ich jetzt vom Internet ankomme und versuche mich per SSH mit der OPNsense (IPv6) zu verbinden, bekomme ich einen Timeout, gleiches gilt für OpenVPN. Wenn ich mich mit der öffentlichen IPv4 Adresse verbinde, wird die Verbindung sofort aufgebaut.

In den Firewall-Logs werden die IPv6 Verbindungsversuche als PASS gelistet. Auch die sshd und openvpn Dienste lauschen auf ANY. Und wenn ich mir das Packet Capture mit Wireshark anschaue, bekomme ich nur zwei Einträge. Zunächst der Verbindungsaufbau (SYN) und anschließend die Antwort (SYN, ACK). Jedoch scheint die Antwort nicht anzukommen.

Ich bin nun einigermaßen ratlos und hoffe, dass ich hier einen Tipp bekommen kann. Handelt es sich vielleicht um einen Bug? Mit pfSense hatte ich an dieser Stelle nie Ärger. Ich muss dazu sagen, dass die Ersteinrichtungsassistent der OPNsense bei mir auch fehlerhaft war. Sobald die Internetverbindung aufgebaut hatte und die IPv6 Konfiguration nachgetragen hatte, hat sich gar keine Internetverbindung mehr aufgebaut. Nach einem Factory-Reset und der manuellen Konfiguration klappte es jedoch.

Vielen Dank
Robert.

[robgnu]

Hallo,
ich gebe hier nochmal ein kleines Update hinterher:

Über den Menüpunkt "System" -> "Gateways" -> "Single" habe ich mir die Einträge angesehen:

- WAN_DHCP6    WAN    IPv6    254    fe80::200:ff:fe00:0
- WAN_PPPOE (active)    WAN    IPv4    254    62.156.244.29

Ich habe einfach mal auf "gut Glück" das WAN_DHCP6 Gateway disabled. Anschließend waren die Verbindungen von Außen über IPv6 auch möglich. Also scheint die Ursache wohl in der Tatsache zu liegen, dass die Verbindungen durch die Firewall gingen, von den Diensten angenommen wurden, aber die Antwort nicht den Weg zurück gefunden hat.

Ich kann mir jedoch derzeit nicht erklären, wieso ein ausgeschaltetes IPv6 Gateway dafür sorgt, dass IPv6 funktioniert.

Gruß
Robert.

[hbc]

Die fe80::200:ff:fe00:0 kannst Du von extern (Internet) gar nicht erreichen. Das ist eine local link Adresse und eben so wie die RFC1918 Adressen werden diese im Internet nicht geroutet.

Deine Clients haben dann öffentliche Adressen, wenn diese erreicht werden können? Was haben die dann als Defaultroute? Die fe80 oder eine öffentliche IPv6 Adresse deiner Sense? Radvd aktiv oder wie wird Gateway verteilt?

[robgnu]

Hallo,

das ist richtig. Die fe80 Adressen werden ja bei IPv6 als Gateway-Adresse genutzt. Bei einem Linux-Client hinter der OPNsense zeigt die Route z.B. auch auf eine fe80 Adresse und natürlich haben sie auch öffentliche IPv6 Adressen:

Code Select Expand


> ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2003:a:143:xxxx::/64 dev enp0s3 proto kernel metric 256 expires 86399sec pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::20d:b9ff:fe4b:f990 dev enp0s3 proto ra metric 1024 expires 1799sec hoplimit 64 pref medium

> ip -6 a
[...]
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:a:143:xxxx:5054:ff:fe21:a000/64 scope global deprecated dynamic mngtmpaddr
       valid_lft 7203sec preferred_lft 0sec
    inet6 fe80::5054:ff:fe21:a000/64 scope link
       valid_lft forever preferred_lft forever


IPv6 / radvd läuft in allen Subnetzen per RA (Stateless DHCP). DHCPv6 ist deaktiviert. Mein Problem liegt jedoch nicht bei den Clients, sondern beim Router.

Wie gesagt: Wenn ich die Client IPv6 Adressen in der Firewall freigebe, erreiche ich die Subnetze und die Systeme von Außen. Routing rein/raus läuft. Jedoch wenn ich die Firewall selbst (also das WAN Inferface) von außen anspreche, dann kommen die Pakete nicht zurück, es sei denn, ich deaktiviere das Gateway wie im zweiten Post beschrieben.

Bisher läuft das jetzt sehr gut - d.h. ich kann damit leben. Denn ich halte IPv6 für essentiell wichtig und mit diesem deaktivieren läuft es... Nur würde ich diesen Teil gerne verstehen. Vielleicht hat ja noch jemand eine Idee?

Gruß
Robert.

[robgnu]

Hallo,

ich hole diesen Thread nochmals hoch, da ich ergänzende Infos zu dem Problem habe, jedoch keine Lösung.

Heute habe bei einem Bekannten eine OPNsense hinter einer FRITZ!Box installiert. Die OPNsense ist als Exposed-Host (v4 + v6) konfiguriert und bekommt per Prefix Delegation ein paar Subnetze von der FRITZ!Box.

Wenn ich nun von außen die WAN-Schnittstelle der OPNsense anspreche, bekomme ich per IPv4 eine Verbindung (z.B. SSH oder OpenVPN), per IPv6 bekomme ich einen Timeout. Daraufhin habe ich, wie oben beschrieben, das IPv6 Gateway deaktiviert (Status Pending) und ab diesem Zeitpunkt war der Zugriff auf die WAN-Schnittstelle von Außen möglich. Dieser Zustand war jedoch nicht von Dauer, nach kurzer Zeit ging es wieder nicht.

Konfiguration: APU2 mit OPNsense 20.1.7 - Frische Neuinstallation von heute.
Die Firewallregeln gestatten den Zugriff. Ich vermute, dass die Antwort der OPNsense nicht "zurück" findet - habe aber keine Idee, wie ich das Lösen soll...

Hat jemand noch eine Idee?

Gruß
Robert.

[robgnu]

Eine Kleine Ergänzung:

Gerade habe ich versucht über den WAN Port auf die WebUI zuzugreifen (Firewall ist freigegeben), der erste Zugriff erfolgte per IPv4, obwohl es eigentlich per IPv6 funktionieren müsste. Anschließend habe ich einen Portscan mit nmap durchgeführt und es wurden mir auch meine offenen SSH/HTTPS Ports angezeigt. Ich wiederholte den Vorgang mit der IPv6 Adresse und auch dort wurden mir die gleichen offenen Ports angezeigt.

Es stellte sich heraus, dass dann auch der Zugang auf die WebUI per IPv6 möglich war. Auch per SSH kam ich gerade rein. Ich bin gespannt ob dieser Zustand anhält.

Was jedoch noch nicht funktioniert ist OpenVPN:
Sobald ich die Verbindung initiiere versucht der Client es auf der IPv6 Adresse, nach einem Timeout von 60 Sekunden versucht er es mit der IPv4 Adresse und es funktioniert auf Anhieb. Ich habe auch die entsprechende Firewall-Regel mit dem Log-Flag versehen und sehe, dass auf dem IPv6 Interface die Verbindung ankommt (grün/allow).

Nach dem Timeout erscheint folgendes im Server-Log; anschließend baut sich die Verbindung per IPv4 sofort auf.

Code Select Expand


openvpn[6152]: 2003:e9:871b:f900:222:4dff:feaa:7c9f TLS Error: TLS handshake failed
openvpn[6152]: 2003:e9:871b:f900:222:4dff:feaa:7c9f TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)


Kann es sein, dass die Pakete zwar rein kommen, aber den Weg zurück nicht finden?

Robert.

[Maurice]

Du könntest mal schauen, ob die angezeigte Gateway-Adresse hier überall die gleiche ist:

- System / Gateways / Single
- System / Routes / Status (IPv6-Default-Route)
- Interfaces / Overview (WAN)

Grüße

Maurice

[robgnu]

Hallo,

ich habe gerade mal nachgesehen:

- System / Gateways / Single
> fe80::2e3a:fdff:feb0:5bbc

- System / Routes / Status (IPv6-Default-Route)
> fe80::2e3a:fdff:feb0:5bbc%igb1

- Interfaces / Overview (WAN)
> fe80::2e3a:fdff:feb0:5bbc

Also wenigstens sind die Routen überall gleich. Ich habe die Situation in den letzten Stunden beobachtet und kann aktuell behaupten, dass der Zugriff über SSH und HTTPS von außen nun möglich ist. Da ich nichts geändert habe, fehlt mir noch eine Erklärung.

Weiterhin komme ich jedoch mit dem OpenVPN nicht auf den WAN-Port. OpenVPN ist als UDP 1194 konfiguriert. Leider habe ich keinen anderen UDP basierenden Dienst zur Hand um zu testen. Wenn ich den OpenVPN auf TCP stelle und die Firewall anpasse, funktioniert der Zugriff per IPv6 Adresse auf Anhieb.

Gruß
Robert.

[Bytechanger]

Hallo,

ich glaube, ich habe das gleiche Problem.
Ich bin aktuell bei der Telekom und versuche über ipv6 von Außen auf die OPNSense zu kommen.

Zuerst glaubte ich an ein Problem von haproxy, zwischenzeitlich weiß ich, ich komme gar nicht per ipv6 auf die OPNSense....
https://forum.opnsense.org/index.php?topic=17316.new;topicseen#new

IPv4 funktioniert einwandfrei. Leider bekomme ich bei ipv6 ein Timeout.
Ob dies irgendwie an der Telekom liegt?
Wurde das Problem zwischenzeitlich analysiert/behoben?

robgnu:

"Mit pfSense hatte ich an dieser Stelle nie Ärger"

bedeutet, bei gleicher Leitung und ISP (Telekom) funktionierte es?

Dann wäre es kein Telekom-Problem, sondern ggf. ein Config oder OPNSense bug??



Gruß

Byte

[Bytechanger]

Hallo,

ich habe auch mal das automatisch erstelle Gateway deaktiviert und prompt komme ich drauf.
Da stimmt doch etwas mit OPNSense nicht.

Gateway->Single->WAN_DHCP6
  WAN_DHCP6    WAN    IPv6    254    fe80::f6b5:2fff:fef0:a2eb

Gruß

Byte

[robgnu]

bedeutet, bei gleicher Leitung und ISP (Telekom) funktionierte es?

Dann wäre es kein Telekom-Problem, sondern ggf. ein Config oder OPNSense bug??

Ja, ich habe dieses Problem derzeit an zwei OPNsense Kisten - beide auf 20.1.7. Die erste klemmt mit einem Vigor 165 an einer VDSL-Anschluss der DTAG und wählt sich direkt ein. Die zweite ist hinter einer FRITZ!Box mit Prefix-Delegation (Exposed Host).

Die erste Installation war vorher eine pfSense 2.4.4p3 auf gleicher Hardware (APU2C4), gleicher Anschluss und gleicher WAN/VLAN/LAN-Konfiguration.

ich habe auch mal das automatisch erstelle Gateway deaktiviert und prompt komme ich drauf.
Da stimmt doch etwas mit OPNSense nicht.

Gateway->Single->WAN_DHCP6
  WAN_DHCP6    WAN    IPv6    254    fe80::f6b5:2fff:fef0:a2eb

Dito. Leider weiß ich nicht, wie ich helfen kann, das Problem einzugrenzen.


Gruß
Robert

[robgnu]

Hallo Bytechanger,
Hallo Zusammen,

ich habe im englischen Forum schon geantwortet. Ich habe hier trotzdem nochmals eine saubere Zusammenfassung:

Gestern Abend habe ich das IPv6 Gateway wieder aktiviert, was sofort dazu führte, dass ich von Außen/IPv6 nicht mehr an die OPNsense kam. Nach einigen Recherchen hier im Forum stieß ich auf den Tipp, die Option "Disable reply-to" unter Firewall->Settings-Advanced zu aktivieren.

Bei meinen drei OPNsense Installationen wurde dadurch das Problem gelöst:
- 1. & 2. Installation an PPPoE/VDSL (WAN-IP war nur auf IPv4 erreichbar)
- 3. Installation hinter einer FRITZ!Box als Exposed Host (IPv6/UDP war nicht erreichbar, IPv6/TCP und IPv4 schon)

Das Problem scheint auch schon viele Jahre in der OPNsense zu sein. Dazu habe ich folgende Links gefunden:
- https://www.andysblog.de/opnsense-zugriff-auf-das-web-interface-ueber-wan
- https://forum.opnsense.org/index.php?topic=15900.0
- https://forum.opnsense.org/index.php?topic=12686.0 (Speziell https://forum.opnsense.org/index.php?topic=12686.msg58664#msg58664)

Da ich hier nirgends ein Dual-WAN Setup habe, finde ich diese Standardkonfiguration äußerst problematisch. Eine andere Standardkonfiguration, wie bei pfSense, halte ich für besser. In der Doku für Dual-WAN könnte man ggf. einen Hinweis geben.

Weshalb dies jetzt nur IPv6 betrifft und bei der OPNsense hinter der FRITZ!Box sogar nur UDP ist mir leider auch nicht klar.

Vielleicht hat jemand noch eine Idee?

Gruß
Robert.

[mimugmail]

Hallo Bytechanger,
Hallo Zusammen,

ich habe im englischen Forum schon geantwortet. Ich habe hier trotzdem nochmals eine saubere Zusammenfassung:

Gestern Abend habe ich das IPv6 Gateway wieder aktiviert, was sofort dazu führte, dass ich von Außen/IPv6 nicht mehr an die OPNsense kam. Nach einigen Recherchen hier im Forum stieß ich auf den Tipp, die Option "Disable reply-to" unter Firewall->Settings-Advanced zu aktivieren.

Bei meinen drei OPNsense Installationen wurde dadurch das Problem gelöst:
- 1. & 2. Installation an PPPoE/VDSL (WAN-IP war nur auf IPv4 erreichbar)
- 3. Installation hinter einer FRITZ!Box als Exposed Host (IPv6/UDP war nicht erreichbar, IPv6/TCP und IPv4 schon)

Das Problem scheint auch schon viele Jahre in der OPNsense zu sein. Dazu habe ich folgende Links gefunden:
- https://www.andysblog.de/opnsense-zugriff-auf-das-web-interface-ueber-wan
- https://forum.opnsense.org/index.php?topic=15900.0
- https://forum.opnsense.org/index.php?topic=12686.0 (Speziell https://forum.opnsense.org/index.php?topic=12686.msg58664#msg58664)

Da ich hier nirgends ein Dual-WAN Setup habe, finde ich diese Standardkonfiguration äußerst problematisch. Eine andere Standardkonfiguration, wie bei pfSense, halte ich für besser. In der Doku für Dual-WAN könnte man ggf. einen Hinweis geben.

Weshalb dies jetzt nur IPv6 betrifft und bei der OPNsense hinter der FRITZ!Box sogar nur UDP ist mir leider auch nicht klar.

Vielleicht hat jemand noch eine Idee?

Gruß
Robert.

Die drei Links haben doch gar nichts mit dem Problem zu tun dass UDP nicht geht aber TCP schon?
Du postest in zu viele Threads mit ähnlichen Themen, ich hab da Schwierigkeiten zu folgen wie denn dein aktueller Stand ist. War mir jetzt sicher dein Problem im englischen Post ist noch nicht gelöst  :o

[robgnu]

Hallo,

ja du hast recht. Ich habe etwas chaotisch geschrieben. Ich war mir irgendwann selbst nicht mehr sicher, wo nun die Probleme entstanden sind und ob diese evtl. zusammenhängen.

Zu meinem ursprünglichen Problem, dass ich auf die WAN-Schnittstelle nicht mehr zugreifen kann, kann ich mitteilen, dass das Problem gelöst ist.

Bei einer OPNsense Installation waren IPv6/udp Zugriffe auf WAN nicht möglich, tcp funktionierte. Bei einer anderen Installation war das ganze Interface betroffen, und das Deaktivieren des Gateways war ein hässlicher Workaround.

Die Lösung beider Probleme war die Aktiviung des Häkchens "Disable reply-to on WAN rules" in den Einstellungen der Firewall. Offenbar wurde dies schon mehrfach berichtet und in den drei Links wird darüber auch diskutiert.

Das Problem in meinem anderen Thread konnte ich heute auch lösen. Ich werde es dort berichten.

Danke für euer Verständnis. Ich bemühe mich beim nächsten mal etwas strukturierter zu Fragen.

Gruß, Robert.

[abulafia]

Hier stand Mist.