Messages

Der Fehler hat sich mit dem Update auf die Version 20.7.8 von selber erledigt. Jetzt geht das Routing wieder wie gehabt. Ich habe dennoch mal die (jetzt wieder deaktivierte) Regel angehängt.

Ich habe mal eine grobe Skizze angehängt.

Auf dem jetzigen LAN-Interface ist kein Gateway direkt definiert (weder das echte LAN-Interface (ist aktuell inaktiv), noch eines der anderen Nicht-WAN-Interfaces). Auf den WAN-Interfaces sind Gateways über PPPoE definiert. Das Routing ins LAN passiert über statische Routen zum Aruba-Switch. Auch ist auf dem LAN-Interface kein Blocking von private oder bogon networks aktiv.

Damit das Routing aber funktioniert, musste ich eine Outbound-Rule für das jetzige LAN-Interface erstellen, damit die Firewall überhaupt zum Aruba hinkommt. Das ergibt für mich jedoch auch keinerlei Sinn, anders funktioniert es aber nicht.

Als Outbound-NAT-Modus ist jetzt manuell eingestellt, nix automatisch und nix hybrid. Für ausgehende Verbindungen über WAN sind zwei manuelle Regeln (für jede WAN-Verbindung eine) angelegt.

Das eigentliche LAN-Interface war das Interface, welches ich rein für das Management genutzt habe. Aktuell habe ich es deaktiviert und nutze OPT1 als quasi LAN-Schnittstelle. Der ursprüngliche Gedanke war, dass die LAN-Schnittstelle rein für das Management der Firewall genutzt werden soll und daher auch nur vom Management-System aus erreichbar war. Der Internetverkehr der Clients soll über OPT1 laufen. So ist es jetzt konfiguriert, nur dass das LAN-Interface aktuell nicht zugewiesen ist. Alle in Richtung LAN zeigenden Interfaces sind übrigens VLAN-Interfaces auf einem 4-Port-LACP-LAG mit Ausnahme der beiden WAN-Interfaces.

Ich habe es jetzt so wie du sagst gemacht und vom hybriden Outbound-NAT Modus auf den manuellen Modus gewechselt und die notwendigen Outbound-Rules für die WAN-Interfaces manuell angelegt. Et voila, jetzt kann ich auch wieder die internen Server anpingen. Ich muss zwar eine explizite Rule für die LAN-Schnittstelle anlegen, die besagt, dass die Firewall selbst ausgehend ins LAN überall mit allen Services hin darf, aber es funktioniert jetzt auch soweit. Muss ich bei dieser Firewallregel noch etwas beachten in Sachen Sicherheit oder ist die so in Ordnung?

Weil es für Probleme sorgt und ich nicht weiß, woher die NAT-Rules für das LAN-Interface kommen. Ich habe den Hybrid-Modus abgeschaltet und die beiden WAN-Rules manuell neu erstellt. Jetzt kann ich auch ganz normal wieder die Server im Management-Netz anpingen.

Ja, das Standard-LAN Interface verwende ich zu Management-Zwecken und habe es auch in "Management" umbenannt. Für den eigentlichen Zugang ins LAN habe ich OPT1 verwendet und auch so bezeichnet.

Hallo zusammen,

ich habe hier ein ziemlich merkwürziges Problem und sehe den Wald vor lauter Bäumen nicht mehr. Auf meiner Firewall habe ich im Hybrid-Modus automatische Outbound-NAT Regeln auf der LAN-Schnittstelle (siehe Bild im Anhang), aber ich weiß nicht woher. Es gibt mehrere IPSEC VPN-Tunnel (S2S und C2S).

Ich bin über das Phänomen gestolpert, weil ich trotz korrektem Routing und entsprechenden Firewall-Regeln von der Firewall aus nicht unseren Management-Server anpingen kann. Umgekehrt funktioniert es einwandfrei, ich kann vom Management-Server aus die Firewall anpingen und auf die Web-GUI zugreifen.

Meine Vermutung ist, dass diese NAT-Rules die Verbindungen ins LAN stören.

Hat jemand eine Idee?

Vielen Dank schonmal im Voraus.

Hi,

habe ich probiert, aber keine Änderung. Der Fehler besteht weiterhin.

Grüße

Anbei die Screenshots der Configs für P1 und P2. Wenn der Fehler auftritt, gibt es keine Protokolle mehr (zumindest nicht bei mir im Prod und in der Testumgebung auch nicht), das ganze System friert einfach ein.  :(

Hallo zusammen,

ich habe ein merkwürdiges Phänomen: Wenn ich eine route-basierte IKEv2 VPN-Verbindung konfigurieren will, stürzt OPNsense komplett ab. Nach einem Neustart des Systems habe ich nur knapp 30 Sekunden Zeit, den Eintrag wieder zu löschen oder die Firewall stürzt wieder ab. Ich kann den Fehler in einer Testumgebung reproduzieren.
Der Fehler taucht dann auf, sobald man auf "Apply" klickt. Selbst nach 10 Minuten warten passiert nichts, alle bestehenden Internetverbindungen brechen zusammen und eine Konsolenbedienung ist auch nicht möglich.

Die VPN-Parameter sehen wie folgt aus:

- Phase 1 Verschlüsselung: AES256
- Phase 1 Signierung: SHA256
- Phase 1 DH-Group: 14
- Phase 1 DPD: Aktiv (Poll alle 120 Sekunden)
- Phase 1 Key Exchange: IKEv2
- Phase 1 Identifier (My/Remote): IP/IP

- Phase 2 Verschlüsselung: AES256
- Phase 2 Signierung: SHA256
- Phase 2 PFS: DH-Group 14

Kann jemand das Verhalten nachvollziehen, bevor ich ein Ticket in Github aufmache?

Viele Grüße

Short update:

Code Select Expand

root@GLB-FIW-01:~ # ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
36 bytes from 62.155.246.135: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 f15d   0 0000  40  01 1264 93.239.13.84  10.0.0.1

36 bytes from 62.155.246.135: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 769d   0 0000  40  01 8d24 93.239.13.84  10.0.0.1

36 bytes from 62.155.246.135: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 0cb3   0 0000  40  01 f70e 93.239.13.84  10.0.0.1

36 bytes from 62.155.246.135: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 1427   0 0000  40  01 ef9a 93.239.13.84  10.0.0.1

36 bytes from 62.155.246.135: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 3d88   0 0000  40  01 c639 93.239.13.84 10.0.0.1

This ping messages appear always. I created an outbound NAT to the LAN-Interface of OPNsense, created a firewall rule with the LAN interface as gateway, but nothing works. I just want to get traffic from the firewall itself (DNS redirects for a specific domain in this case) to be redirected to a dns server on the other site of a IKEv2 S2S tunnel.

Does anyone have an idea?

Hello everyone,

I want to forward DNS queries to a DNS server on the other site of a IKEv2 Site2Site-Tunnel. My clients can resolve queries without problems to this DNS server, but the firewall does not, perhaps because of not having any valid IP address to the VPN tunnel by default.

Is there any way I can accomplish this?

Thanks in advance

Hello,

I have searched the forum on news about user-based firewall policies. I have found several entries and also a plugin which was discussed last year for implementing it in OPNsense.

Are there any news about this topic? Is anybody developing it or planning to do it? I would volunteer for testing it, but I am not a programmer.

Best regards

Maybe I can help. I run OPNsense on a Sophos SG330rev1 and I got my LCD screen working with lcdproc. Use the following config:

Code Select Expand

[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=hd44780
Bind=127.0.0.1
Port=13666
ReportToSyslog=yes
User=nobody
Foreground=no
Hello="  Welcome to"
Hello="   OPNsense!"
GoodBye="Thanks for using"
GoodBye="   OPNsense!"
WaitTime=5
TitleSpeed=5
ServerScreen=on
Backlight=open
ToggleRotateKey=Enter
PrevScreenKey=Up
NextScreenKey=Down

[menu]
MenuKey=Escape
EnterKey=Enter
UpKey=Up

[hd44780]
ConnectionType=ezio
Device=/dev/cuau1
Keypad=yes
Size=16x2
KeyMatrix_4_1=Enter
KeyMatrix_4_2=Up
KeyMatrix_4_3=Down
KeyMatrix_4_4=Escape


You may have to change a few things, especially under the hd44780-section, but this should give you a start for getting the LCD panel to work.

Du musst zuerst unter "Firewall" - "NAT" - "Outbound" den Hybridmodus aktivieren. Danach kannst du manuelle NAT-Regeln erstellen. Anschließend erstellst du eine Regel ausgehend von deinem PC ins Internet über die verwendeten SIP/RTP-Ports als Quell-Ports und aktivierst dann weiter unten den Haken "Static Port". Dies dient dazu, dass die Firewall den ursprünglichen Quellport beibehält, wenn sie die Gegenstelle anspricht. Ohne diese Regel würde sich der Quellport durch das ausgehende NAT ändern.

Leider nein. Entweder mit siproxd, was bei mir auch nicht sauber funktioniert oder aber wenn es eine Telefonanlage/IP DECT-Basis wäre, mit einem eigenen VLAN und NAT. Letzteres habe ich nun im Einsatz und das läuft soweit. Wichtig ist, dass bei ausgehendem NAT Static-Port für VoIP-Verkehr genutzt wird, sonst klappen die Anrufe nicht.