Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - bsch

#1
German - Deutsch / Re: VPN Status per SNMP lesen
November 30, 2024, 10:09:42 PM
Das habe ich jahrelang vergebens versucht für meine IPsec VPNs zu basteln... Am Ende blieb wirklich immer nur ein ICMP Ping und/oder Test-Aufrufe von Ports auf der Gegenseite um die Verfügbarkeit zu prüfen.
Ist leider unschön, aber war die einzige Möglichkeit für mich den "Status" zu prüfen.
#2
German - Deutsch / Re: Full NAT wie bei der Sophos UTM
November 30, 2024, 10:06:02 PM
Nabend!

Also so richtig klar wird dein Vorhaben nicht. Wenn du ein IPsec VPN aufbaust und die Gegenseite mit einem öffentlichen Adress-Bereich durch den Tunnel kommt (was ja kein Thema ist), benötigst du ja noch viel weniger ein NAT als sonst beim Aufbauen von unzähligen Tunneln.

Das NAT sollte die Gegenseite dann als Source-NAT machen und die Phase 2 entsprechend konfigurieren. Alles andere macht keinen Sinn :D

#3
Moin!
Das habe ich zu genüge im professionellen Umfeld auf hochproduktiven Firewalls gemacht :)
Es ging da um virtualisierte Instanzen und hat immer einwandfrei funktioniert. Lediglich die Interfaces sind in manchen Versionen durcheinander gegangen. Das habe ich in dem Hypervisor einfach wieder passend umkonfiguriert und somit war die Downtime nicht größer als 5 Minuten.

Es waren verschiedenste Dienste im Einsatz. IPsec, OpenVPN, BGP, NAT, etc ...

Ich habe damit auch gelegentlich mehrere Releases "übersprungen". Und im Zweifel schaltest du die alte Kiste wieder ein und gut. War aber nie notwendig.
#4
German - Deutsch / DHCP Server Option 43
June 25, 2024, 05:10:21 PM
Hallo zusammen,

ich möchte aktuell eine OPNsense mit einem DHCP-Server ausrollen. Die "Besonderheit" ist allerdings, dass ich die Option 43 an alle Clients senden möchte. Es ist die aktuellste OPNsense Version installiert und ich nutze den ISC-DHCP, da der KEA noch keine Options in der GUI ermöglicht. ISC-DHCP Option 43 konfiguriere ich normal in der GUI über Advanced und dann Option 43 als String und den entsprechenden HEX-Wert meiner URL, die mitgegeben werden soll.

Der DHCP-Client muss diese Information bei jedem DHCPOFFER vom Server gesendet bekommen. Das macht die Sense wohl nicht von sich aus.

Mit einem ISC-DHCP auf einer normalen Linux-Kiste geht das ohne Probleme mit folgenden Parametern:
option dhcp-parameter-request-list 3, 5, 6, 43;
option vendor-encapsulated-options 68:74:74:......;


Auch beim Mikrotik Board hat man im DHCP Server die Möglichkeit "force" mitzugeben, sodass dies funktioniert.

Kann mir da jemand einen Tipp geben oder hatte ein ähnliches Problem schon mal?

Danke euch!
#5
Danke für die Rückmeldung. Klassischer Fall von: "wenn man nicht alles selber macht".

Es gab lediglich ein Problem mit dem VLAN in dem Hypervisor. Habe schon an mir selbst gezweifelt. :-D

Um deine Frage aber noch zu beantworten: Ich stelle den Einwahlserver selbst bereit und natürlich sitzt da irgendwo eine ONT davor.
#6
Im Grunde ist das Glas. Aber der Virtualisierungs-Host ist entsprechend an das VLAN angebunden und das wird untagged übergeben. Für mein Verständnis sollte das dann ohne weitere VLAN Konfiguration funktionieren. Daher habe ich jetzt nur ein Interface in der OPNsense auf PPPoE konfiguriert und das Interface entsprechend in VMware angebunden.
#7
German - Deutsch / PPPoE ohne physikalisches Modem
April 15, 2024, 03:59:36 PM
Hallo zusammen,

ich verzweifle grade an der PPPoE Konfiguration meiner OPNsense. Ist nicht die erste Instanz unter meiner Administration, allerdings kam ich mit PPPoE nie in Berührung.

Ich habe eine virtualisierte OPNsense und möchte gerne eine PPPoE Einwahl über ein Interface machen. Das entsprechende VLAN und die Einwahl-Daten habe ich konfiguriert. Allerdings wird bisher keine Verbindung aufgebaut. Ich habe nicht wie viele andere ein physikalisches Modem im Einsatz. Daher nun meine Frage ob das überhaupt so funktionieren kann, wie ich mir das wünsche?

LG
#8
Moin zusammen,

ich beobachte das Problem auch seit einiger Zeit. Die Weboberfläche "stirbt" sobald man am IPsec aktiv konfiguriert oder z.B. einige Tunnel kurz nacheinander neuaufbaut etc...
Das äußert sich so, dass die Status Page dann leer bleibt, die VPNs gehen nach und nach offline und am Ende ist auch die Oberfläche tot.

Workaround ist aktuell folgender: charon Dienst über CLI killen, WebGUI Restart, IPsec deaktivieren, IPsec aktivieren und IPsec restart. Danach langsam die VPNs nach und nach wieder aufbauen. Dabei empfiehlt es sich Geduld mitzubringen. Ist man zu schnell, muss die ganze Prozedur erneut durchgeführt werden.
Aktuell befinden sich rund 40 aktive Tunnel auf meiner OPNsense Installation.
#9
German - Deutsch / Re: NAT vor route-based VPN
May 19, 2023, 10:51:51 AM
Jap, daher meine Frage :D Ich möchte idealerweise nichts aufgeben. Nunja, wenn das nicht geht, muss ich dafür wohl eine weitere VM nutzen. Nützt ja nichts.
#10
German - Deutsch / Re: NAT vor route-based VPN
May 19, 2023, 10:25:15 AM
Vielen Dank für die schnelle Antwort! Das war mir nicht bekannt.

Mit Policy-Based VPNs und NAT habe ich auch durchweg positive Erfahrungen. Da habe ich auch sehr viele Tunnel gebaut.

Allerdings verlangt es in diesem Fall die Gegenseite nunmal so leider. Dann muss ich da wohl etwas anderes außerhalb der FW basteln. Oder hast du einen Work-Around parat? :)

Danke!
#11
German - Deutsch / NAT vor route-based VPN
May 19, 2023, 08:06:26 AM
Hallo zusammen,

ich habe mal eine Frage bezüglich einem route-based VPN. Und zwar handelt es sich um folgendes Szenario:

Ich verwalte auf meiner Seite eine OPNsense. Die Gegenseite ist ein fremd-verwaltetes Amazon AWS Netzwerk zu dem eine route-based VPN-Verbindung aufgebaut wird. Der Tunnel ist online (Phase1 und Phase 2 erfolgreich aufgebaut).
Die Gegenseite erwartet (aus Gründen) aber ein anderes als mein LAN-Netz (ein /16). In der alten FW (FortiGate) konnte ich das NAT ohne Probleme konfigurieren. In der Sense bekomme ich das nicht ans Laufen. Weder per One-To-One BI-NAT noch per Outbound NAT-Regel. Sobald die NAT Regel greift, läuft der Traffic nicht ins VPN rein. Deaktiviere ich sämtliche NAT-Regeln für diesen Traffic, landet der Traffic mit seiner richtigen IP-Adresse im VPN. Die Gegenseite kann aber nicht mit der Adresse arbeiten und erwartet wie gesagt ein anderes Netz.

Ist das schlichtweg nicht möglich? Muss ich vllt zusätzlich SPD Einträge setzen? Das kann man ja in einem "normalen" Tunnel einfach in der Phase2 konfigurieren.
#12
Es gab ein allgemeines Routing Problem der OPNsense. Nach einem Neustart war alles behoben.
#13
Hallo zusammen,

ich habe aktuell das Problem, dass die Routen nicht mehr automatisch angelegt werden wenn ein rule-based IPsec VPN online geht. Das betrifft aktuell glücklicherweise nur einen Tunnel. Es führt allerdings zu sehr komischen Effekten.

Version:
OPNsense 21.7.5-amd64
FreeBSD 12.1-RELEASE-p21-HBSD
OpenSSL 1.1.1l 24 Aug 2021

Sowohl in der Tunnel Konfiguration als auch in der IPsec Konfiguration ist aktiviert, dass die Routen/Rules automatisch angelegt werden.

Konfiguriere ich die Routen händisch, funktioniert das auch nicht wirklich.

Ist das eventuell ein bekanntes Problem? Workaround? Kann das durch eine Vielzahl von IPsec VPNs bedingt sein ? Das ist Tunnel Nummer 31


#14
Ah super. Vielen Dank. Ich hatte da ein kleines Routing Problem. So macht das nun auch Sinn. :)
#15
Hallo zusammen,

ich möchte gerne mehrere OPNsense Instanzen auf einen Syslog-Server loggen lassen. Bei dem ersten System funktioniert das auch wunderbar.

Bei den anderen Systeme stellt sich mir nun die Frage ob ich den Traffic zum Syslog-Server über ein bestimmtes Interface raus geben kann? In der GUI sehe ich keine Möglichkeit das zu konfigurieren. Aktuell wird scheinbar automatisch das WAN Interface verwendet. Das ist bei meinem Setup aber so nicht umsetzbar und ich würde das gerne ändern.

Vielleicht kann mir ja jemand einen Tipp geben oder steht vor dem gleichen Problem.

Eingesetzte Version: OPNsense 21.7.5-amd64

Vielen Dank und schöne Grüße,
Björn