Messages

Also,
ich habe jetzt alles, was Wireguard und das NAT und die Berechtigungen dazu angeht abgerissen und neu eingerichtet.
Eigentlich genau wie vorher, nur die Reihenfolge etwas anders.
Jetzt geht es.
?
Danke für die Unterstützung.

Man mach dass wenn man z.b. einen Server hosted der eine ACL hat und nur bestimmte IP addressen zulässt. Dann routet man via VPN über die Firmen IP Addresse. Damit man nicht jede youtube verbindung über das VPN jagt, nimmt man halt nur einzelne IPs für den Split tunnel. An sich sollte das funktionieren.

Genau so ist das. Danke.

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

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.

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

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

Ja, genau. Da ist ein Kabelrouter vor der Firewall

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

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.

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.

Hi,

since today we have the same issue.

We are just using ET telemetry rulesets.

Is there anything I can do?

Memory and diskspace is available.

Das war ja das Problem. Ich hatte nur die IP-Adresse und die war nicht in der Konfiguration, weil der DNS-Eintrag fehlerhaft war.
Da ich auf diesen keinen Einfluss hatte, habe ich die dazu passenden FQDN aus der Konfig rausgeworfen.
Den Rest kläre ich die nächsten Tage.
Nochmals danke.

Ich hatte zwei Abstürze einer virtualisierten OPNsense. Auf der Konsole kam noch die Meldung:

arprequest_internal: cannot find matching address

Ich habe danach recherchiert, konnte aber keine Lösung dazu finden.

Der Fehler tritt erst seit heute auf. Einzige Änderung ist das Update auf die 25.1.3

Vielen Dank für die Unterstützung.

Hallo patient0,

vielen Dank. Das hat mich auf die richtige Spur gebracht. Hatte tatsächlich nichts mit dem Update zu tun, sondern mit einem gelöschten DNS-Eintrag. Dumm nur, dass ich zwar die IP-Adresse, nicht aber den dazu passenden FQDN ausgegeben bekommen habe. Hat zwar eine gute Stunde gedauert, bis ich alle DNS-Abfragen durchgearbeitet hatte, ich habe dann aber den Übeltäter gefunden.

Der Dienst läuft wieder.

Vielen Dank!

Hallo,
seit dem Update auf die Version 25.1.3 startet der HAProxy nicht mehr. Hinweise in den Logdateien kann ich nicht finden.

Wenn ich in der Shell starte kommt die Meldung:
Starting haproxy.
/usr/local/etc/rc.d/haproxy: WARNING: failed to start haproxy

Die Konfiguration ist noch da und seit dem letzten Neustart auch unverändert.

Deinstallation des Plugins bringt keine Änderung.

haproxy -c -f /usr/local/sbin/haproxy
[NOTICE]   (77006) : haproxy version is 3.0.8-6036c31
[NOTICE]   (77006) : path to executable is /usr/local/sbin/haproxy
[ALERT]    (77006) : config : parsing [/usr/local/sbin/haproxy:1]: unknown keyword 'ELF␂␁␁' out of section.
[ALERT]    (77006) : config : parsing [/usr/local/sbin/haproxy:1]: Stray NUL character at position 9.
[ALERT]    (77006) : config : Error(s) found in configuration file : /usr/local/sbin/haproxy
[ALERT]    (77006) : config : Fatal errors found in configuration.

Ich komme hier gerade nicht weiter.

Vielen Dank für Eure Unterstützung.

Gruß
Ralf