Messages

I have a similar issue:

I have 2 WAN connections (DSL and LTE). Wireguard peers are configured with 10 seconds keepalive. But if the DSL connection fails it doesn't reconnect. I have to restart the Wireguard services for the concerning connections manually.

Found the problem but have no solution:

We have a setup with opnSense business edition and do our firewall rules only on floating tab because our firewalls have different interface names and order so we can not make sure that the rules would be applied to the correct interface. Reply-To is the thing we'd need but that works only on rules on WAN interfaces (floating does not match this requirement). Since we manage our rules centralized we would overwrite the WAN interface rules if we'd configure some rules manually. So we have to proceed with this workaround (static routes to the endpoints).

EDIT: Not completely the problem. This is the problem for packets arriving on the firewall. Packets originating from the firewall should be correctly routed...

Regards
Ketanest

Hi altogether,

I have the follwing problem:
I have configured 2 WAN interfaces and gateways. One is an LTE connection (with an LTE-Router with fixed IP and /29 net) the other a cable connection with dynamic IP and extra router.
An IPSec tunnel is configured on the CARP address of the LTE interface.

Default gateway is on the cable connection. The problem is: any WAN traffic leaves the firewall on WAN_Cable interface via the default gateway 192.168.178.1 even though the IPSec tunnel is configured on WAN_LTE carp (it has neither worked with setting tunnel direct to WAN_LTE interface). Incoming connections e.g. on the webinterface via WAN_LTE interface are also answered via WAN_Cable interface. Firewall settings are default, especially "Disable force gateway" is disabled so usually the firewall should answer or send packets from the WAN_LTE interface via the WAN_LTE gateway but it does not.

Config:

Code Select Expand


OPNSense Version: 22.4.3_1

Interfaces:
WAN_LTE: 82.x.x.4/29
WAN_Cable: 192.168.178.10/24
CARP WAN_LTE: 82.x.x.3/29
CARP WAN_Cable: 192.168.178.12/24

Gateways:
WAN_LTE_GW: 82.x.x.1/29 on WAN_LTE interface prio 255
WAN_Cable_GW: 192.168.178.1/24 on WAN_Cable interface prio 250

Outbound NAT rules:
WAN_LTE and WAN_Cable interfaces (each rule for each interface):
This firewall / any source -> any / tcp/udp 80,443,123,53 -> translation to interface address
This firewall / any source -> any icmp -> translation to interface address
This firewall / source tcp 4444 -> any -> translation to interface address (webinterface is on port 4444)
any -> any -> translation to interface belonging CARP IP


The first NAT rules are to be able to do updates, DNS,  NTP and reach webinterface on each node in a HA setup.

With a static route to the IPSec endpoint via the LTE-Gateway the tunnel works fine but that should not be the solution.

Can you help me here?
Thank you!
Regards
Ketanest

Hallo zusammen,

ich hatte folgende Problematik und habe hierzu auch bereits die Problemlösung gefunden:

Ich habe einen IPSec-Tunnel gebaut zu einem Partner. Leider müssen in Phase 2 aufgrund der Vorgaben des Partners für lokales und entferntes Netz öffentliche Netze benutzt werden, auf unserer Seite wird geNATed. Ich hatte jetzt das Problem, dass Pakete von unserer Seite, die eigentlich im Tunnel landen sollten auf dem WAN Interface (Default-GW) landen.
Der Tunnel wird korrekt aufgebaut, auch die Phase 2. Pakete vom Gegenüber landen auch im Tunnel und danach via DNAT auf unseren Systemen. Diese wiederum antworten an die korrekte Adresse, die Pakete landen wieder auf der OPNSense. Dann jedoch schickt die OPN sie übers Default Gateway auf dem WAN Interface raus, statt in den IPSec Tunnel, was logischerweise dazu führt, dass sie auf der Gegenseite nicht ankommen.

Bei einem IPSec-Tunnel zu einem anderen Partner haben wir nahezu die selbe Konfiguration, nur dass das lokale Netz tatsächlich ein RFC1918-Netz ist, das auf unserer Seite existiert. Auch hier ist das entfernte Netz ein öffentliches. Hier funktioniert aber der Rückweg in den Tunnel.

Problemlösung war:
SPD in Phase 2. Wenn man hier NAT baut, muss man die betroffenen Zielsysteme in Phase 2 bei den SPD entries eintragen, damit diese berechtigt sind, den Tunnel zu nutzen. Die Routing-Entscheidung wird offensichtlich vor dem "Zurückbauen" des NAT getroffen.

Viele Grüße
Ketanest

Hi together,

I hope this forum is the correct one even if there is HA involved.
We've got the following problem: We set up some VMs to test OPNsense in our business environment. We set up IPSec tunnels between 3 of our locations. Routing is done by OSPF and routed ipsec (VTI). That works fine. No we got two more locations where we decided to implement OPNsense with HA. That are two physical servers per site, configured in HA-mode. We have an /29 subnet for WAN at each site so each node has an own public IP and we configured CARP to share a VIP. The configuration between HA clusters and the VMs is completely the same but we have a problem with the site-to-site tunnels to the HA clusters. The tunnels regularly break and do not come up again or come up hours later. When the tunnels are down the log is full of entries:

Code Select Expand

querying policy 0.0.0.0/0 === 0.0.0.0/0 in failed, not found
Then we have to restart the tunnel on one of the sites (HA or VM). Service restart is usually not necessary.

Config of the tunnels (is on each node the same):

Code Select Expand


P1:
Connection method: start on traffic
Key Exchange: IKEv2
Internet Protocol: IPv4
Interface: WAN Interface or VIP
Remote Gateway: Public IP of WAN Interface or VIP
Auth method: Mutual PSK
Identifiers: Public IPs
PSK: PSK
Encryption algorithm: AES256
Hash: SHA512
DH key group: 14
Lifetime 28800

Install policy: no
Disable rekey: no
Disable reauth: no
Tunnel Isolation: no
SHA256 96 bit trunc: no
NAT Traversal: Enable
Disable MOBIKE: no
Close Action: none
DPD: on, 10 seconds, 5 retries, action: restart
Inactivity timeout: -
Keyingtries: -
Margintime: -
Rekeyfuzz: -

P2:
Mode: route based
Local address: unique IP in an /30 net
Remote Address: other unique IP in the same /30 net
Protocol: ESP
Encryption algorithm: AES256
Hash: SHA512
PFS key group: 14
Lifetime: 3600
Automatically ping host: -

EDIT: What I also recognized is that sometimes an entry with connection name "((unnamed))" appears (attachment). The local IP and remote IP are the same as in the real connection.

Has anyone an idea what the problem could be here?

Thank you!
Ketanest

Was mir spontan einfällt: Static Port bei NAT (Falls vorhanden)?

Gruß
Ketanest

Wie pmhausen schon gesagt hat: Policy Based Routing.
Bei ganzen Netzen einfach bei der betreffenden Regel ziemlich weit unten das Gateway (hide.me) auswählen.
Wenn du nur einzelne Clients aus einem Netz über VPN schicken willst, musst du eine zusätzliche Regel bauen mit dem hide.me Gateway, die muss dann auch VOR der "allgemeinen" Internet-Regel stehen, sonst greift die allgemeine und damit landet der Traffic bei der Telekom.
Bei den Gateways sollte die Prio des primären Gateways (ich nehme an Telekom) niedriger sein, damit das eben primär benutzt wird.

Gruß
Ketanest

DNS geprüft? Verteilst du per DHCP auch einen DNS-Server? Wenn ja: ist der erreichbar? Standardmäßig ist unbound aktiv, es braucht aber auch dafür auf der OPN eine eingehende Regel.

EDIT: Und was mir gerade aufgefallen ist: Source LAN-net? Das müsste doch wenn dann das WLAN-net sein ;-)

EDIT2: Wenn du eine Any-Regel anlegst, kannst du dir das zusätzliche Netz übrigens auch gleich sparen  :P

Gruß
Ketanest

Hallo zusammen,

da ich leider nichts brauchbares gefunden habe (oder zu doof bin zu suchen), richte ich mich an euch.
Geht konkret um die Business-Edition.
Wenn ich einerseits über OPNCentral meine Einstellungen auf die Firewalls per API verteile und auf der anderen Seite bei jeder Firewall ein HA-Cluster fahren möchte, gibt es dann irgendwas spezielles zu beachten?
Könnte es zu einem Konflikt kommen, wenn ich die Einstellungen sowohl per OPNCentral verteile als auch dann per pfsync noch auf den 2. HA-Cluster-Knoten schiebe?
Sollte ich am besten jede Firewall einzeln per OPNCentral mit der Config versorgen oder jeweils nur den Master-Knoten und dann auf den Slave per pfsync replizieren lassen?

Danke schonmal für eure Antworten!

Viele Grüße
Ketanest

So, Problem konnte behoben werden. Manchmal hilft ein einfacher Neustart und alles funktioniert wieder. Warum auch immer.

Ganz einfach: Weil Reboot tut gut ;) Ist doch oft so

Wenn Du nach dem Komma ein Leerzeichen hast, funktioniert es nicht. Ist bekannt.

Jupp so ist es. Konnte man sich das nicht aussuchen entweder Leerzeichen ODER Komma aber nicht beides? Oder war das bei der pf? Oder lieg ich ganz daneben?
Weiß man, ob es dafür schon einen RFC gibt?

Gruß
Ketanest

Ah, Augen auf und so XD

Ja funzt schon, trotzdem überflüssig...

Hab bei mir mal durchgeschaut: Ich kann meine automatisch generierten Gateways gar nicht deaktivieren... Auch interessant...

EDIT: Bei mir sind die Regeln mit "Reply-To: default" angelegt, funzt aber alles...

EDIT: Das mit den Route Maps sowie Prefix Lists sowie deren Zusammenhang hab ich leider nicht wirklich verstanden. Dazu hab ich leider zu wenig Erfahrung mit OSPF. Hat da eine vielleicht nen verständlichen Erklärungsansatz für?

Gruß
Ketanest

Das ist damit natürlich obsolet geworden, so halbwegs hab ichs jetzt verstanden.

Wenn ich im LiveView der Firewall schaue zeigt er mich auch, dass das Paket weitergeleitet wird, nur danach scheint es zu verschwinden, hab auch schon versucht regeln für den Rückweg einzutragen in der FW aber ich bekomme auch in der FW keine Meldung das etwas geblockt wird.

Rückroute brauchst du nicht, das regeln die States.

Sehe ich das richtig, du möchtest aus dem VPN ein Gerät im 192.168.178.0/24er Netz erreichen? Kennt dieses Gerät das VPN-Netz? Bzw. ist das Standardgateway die OPN?

EDIT: Die Live-View zeigt nur dein LAN Interface, was sagt denn die Live-View aufm VPN-Int?
EDIT2: Vergiss es, wenns aufm LAN rausgeht, isses inbound ja schon durchs VPN-Interface und damit durch diese Regel durch. Denkfehler.

Wie gesagt, ich vermute ein Routing Problem. Was macht denn ein Trace?

Gruß
Ketanest