Messages

1

Virtual private networks / Re: Wireguard client not reconnecting after WAN drop

« on: April 10, 2024, 12:49:17 pm »

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.

2

22.1 Legacy Series / Re: Traffic leaves WAN on wrong interface

« on: September 09, 2022, 02:04:37 pm »

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

3

22.1 Legacy Series / Traffic leaves WAN on wrong interface

« on: September 09, 2022, 11:23:54 am »

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]

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

4

German - Deutsch / IPSec: Traffic landet nicht im Tunnel

« on: September 06, 2022, 12:45:23 pm »

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

5

Virtual private networks / Issues with routed IPSec (VTI) on HA-Firewalls

« on: June 27, 2022, 10:49:41 am »

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]

querying policy 0.0.0.0/0 === 0.0.0.0/0 in failed, not foundThen 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]

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

6

German - Deutsch / Re: Probleme mit VPN-Tunneln

« on: March 23, 2022, 11:09:15 am »

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

Gruß
Ketanest

7

German - Deutsch / Re: WAN / PrivateVPN Trennung VLANs

« on: March 23, 2022, 11:02:37 am »

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

8

German - Deutsch / Re: Kein Internet über VLAN DHCP

« on: March 23, 2022, 10:55:47 am »

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 

Gruß
Ketanest

9

German - Deutsch / Best Practice OPNCentral und HA

« on: March 23, 2022, 10:44:03 am »

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

10

German - Deutsch / Re: Ständig neue WAN Verbindung

« on: January 07, 2022, 10:08:14 am »

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

11

German - Deutsch / Re: OpnVPN internes Routing [solved]

« on: January 07, 2022, 10:05:03 am »

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

12

German - Deutsch / Re: OpnVPN internes Routing

« on: January 06, 2022, 10:37:55 pm »

Ah, Augen auf und so XD

Ja funzt schon, trotzdem überflüssig…

13

German - Deutsch / Re: OpnVPN internes Routing

« on: January 06, 2022, 09:04:03 pm »

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...

14

German - Deutsch / Re: OSPF funktioniert nur bedingt auf OpenVPN Interface

« on: January 06, 2022, 04:26:46 pm »

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.

15

German - Deutsch / Re: OpnVPN internes Routing

« on: January 06, 2022, 04:21:27 pm »

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