Messages

Ja genau, das scheint wohl das Problem zu sein.
Der Tunnel ist Policy Based.

Was allerdings verwunderlich ist, wieso dann die DNS Weiterleitung über den Tunnel an den AD DNS Server funktioniert, da Unbound auch auf der OPNsense läuft?

Falls ich tatsächlich nicht weiterkomme, werde ich mal einen WireGuard Tunnel testen.
Wenn als Source das LAN Interface benutzt würde, sollte es meiner Meinung nach aber klappen, zumindest verhält sich der Ping von der OPNsense aus so.

Gibt es evtl. eine Möglichkeit, die Source IP bzw. Interface am LDAP Client auszuwählen oder festzulegen?

Hallo,

ich hole hier mal den alten Thread raus, da ich gerade vor dem selben Problem stehe.

Die LDAP Verbindung soll über einen IPsec Tunnel zwischen zwei OPNsensen aufgebaut werden.
Der Ping von der OPNsense zum LDAP Server funktioniert, wenn ich als Quelladresse eine Interface-IP der OPNsense angebe, für die auch ein IPsec Tunnel besteht.
Ohne Angabe einer Quelladresse geht der Ping nicht durch.
Einwandfrei hingegen funktioniert allerdings die DNS Auflösung von Unbound DNS, welche für die AD Domain per Query Forwarding den Windows DNS Server über den IPsec Tunnel abfrägt.
Das Routing aus den verschiedenen lokalen Netzen per IPsec in die Remote Netze und umgekehrt funktioniert ebenfalls wie gewünscht.

In der Firewall Diagnose ist auch zu sehen, dass die OPNsense die LDAP Verbindung über die WAN-IP am WAN Interface aufbauen möchte, statt über den IPsec Tunnel.
Eine statische Route habe ich testweise schon versucht, allerdings auch ohne Erfolg.

Wie kann ich erreichen, dass die OPNsense nicht das WAN Interface wählt, sondern die Verbindung über den IPsec Tunnel schickt?

Vielen Dank!

Hallo zusammen,

vielen Dank für Eure Tipp's. Ich hatte heute wieder etwas Zeit mich mit dem Thema zu beschäftigen und es läuft jetzt auch einwandfrei.
Für den Fall, dass noch jemand die selben Probleme hat, hier meine Lösung:
Wie schon von KHE geschrieben, muss das Outbound-NAT an der LAN-Schnittstelle im FB-Netz deaktiviert sein. Hierfür muss man die Regeln auf manuell stellen und die benötigten Regeln selbst anlegen.
Die für mich einfachere Lösung war dann aber, einfach das beim Anlegen der Schnittstelle automatisch erstellte Gateway unter System: Gateways zu deaktivieren. Somit wird dann auch kein NAT mehr zwischen dem FB-LAN und dem Opnsense-LAN mehr gemacht sondern direkt geroutet.

Schöne Grüße

Hallo,

nein, das werde ich später noch probieren.
Das Problem scheint aber wie bei stsnake Outbound NAT bzw. die automatisch erstelle Regel zum Interface im FB-Netz zu sein.
Nach dem Ändern auf manuelle Regeln ging das DVB-C Streaming, jetzt habe ich aber dadurch scheinbar andere Probleme, da teilweise Portfreigaben fürs Smarthome nicht mehr funktionieren zu scheinen. Hier muss ich mal die Einstellungen zu den Outbound-NAT Regeln durchgehen, habe gestern Abend nur noch schnell eine Regel mit den Standardeinstellungen erstellt, damit der Zugriff aufs Internet wieder läuft.
Kann man eventuell die automatisch erstellten Outbound-NAT Regeln irgendwo einsehen, welche Einstellungen da gesetzt sind, oder im Hybrid-Modus die automatischen Regeln fürs FB-Lan Interface deaktivieren? Bzw. muss für dieses Interface zwingend ein Gateway vorhanden sein? Falls es auch ohne Gateway über static routes geht, wär das meiner Meinung nach die einfachere Lösung. Hatte auch gestern mal den Fall, dass der Internetverkehr der Lan-Clients teilweise über die WAN IP der Fritzbox statt übers WAN der OPNsense geroutet wurde. Ich habe dann noch die Gatewayeinstellungen angepasst (WAN als Upstream markiert und Prioritäten geändert), seither ist es mir nicht mehr aufgefallen.

Schöne Grüße

Hallo KHE,

Ich versuche gerade ein identisches Setup wie bei dir zum Laufen zu bekommen.
OPNsense WAN hängt an der FritzBox Bridge Port und jetzt zusätzlich ein Interface der OPNsense im LAN der Fritzbox.
Statische Routen sind vorhanden, ich kann auch aus dem LAN der OPNsense aufs Webinterface der Box zugreifen.
Was jetzt noch nicht klappt, ist der DVBC Stream. Es scheint wohl an den Firewall Regeln zu liegen, denn wenn ich an der OPNsense die Firewall (Paketfilter) deaktiviere, funktioniert auch der Stream.
Habe schon testweise am Interface im LAN der Fritzbox eine Regel angelegt, die den Zugriff auf alles erlaubt, der Stream will aber immer noch nicht.
Welche Regeln hast Du hier angelegt, dass bei dir der Stream klappt?

Schöne Grüße

Hallo zusammen,

bei mir läuft das im Bridged Mode. Ob wie sich das mit Doulbe-NAT oder Exposed Host umsetzen lässt, keine Ahnung, ich glaube aber leider nicht.

Meine Konfiguration:
Fritzbox: 10.0.0.1 / 24
OPNsense WAN: DHCP (hängt an Bridged Port LAN 2 der Fritzbox, IP vom Provider)
OPNsense intern: 10.0.1.1 / 24
OPNsense zu Fritzbox: 10.0.0.254 / 24 (eigenes LAN zu LAN 1 der Fritzbox)

In der Fritzbox muss dann noch in den Netzwerkeinstellungen eine IP4 Route eingetragen werden, um die Pakete ins Netzwerk 10.0.1.0/24 über das Gateway 10.0.0.254 an die OPNsense zu schicken.

Es sind dann noch Firewall-Regeln notwendig, dass der Traffic von dem Fritzbox-Netz auch in das Interne Netz kommt und umgekehrt. Im Moment habe ich da noch zuviele Ports und Protokolle offen. Wenn ich etwas mehr Zeit habe, werde ich da noch weitere Einschränkungen vornehmen.

Mit dieser Einstellung kann ich dann die Fritzbox auch aus dem Internen Netzwerk der OPNsense administrieren.

Weitere Info:
Zum Start des Streams verbindet sich der Client via TCP-Port 554 zur Fritzbox und gleich danach werden noch zwei UDP-Verbindungen vom Client aus geöffnet aus dem Portbereich 5000+
Weitere Verbindungen habe ich im Firewall-Log nicht gesehen.
Durch NAT klappte es jedenfalls nicht. Ich hatte Anstatt der IP4 Routen in der Fritzbox ein Outgoing NAT auf dem Netzwerk zur Fritzbox aktiv und habe es damit nicht zum laufen gebracht.

So, habe gerade nochmal auf anderer Hardware (sowohl mit USB 2.0 und 3.0) getestet , auch hier bringe ich den Stick überhaupt nicht zum Laufen, auch nicht nach Reboot.
Die Firmwareversion deines Sticks hast du wahrscheinlich nicht mehr irgendwo abgespeichert?
Ich denke, ich flashe als letzten Versuch mal eine ältere Firmware drauf.

Irgendwie ist das ein merkwürdiges Verhalten.
Komischerweise funktioniert der Stick auf einer anderen Hardware auf meiner OPNsense Zuhause überhaupt nicht, da hatte ich ebenfalls schon verschiedene USB (2.0, 3.0) getestet.
Ich teste morgen mal auf einer Serverhardware, ansonsten habe ich auch noch ein anderes Testsystem rumliegen, das müsste ich aber erst mal aufsetzen.
Das Ganze sollte auch nur was temporäres werden, die Hardware (Beelink T4) lag auch noch rum. War ursprünglich auch mal für Reisen gedacht :D

PIN und Pin-wait macht leider auch keinen Unterschied.
Auch verschiedene USB Ports helfen hier nicht weiter.
Der Stick funktioniert erst nach einem weiteren Neustart nach dem Kaltstart.

Evtl. werde ich nochmal auf einer weiteren Hardware testen, ansonsten werde ich wohl hier mit der OPNSense und dem LTE Stick aufgeben und für den Fall einen Industrie-LTE Router kaufen.

Schöne Grüße

Deinen Beitrag dazu in dem anderen Post hatte ich bereits gefunden und auch das mit dem Init String "Z" schon probiert.

Ansonsten sieht meine Config ähnlich aus, verwende auch das Interface cuaU0.1, welches das einzige ist, was funktioniert.

Was ich aber nochmal testen werde ist die SIM-Pin, die habe ich aktuell deaktiviert.
Evtl. hilft pin-wait hier weiter...

Hast du dazu evtl. noch in Erinnerung, wie du den konfiguriert hast? Hast du dazu sonstige Einstellungen vorgenommen, oder nur ppp übers Webinterface konfiguriert?
Meiner ist ebenfalls mit Telekom branding.
Hotplug wäre egal, wenn es nicht geht, er sollte aber nach einem Kaltstart des Systems schon funktionieren, und nicht wie bei mir erst mit anschließendem Reboot...

Vielleicht liegt bei dir die Ursache dann woanders. Ich meine, bei mir ging der Ping noch, kann mich hier aber auch täuschen. Ich meine auch, mich zu erinnern, dass die Route (System->Routes->Status) noch vorhanden war. Auf alle Fälle konnte ich im Firewall Livelog sehen, dass das Paket auf der richtigen Schnittstelle (IPSec) durchgelassen wurde. An der Gegenseite kam das Paket aber nicht mehr an, soweit ich es noch richtig im Kopf habe.

Sorry, ich meinte natürlich die 6591 cable.
Ich bin hier auch im ex KabelDeutschland Gebiet, mit der selbst gekauften Fritzbox 6591 und der freigeschalteten Bridgeoption funktioniert es hier mit mehrern WAN IP's. Bekomme aber auch MaxCPE 10 provisioniert, ob das immer der Fall ist, kann ich allerdings nicht sagen. Seit der Umstellung funktioniert auch mein IPsec einwandfrei, hatte vorher die OPNsense als exposedHost im LAN der Fritzbox mit ähnlichem Verhalten wie bei dir.

Bei mir war die IPSec Verbindung ebenfalls vorhanden, ich konnte merkwürdigerweise nur manche IP-Adressen im Remote-Netzwerk nicht erreichen, obwohl ich im Firewall Log sehen konnte, dass alles durchgelassen wird, aber an der Gegenseite nichts ankam.
Kannst du die IP-Adressen z.B. anpingen? Ich meine, dass das bei mir funktionierte, das Aufrufen vom Webinterface eines Geräts z.B. ging aber nicht.

Mit meiner jetzigen Fritzbox 7591 läuft es jetzt super und ohne Abbrüche. Ich habe die Opnsense aber nicht als exposed Host eingetragen, sondern nutze die Funktion, einen LAN-Port der Box als Modem zu nutzen. D.h. ich habe an der Fritzbox selbst ein eigenes Netz mit öffentlicher IP und an der OPNsense selbst auch eine zusätzliche WAN IP. Mit einem Switch an diesem Port gehen auch weitere öffentliche IP's, da ich von Vodafone MaxCPE 10 provisioniert bekommen habe.
Die Konfigurationsmöglichkeit ist allerdings in der Fritzbox nicht standardmäßg sichtbar im Webinterface.

Hallo,

welches Modem bzw. Router hast du von Vodafone?
Ist das Modem im bridged Mode, d.h. hast du an der opnsense die öffentliche WAN IP oder bekommst du vom Modem / Router eine lokale IP zugewiesen?

Ich hatte mit der Fritzbox Cable von Vodafone und NAT ein ähnliches Problem mit IPsec. Nach einem Wechsel auf eine eigene, gekaufte Fritzbox Cable ohne Vodafone Branding hatte ich die Möglichkeit, den LAN1(?) Port der Fritzbox in den Bridgemode zu schalten und bekomme somit an der OPNsense die öffentliche IP am WAN Port.
Seitdem sind die Probleme mit den abbrechenden IPsec Verbindungen weg.

Schöne Grüße

Die Idee mit dem Script wäre auch nur eine Notlösung und ist auch nicht die Variante, die ich bevorzugen würde.
Da der Stick ja eigentlich funktioniert, müsste es doch auch eine Ursache / Lösung dazu geben?

Die Lösung mit dem LTE Router davor gefällt mir nicht so sehr, da ich doppeltes NAT und mögliche Probleme damit vermeiden möchte.

Gibt es alternativ LTE Sticks oder Router, die im Modembetrieb über OPNsense zuverlässig funktionieren und auch verfügbar sind?

Hallo,

seit mehreren Stunden/Tagen versuche ich mehr oder weniger erfolgreich, den Huawei E3372s-153 LTE Stick in Opnsense (21.7.3_3) zum laufen zu bekommen.
Ich hatte bereits zwei unterschiedliche Sticks verwendet, beide ohne Erfolg.
Verwendet habe ich folgende Konfiguration aus der PFsense Doku:

Code Select Expand

Huawei E3372s LTE USB-stick
    Link interface: /dev/cuaU0.1
    Init string: &F&C1&D2E0S0=0 (alternativ funktioniert auch "Z")


Das Logfile zeigt dazu folgende Einträge:

Code Select Expand

2021-10-05T08:59:29 ppp[42026] [opt3_link0] MODEM: chat script failed
2021-10-05T08:59:29 ppp[42026] [opt3_link0] CHAT: The modem is not responding to "AT" at ModemCmd: label.
2021-10-05T08:59:16 ppp[42026] [opt3_link0] Link: reconnection attempt 1
2021-10-05T08:59:13 ppp[42026] [opt3_link0] Link: reconnection attempt 1 in 3 seconds
2021-10-05T08:59:13 ppp[42026] [opt3_link0] LCP: Down event
2021-10-05T08:59:13 ppp[42026] [opt3_link0] Link: DOWN event
2021-10-05T08:59:13 ppp[42026] [opt3_link0] MODEM: chat script failed
2021-10-05T08:59:13 ppp[42026] [opt3_link0] CHAT: The modem is not responding to "AT" at ModemCmd: label.
2021-10-05T08:58:59 ppp[42026] [opt3_link0] LCP: LayerStart
2021-10-05T08:58:59 ppp[42026] [opt3_link0] LCP: state change Initial --> Starting
2021-10-05T08:58:59 ppp[42026] [opt3_link0] LCP: Open event
2021-10-05T08:58:59 ppp[42026] [opt3_link0] Link: OPEN event
2021-10-05T08:58:59 ppp[42026] [opt3] Bundle: Interface ng0 created

Nach langem Versuchen habe ich herausgefunden, dass der Stick merkwürdigerweise nach einem Reboot der Opnsense einwandfrei funktioniert, nicht jedoch nach einem Kaltstart.

Hier der Anfangsteil aus dem Logfile nach einem Reboot und funktionierender LTE WAN Verbindung:

Code Select Expand

.....
2021-10-05T09:03:19 ppp[76951] [opt3_link0] MODEM: chat script succeeded
2021-10-05T09:03:19 ppp[76951] [opt3_link0] CHAT: Connected at an unknown speed.
2021-10-05T09:03:19 ppp[76951] [opt3_link0] CHAT: ATDT*99#
2021-10-05T09:03:19 ppp[76951] [opt3_link0] CHAT: Dialing server at *99#...
2021-10-05T09:03:19 ppp[76951] [opt3_link0] CHAT: Detected Custom modem.
2021-10-05T09:03:19 ppp[76951] [opt3_link0] CHAT: +CGDCONT=1,"IP","internet.telekom"
2021-10-05T09:03:18 ppp[76951] [opt3_link0] LCP: LayerStart
2021-10-05T09:03:18 ppp[76951] [opt3_link0] LCP: state change Initial --> Starting
2021-10-05T09:03:18 ppp[76951] [opt3_link0] LCP: Open event
2021-10-05T09:03:18 ppp[76951] [opt3_link0] Link: OPEN event
2021-10-05T09:03:18 ppp[76951] [opt3] Bundle: Interface ng0 created

Ich habe bereits mehrere Versuche gemacht mit einem Boot-Delay (sowohl über die loader.conf.local, das bootdelay Addon oder über das BIOS gemacht, was alles keinen Unterschied macht. Der Stick funktioniert immer nur nach einem Reboot, nie nach einem Kaltstart oder Spannungsausfall.

Dazu kann ich noch erwähnen, dass ich es auf einer anderen OPNsense mit anderer Hardware und selbem LTE-Stick und identischer Konfig bisher auch nach einem Reboot noch nicht zum Laufen gebracht habe. Hier scheint der Stick überhaupt nicht zu funktionieren.

Hatte jemand schon mal ähnliche Probleme bzw. eine Idee, woran dies liegen könnte?
Gibt es alternativ als Notlösung eine Möglichkeit, OPNsense nach einem Kaltstart oder Spannungsausfall automatisch neuzustarten? Kann man hier evtl. in einem Script zwischen einem vorausgegangenen Kaltstart bzw. Reboot unterscheiden, um keine Rebootschleife zu erzeugen?

Schöne Grüße