Messages

Zuerst nicht, daher habe ich dann noch mal die Konfigurations Historie beim Backup zurückgespielt, dann vor dem Aufbau des HAs die Interfaces inkl. Opt korrekt angelegt, das HA erstellt und dann testweise noch ein neues Interface hinzugefügt. Direkt wieder der Fehler, dass das Backup nicht erreichbar wäre.

Hallo zusammen,

ich habe leider nichts gefunden, außer, dass man bei einem HA, wenn man neue Interfaces anlegt, dieses auf beiden Seiten gleich machen muss.

Jedoch jedes mal, wenn ich genau gleich das neue Interface zuerst auf dem Master, dann auf dem Backup anlege und die Bezeichnungen exakt gleich sind, bekomme ich beim nächsten Konfigurations-Sync den Fehler "the backup firewall is not accessible or not configured".

Ich dachte zuerst, dass man dem Interface zwangsweise eine IP je Firewall zuweisen muss und es nicht reicht nur eine virtuelle IP zu nehmen. Aber auch wenn ich dem Interface noch je Firewall eine zuweise, ändert es nichts mehr am Fehler.
Jedes Mal ist das HA korrupt und es geht kein Sync mehr.

Irgendetwas muss ich doch falsch machen oder nicht beachten?

Ok, ich habe es mir selbst beantwortet...
Ich habe vergessen, ESP, 500 und 4500 auf der WAN Seite freizugeben.
Daher funktionierte es nur, wenn man die jeweilige Firewall aktiv aufforderte mit der anderen Seite zu kommunizieren, da sie dann wohl auf die WAN Seite horcht und ohne die Freigabe nicht.

Zumindest ist das meine aktuelle Vermutung und der Tunnel baute sich aktuell einmal alleine auf.

Was sagen denn die Logs nach Neustart? Irgendwelche Hinweise?

Schwierig, da einfach kaum etwas zu sehen ist.

Firewall A will eine Verbindung zum Firewall B aufbauen.
Bei Firewall B sieht man nichts in den IPSec Logs, bei Firewall A sieht man:

Code Select Expand

2021-08-29T20:46:23 charon[91089] 09[IKE] <con2|20875> establishing IKE_SA failed, peer not responding
2021-08-29T20:46:23 charon[91089] 09[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:45:07 charon[91089] 08[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:45:07 charon[91089] 08[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:44:25 charon[91089] 07[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:44:25 charon[91089] 07[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:44:02 charon[91089] 10[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:44:02 charon[91089] 10[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:43:49 charon[91089] 10[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:49 charon[91089] 10[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:43:42 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:42 charon[91089] 05[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:43:38 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:38 charon[91089] 05[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> peer not responding, trying again (3/3)
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:42:22 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:42:22 charon[91089] 13[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:41:40 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:40 charon[91089] 13[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:41:17 charon[91089] 16[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:17 charon[91089] 16[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:41:05 charon[91089] 14[CFG] received stroke: route 'con2'
2021-08-29T20:41:05 charon[91089] 11[CFG] added configuration 'con2'
2021-08-29T20:41:05 charon[91089] 11[CFG] received stroke: add connection 'con2'
2021-08-29T20:41:05 charon[91089] 13[CFG] deleted connection 'con2'
2021-08-29T20:41:05 charon[91089] 13[CFG] received stroke: delete connection 'con2'
2021-08-29T20:41:05 charon[91089] 14[CFG] received stroke: unroute 'con2'
2021-08-29T20:41:04 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:04 charon[91089] 14[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:40:57 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:40:57 charon[91089] 14[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:40:53 charon[91089] 09[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:40:53 charon[91089] 09[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> peer not responding, trying again (2/3)
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:40:49 charon[91089] 07[CFG] received stroke: route 'con2'
2021-08-29T20:40:49 charon[91089] 09[CFG] added configuration 'con2'
2021-08-29T20:40:49 charon[91089] 09[CFG] received stroke: add connection 'con2'
2021-08-29T20:40:49 charon[91089] 07[CFG] deleted connection 'con2'
2021-08-29T20:40:49 charon[91089] 07[CFG] received stroke: delete connection 'con2'
2021-08-29T20:40:49 charon[91089] 10[CFG] received stroke: unroute 'con2'
2021-08-29T20:39:37 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:39:37 charon[91089] 14[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:38:55 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:55 charon[91089] 14[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:38:32 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:32 charon[91089] 13[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:38:32 charon[91089] 11[CFG] received stroke: route 'con2'
2021-08-29T20:38:32 charon[91089] 15[CFG] added configuration 'con2'
2021-08-29T20:38:32 charon[91089] 15[CFG] received stroke: add connection 'con2'
2021-08-29T20:38:32 charon[91089] 11[CFG] deleted connection 'con2'
2021-08-29T20:38:32 charon[91089] 11[CFG] received stroke: delete connection 'con2'
2021-08-29T20:38:19 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:19 charon[91089] 05[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:38:12 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:12 charon[91089] 05[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:38:08 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:08 charon[91089] 05[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:38:08 charon[91089] 05[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:38:08 charon[91089] 06[CFG] received stroke: initiate 'con2'



Die IPs sind abgewandelt.
Da auf beiden Seiten eine FritzBox am WAN hängt und die OPNsense nur per ExposedHost etc. freigegeben ist, könnte es natürlich auch sein, dass hier irgendetwas hängen bleibt.
Wobei es ja direkt wieder funktioniert, wenn ich auf beiden Firewalls etwa zeitgleich den reconnect der VPN anwerfe.


"Start on traffic" bedeutet doch nur, dass sobald aus dem LAN Traffic zu einer IP des Tunnels geleitet wird, der VPN versucht wird aufzubauen.
"Start immediate" ist bei mir aktiv und heißt ja eigentlich, dass er sofort und immer die Verbindung versuchen soll aufzubauen.

Hm, keiner eine Idee, wieso das passiert bzw. wie man es verhindert oder zumindest behebt?

Wäre es ggf. sinnvoll, wenn ich es im englischen Forum poste?

Hallo zusammen,

trotz der Einstellung, dass der Tunnel sich direkt starten soll, habe ich bei mehreren OPNSense den Fall, dass der VPN Tunnel sich einfach nicht mehr automatisch aufbaut.

Der VPN liegt z.B. zwischen FritzBox und OPNSense als auch OPNSense zu OPNSense.
Alle Anschlüsse haben Dyn IPv4 Adressen.

Ich muss manuell einmal zur OPNSense mich aufschalten und in der IPSec Übersicht manuell den Tunnel, der auf einem "orangenen Pfeil" steht, noch einmal mit einem Klick auf diesen Pfeil starten.

Das ggf. zuerst die Verbindung fehl schlägt, kann ich beim IPv4 Wechsel der IP nachvollziehen, wenn noch die falsche IP aufgelöst wird. Nur wieso versucht die Firewall es nicht alle paar Minuten immer wieder bzw. wie bekomme ich das hin?

Hallo zusammen,

ich hoffe ihr könnt weiterhelfen.


Client -> Firewall1 <-IPSec-> Firewall2 <-IPsec-> Router

z.B.
Firewall1 IP/Netz: 192.168.1.1 /24
Firewall2 IP/Netz: 192.168.2.1 /24
Router3 IP/Netz: 192.168.3.1 /24

Nun will ich mit dem Client, der bereits korrekt zum Netz der Firewall2 kommt, zum Router.

Dafür habe ich im IPsec Phase2 das Netz des Router Netzwerks ebenso hinzufügt zum Tunnel zwischen Firewall1 und 2.

Auf der Firewall2 habe ich eine Firewall Regel angelegt Firewall2->Router IP outbound ICMP, Ping funktioniert auch. Generell geht die IPsec Verbindung zwischen den beiden Netzen.

Dazu noch eine Regel der Firewall2 "Firewall1 Netz" zu "Router Netz" erlaubt IPv4 Traffic * (zum Test) Eine inbound und eine outbound Regel.

Beim NAT eine Outbound NAT Regel, Firewall1-Netz zum Router-Netz, verschiedene Interfaces ausprobiert und NAT Adress auch bereits "Interface Adress" und auch "Firewall2-Interface-Adress".

NAT, da im Router keine Route eingetragen ist für das "Firewall1-Netz".

Ich habe schon etwas mit den NAT Regeln rumprobiert, aber habe bisher keine Verbindung vom Firewall1-Netz zum Router-Netz hinbekommen. Eigentlich dürfte das doch gar kein Problem mit NATing auf der Firewall2 sein?

Du kannst in den WebAdmin Einstellungen festlegen, auf welchen Interfaces er horchen soll.
System->Settings->Administration->"Listen Interfaces".
Dort einfach nur dein LAN bzw. wenn vorhanden MGM Interface auswählen.

Findet eventuell bei Anwendung 1 ein "No-NAT" statt vom MAC Book zur FritzBox und beim 2. Anwendungsfall ein SNAT/Masq.?

Die SIP Clients wenden sich an die FB als Zugang, richtig? Und ei FB baut dann die weitere Verbindung auf?
Oder bauen alle Clients eine Verbindung direkt zu 1und1 auf?

Wenn über die FB:
Generell würde ich für die eingehende Verbindungen/Telefonate empfehlen, dass zur FB ein Routing stattfindet und in der FB die entsprechende Route über die OPNSense einstellen in ein internes LAN für den Port, damit du mehrere interne "Telefone" benutzen kannst, wenn ein Anruf reinkommt.

Also [SIP-Clients] -> [FB] NO-NAT
Danach die Regel alles andere normalerweise (LAN) -> * mit SNAT mit der "WAN-IP" der OPNsense.

Dann bei der FB eine statische Route für ein LAN Netz über GW "WAN-IP" der OPNsense.

Und die entsprechende FW Regeln noch einstellen.

Aber wenn man Tunnel hat, liegen an deren Enden ja auch RFC1918 Netze, und die sollen ja auch nur aus bestimmten Subnetzten erreichbar sein. Dann funktioniert das mit dem Alias für RFC1918 nicht so einfach. Aber so wie ich es mache schon.

Ob die Netze intern oder über Tunnel angeschlossen sind macht doch keinen Unterschied. Ein über Tunnel angeschlossenes Netz ist doch in etwa wie ein langes Lan Kabel - sehr vereinfacht.
Statt, dass ich (lan) to (any) erlaube, erlaube ich ja mit der Regel von Mks eben (lan) to (alles außer "lan-netze") was sozusagen dann ja (Internet) ist. Alle anderen Pakete werden geblockt, also alle Pakete von (lan) zu anderen Lan-Netzen also auch zu anderen VPNs. Für die VPN Verbindung gibt man natürlich weitere allow Regeln an. Dann klappt das doch alles und ist eleganter, finde ich.
Im Prinzip erreicht man ja genau was ich meinte mit "zu Internet".
Ich wusste nur nicht, dass man eben bei OPNsense auch verneinen kann.

Ich finde es gut (v.a. auch für die Übersichtlichkeit), dass man mit einer Regel ein Netz / einen Port schaltet und nicht gleich rudelweise (wenn man das braucht, macht man sich einen sinnvollen Alias). Man muss halt vorher etwas planen und immer das Gehirn angeschaltet lassen. Wie meistens im Leben... :-D

Naja ich finde es eben unnötig und unübersichtlicher Aliase anlegen zu müssen oder mehrere Regeln, nur weil ich in einer Regel z.B. 3 Ports freigeben möchte oder 3 Hosts die aber ansonsten nie zusammen als Gruppe in anderen Regeln vorkommen sondern wirklich nur in einer Regel. In dem Fall muss ich eben für alle diese Situationen 3 Regeln anlegen oder eben Aliase einrichten und habe auf lang oder kurz einen Wildwuchs in der Alias-Liste. Ich finde, in beiden Möglichen Szenarien muss man sein Gehirn einschalten - denn auch wenn man mehrere Hosts oder Ports zusammen in einer Regel unterbringen kann, muss man die Übersicht behalten und überlegen ob das in diesem Fall auch sinnvoll ist und ggf. doch Aliase anlegen. Man hat aber eben die Freiheit ob oder ob nicht. Da hat wohl jeder seine eigenen Vorlieben. Komplett ohne Aliase würde ich selbst auch niemals leben wollen. Ich unterscheide jedoch eben gerne, wann ich einen nutzen will oder nicht. Bei OPNsense bin ich hier leider dazu gezwungen, wenn ich keine tausenden Regeln anlegen will - was wohl noch schlimmer wäre.

Moin.

Das mit der Block Regel ganz oben für alle anderen "internen" und auch "VPN-Netze" etc. habe ich mir ebenfalls bereits alt Notlösung gedacht. Allerdings muss man diese liste auch sehr gewissenhaft bei neuen Netzen führen und für jedes Interface separat führen. Dazu müssen alle Regeln, die den Traffic in diese anderen Netze erlauben, vor dieser Block Regel sein.

Da muss es doch elegantere Lösungen geben?

Ich finde es bei OPNsense schon sehr schade, dass man in eine Regel nicht direkt mehrere Ports und auch Quellen oder Ziele gleichzeitig hinterlegen kann, ohne direkt jedes Mal ein Alias als Gruppe erstellen zu müssen.
Wirkt einfach echt uralt.

Hallo zusammen.

Wie bekomme ich es hin, dass ich eine "Lan -> Internet" Regel erstellen kann.
"Any" bedeutet, dass es auch in andere Netze, die die OPNsense kennt, erlaubt ist. Das ist jedoch definitiv nicht gewünscht. z.B. LAN -> LAN_unsecure oder LAN -> VPN_Tunnel sollte ja nicht erlaubt sein, was es durch "any" jedoch ist.
Ich habe "WAN Net" probiert, was jedoch nicht funktioniert, da er WAN Net natürlich ernst nimmt und wirklich nur das WAN Netz erlaubt. Ebenso habe ich ein Alias mit "External" erstellt. Das brachte jedoch auch nichts - was External als Alias bewirkt weiß ich auch nicht, jedenfalls nicht das, was ich wollte.

Ich habe die Netzwerk Konfiguration folgend: WAN <-> Router <-> Firewall <-> LAN. NAT erfolgt sowohl bei der LAN -> Firewall -> Firewall_WAN_INT als auch Firewall -> Router -> Router_WAN_Int.

Ich hoffe jemand kann hier schnell helfen. Von anderen Firewalls kenne ich es so, dass es neben dem "any" auch ein "Internet" gibt, in dem alle Netze drin sind (wie any) nur ohne alle selbst bekannten Netze).

Sehe ich es richtig, dass du es so haben willst?

(WAN) <---> [Router] - Netz: 192.168.1.0/24 mit (Clients)+["WAN" Interface Firewall] <--> Netz: 192.168.10.0/24 mit [LAN Interface Firewall] + (Clients hinter Firewall)

Gibt es einen Grund dafür, dass ein paar Clients vor und andere hinter der Firewall sind und trotzdem miteinander kommunizieren sollen?

Wenn unbedingt ja, dann müssen die entsprechenden Clients eine manuelle Routing Regel bekommen, dass Datenverkehr zum Netz 192.168.10.0/24 über die WAN IP-Adresse der Firewall gesendet werden muss statt über das Standard Gateway.
Ebenso braucht man eine No-NAT Regel, dass der Datenverkehr vom 10er Netz zu den entsprechenden Clients im 1er Netz nicht über NAT rausgeschickt wird.
Und natürliche entsprechende Firewall Regeln die die Ports für die gewissen IP Adressen freigeben.

Aber generell entspricht so ein Konstrukt überhaupt nicht mehr dem Sinn einer Firewall.

Vielleicht können wir dir eine bessere Lösung anbieten, wenn du uns schreibst, was genau du erreichen willst und wieso.

Gibt es hierfür keine Lösung und daher gibt es keine Antwort oder hat noch niemand die Anforderung für diese Konstellation gehabt? =)

Hallo zusammen.

Ich würde gerne, wie ich es von anderen Firewalls her kenne, einen Alias anlegen der sich entsprechend über DNS die aktuelle IP des Clients besorgt.

Bei einem Windows Host, sagen wir "NB10" als Host Name habe ich beim DHCP Server der OPNsense den Domänen Namen "bla.intern" mitgegeben und danach kann die OPNsense den Hostnamen "NB10.bla.intern" auch passend auf die passende DHCP Adresse vom NB10 auflösen. Dementsprechend sollte auch der Alias als "host" mit "NB10.bla.intern" funktionieren, wenn sie die DHCP Client IP einmal ändert.

Bei einem Smartphone jedoch, funktioniert die Auflösung vom DNS Namen nicht. Das Smartphone heißt z.b. "ironman" und bekommt vom gleichen DHCP Server auch die Domäne "bla.intern" mit. Allerdings kann man hier mit der OPNsense danach weder "Ironman" noch "Ironman.bla.intern" passend mit der IP auflösen. Die OPNsense findet einfach den Host nicht. Dadurch sind natürlich auch keine Aliase möglich.

Es wäre für mich auch ok, anhand der MAC die Firewall Regel zu setzen, wenn es anders nicht möglich ist, da die Regel nicht extrem "kritisch" ist.

Von anderen Firewalls kenne ich es auch, dass man in einer Regel mehrere Angaben für "from" "port" und "to" angeben kann. Das ist bei der OPNsense wohl ebenso nicht möglich, oder? Außer man legt tausende Aliase als Gruppen an.