Über Wireguard kann ich eine Öffentliche IP-Adresse nicht erreichen

[RalfOE]

Hallo,
wir testen gerade Wireguard und das funktioniert soweit sehr gut.
Leider habe ich aktuell ein Problem.
Der Zugriff über Wireguard auf interne IP-Adressen funktioniert einwandfrei. Wenn wir nun einzelne öffentliche IP-Adressen hinzufügen, werden diese zwar im Routing ordentlich angezeigt, sind aber nicht erreichbar.
Firewall und NAT sind soweit korrekt eingestellt. Beim Outbound-NAT habe ich auch schon alles mögliche ausprobiert.
Traceroute zeigt nur "Zeitüberschreitung der Anforderung"
Hat jemand eine Idee?
Danke für die Unterstützung.

[Bob.Dig]

Wenn wir nun einzelne öffentliche IP-Adressen hinzufügen

Bitte mal näher erläutern.

[RalfOE]

In den Einstellungen des Wireguard-Clients steht:

Erlaubte IPs: 192.168.0.0/24, 123.123.123.123/32

Dann sieht die Routingtabelle wie folgt aus:

    Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
...
123.123.123.123  255.255.255.255   Auf Verbindung        172.30.2.1      5
...
    192.168.0.0    255.255.255.0   Auf Verbindung        172.30.2.1      5
...

Die Geräte im Netzwerk 192.168.0.0/24 sind erreichbar, die IP-Adresse 123.123.123.123 nicht.

[Patrick M. Hausen]

Wie sehen die Firewall-Regeln für das Wireguard-Interface (falls angelegt) oder die Wireguard-Gruppe (falls kein Interface angelegt) aus?

Dann mach mal per SSH:

Code Select Expand

pfctl -s nat

und schau, ob für das Wireguard-Netz eine ausgehende NAT-Regel auf WAN automatisch angelegt wird. Bin mir da nicht ganz sicher, unter Umständen musst du NAT auf manuell oder hybrid schalten, und das selbst machen.

Bestätigen oder widerlegen ließe sich das NAT-Problem, so es existiert, auch durch:

Code Select Expand

tcpdump -n -i <wan-interface> icmp

und dann mal gucken, was als Source-Adresse in den Paketen steht, die zum WAN rausgehen während des "ping". Wenn da die private Adresse drin ist, dann kann der Ziel-Server natürlich nicht antworten, dann ist es das fehlende NAT.

Ich kann das hier ohne größeren Umbau nicht testen, da ich NAT immer 100% manuell mache.

Grüße, HTH
Patrick

[RalfOE]

Hallo Patrick,

danke für Deine Antwort.
NAT Outbound Hybrid hatte ich schon eingestellt, nachdem es nicht funktionierte.
Und dann verschiedene Einstellungen getestet.

pfctl -s nat
no nat proto carp all
nat on igb1 inet from 10.2.120.0/24 to any -> (igb1:0) port 1024:65535
nat on igb1 inet from 10.2.120.0/24 to any port = isakmp -> (igb1:0) static-port

10.2.120.0/24 ist das VPN-Netzwerk

Beim tcpdump kommt folgende Meldung:

21:04:22.683457 IP 192.168.123.29 > 123.123.123.123: ICMP echo request, id 1, seq 1734, length 40

Wobei 192.168.123.29 die IP-Adresse auf dem WAN-Device ist

[meyergru]

Ist das ein Router-Behind-Router Szenario, z.B. Fritzbox vor der OpnSense? Sonst wäre ja wohl keine RFC1918 auf dem WAN-Device...

[RalfOE]

Ja, genau. Da ist ein Kabelrouter vor der Firewall

[meyergru]

Na dann. Denk mal darüber nach, warum das nicht klappt. Tipp: RFC1918-IPs werden von den wenigsten ISPs geroutet...

Lesestoff:

https://forum.opnsense.org/index.php?topic=42985.0, speziell Punkt 4.

Ich habe das nie so gemacht (aus Gründen), deswegen kann ich auch keine Schritt-für-Schritt-Anleitung geben, wie das mit geeigneten Firewall- und NAT-Regeln rein und raus sowie erlaubten IP-Ranges im Wireguard-Profil geht. Irgendwie bekommt man das sicher hin, ist aber wahrscheinlich komplex.

Zugegebenermaßen wüsste ich aber auch nicht, ob es reine Kabelmodems gibt...

[RalfOE]

Ja, klar.

Der Kabel-Router macht ja auch nochmal NAT. Von daher ist das aus meiner Sicht alles korrekt. Irgendwo habe ich noch einen Knoten und das NAT scheint es nicht zu sein.

Also nochmal kurz zusammengefasst.

Die Anfrage geht über das VPN und kommt am WAN-Port der Firewall an, was aus meiner Sicht korrekt ist.

Zugriff von 10.2.120.0/24 auf 192.168.0.0/24 (VPN-LAN) funktioniert
Zugriff von 192.168.0.0/24 auf 123.123.123.123 (LAN-WAN) funktioniert
Zugriff von 10.2.120.0/24 auf 123.123.123.123 VPN-WAN) geht nicht

Der Kabelrouter hat keine Firewall aktiv, nur NAT und bekommt alle drei Anfragen von der 192.168.123.29

[Patrick M. Hausen]

Guck dir mit tcpdump die Pakete an ...

[RalfOE]

Was genau meinst Du?

07:34:25.049713 IP 192.168.123.29 > 123.123.123.123: ICMP echo request, id 1, seq 1979, length 40
        0x0000:  4500 003c 14ac 0000 7f01 98cd c0a8 b21d  E..<............
        0x0010:  d9a0 41e1 0800 45a0 0001 07bb 6162 6364  ..A...E.....abcd
        0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst
        0x0030:  7576 7761 6263 6465 6667 6869            uvwabcdefghi

[Patrick M. Hausen]

Zum Beispiel. Auf welchem Interface ist das? WireGuard ausgehend? Und an welcher Stelle wird dann geNATed? Am anderen Ende des WireGuard-Tunnels? Der Server 123.123.123.123 kann ja 192.168.123.29 nicht antworten ...

[RalfOE]

Das ist auf dem WAN-Interface auf der OPNsense-Firewall. Dieses befindet sich im Netzwerk 192.168.123.0/24 hinter dem Kabelrouter, der wiederum in das Internet nattet.
Die 123.123.123.123 kann natürlich nicht auf die 192.168.123.29 antworten. Allerdings auf die öffentliche IP-Adresse des Kabel-Routers und der wiederum auf die 192.168.123.29.

[Patrick M. Hausen]

Hat der Upstream-Router eine statische Route zu 192.168.123.0/24?

[RalfOE]

Das LAN-Interface des Upstream-Routers hat die IP-Adresse 192.168.123.1 im Netzwerk 192.168.123.0/24