Messages

Nun habe ich das Problem, dass bei neueren Geräten die Weiterleitung auf den entsprechenden Port blockiert wird.

Welche Weiterleitung?
Du hast doch geschrieben, dass die Seite per QR-Code-Scan geöffnet wird. Wo wird dann weitergeleitet?

Vielleicht mögen die Geräte den verdeckten speziellen Port nicht?
Ich verstehe aber auch nicht, wie der verschleiert sein soll, wenn er im QR-Code steckt. Ist die Funktionsbeschreibung wirklich vollständig?

Um den Port speziellen Port loszuwerden, könntest du jedenfalls einen Reverse-Proxy in Betracht ziehen.

Nun möchte ich aber auf dem WAN den DNS abschalten - klar könnte man das auch per Regel blocken, das ist nur ein Workaround. Macht man bei den Regeln einen Fehler, ist wieder alles offen.

Ich denke, da hast die eine falsche Sichtweise. Natürlich sind Regeln hier das geeignet Mittel, um Zugriffe zu beschränken.

Die Interfaces, die man in Unbound auswählt, sind lediglich jene, auf welche Unbound lauscht. Ihn auf die Interface IP lauschen zu lassen ist komfortabel in Verbindung mit einem DHCP Server, weil dieser die Interface IP automatisch auch gleich an die Clients als DNS verteilt. Als Zugriffsbeschränkung ist das aber gar nicht geeignet.
Clients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Das gilt natürlich auch für alle anderen Services, die auf OPNsense laufen.
Firewall-Regeln sind also in jedem Fall das Werkzeug der Wahl, um unerwünschte Zugriffe zu unterbinden.

>>Möchte meinen VPN-lern die internen Servernamen mitgeben, die den Rest der Welt nichts angehen!

In der OpenVPN Server-Konfiguration musst du ohnehin einen DNS-Server eintragen. Das kann dann auch die LAN-IP oder sonst eine sein, auf der Unbound lauscht. Wenn die Clients nur die Hostnamen, nicht den gesamten FQDN, auflösen können sollen, musst du die lokale Domäne auch als Suchdomänen pushen.
Erlaube den Zugriff ggf. noch mit einer Regel, dann sollten die Clients Namen auflösen können.

is there a way of forcing my outbound VPN connection to use a specific gateway rather than the default one?

I've tried a firewall rule (LAN and floating) to force destination traffic for the vpn endpoint to a specific gateway

On LAN?
If you're talking about a VPN client running on a LAN device, yes, this would be the proper way and should work.

But if want to force a connection from a client running on OPNsense itself to a certain gateway, you can only do this with a policy-routing rule for outbound traffic on the WAN.

To get sure, for this to work, it's required that gateway monitoring is enabled and that the LTE is detected as online. Otherwise OPNsense sends the traffic to the default gateway instead.

So go to System: Gateways: Configuration and check if monitoring is enabled for the LTE (if it is, a monitoring IP is displayed) and if it's status is online.
If it isn't you have to configure the gateway monitoring properly.

Remember that a connection sticks on the rule till the state times out or is deleted.
So consider to flush the state table after making chances in the rule set.

I have tried to create a Firewall Rule with a specific internal host IP on LAN interface and mapping it to the LTE Gateway but everything still routes over the DSL Gateway.

Ensure that the rule is applied to the respective traffic.
State a unique description, enable logging and check the firewall log after trying a connection.

Note that interface group rules and floating rule have precedence over interface rules.

Hat jemand ein ähnliches Problem bzw. eine Lösung?

Die Forumssuche hätte diese Frage vielleicht beantworten können:
https://forum.opnsense.org/index.php?topic=51861.msg266881#msg266881

Nach einem Neustart habe ich in Wireshark noch das gleiche Aussehen

Wo wurde das Capture gemacht?
Ich vermute am Client?

Läuft diese Verbindung überhaupt über OPNsense?
Wenn ja, welche Netze sind das?
Wenn nein, hat eine Änderung der WAN Konfiguration wohl nicht viel Einfluss darauf, zumal ja das Ziel offenbar gar nicht im WAN liegt.

Kann ich irgendwie sehen, ob das mit MTU zusammenhängt oder ob MTU jetzt korrekt ist?

Du kannst MSS ja auf einen Wert runter setzen, der in jedem Fall kein Problem bereitet, wie 1200, aber auf einem Interface, das in die Verbindung involviert ist.
Ich denke aber nicht, dass es damit zu tun hat.

Vielmehr würde ich ein Layer 1 Problem vermuten wie Kabel, Netzwerkschnittstelle, Treiber.

OPNsense has an implemented TOTP server out of the box.

Configure 2FA TOTP & Google Authenticator

Of course it does not work that way, because the Pi itself needs to be excluded from the hairpin rule.

I think, the pi must rather be excluded from redirecting to itself. And that's already done according to the initial post.
Then the hairpin rule has not any impact on requests from the pi itself at all.

Assuming the pi-hole resides within your LAN, you also need a source NAT rule to hairpin DNS requests from other LAN devices going to the pi-hole:

Interface: LAN
protocol: TCP/UDP
source: LAN network
destination: pi IP
dest. port: 53
translation: LAN address

Stimme zu, dass die GUI hier wiedermal für Verwirrung sorgt.
MSS sollten eigentlich die Nutzdaten sein. Und die sind nun mal für TCP IPv4 MTU - 40.

Nachdem das Feld "MSS" benannt ist, würde ich ebenfalls annehmen, dass ich da die tatsächlich Nutzdatengröße angeben müsste.
Frag mich wiedermal, was die Entwickler sich wohl hierbei gedacht haben.

Ich habe aber bei mir in keinem der Felder etwas eingetragen, nachdem ich irgendwann mal gelesen hatte, dass OPNsense die Werte automatisch setzt. Und soweit ich das überprüfen kann, passt das auch.

Your outbound NAT rules are not clear to me. Why did you use single from addresses:

nat on igb1 inet from ! <opn2_igb1_plus_lo_addr> ...
nat on igb1 inet from <opn2_igb1_plus_lo_addr> ...

And I don't see a rule for 127.0.0.0/28 at all.

Maybe a screenshot can show it better.

Are the rule on master and backup even the same?
Note, that you have to add the rule on the master if they are synced to the backup. Otherwise the backup rules get overwritten by the sync.

tcpdump does not show any packets on the WAN interface so I do not know the sender address.

Any source address in packets stemming from 127.0.0.0/8 is translated to the CARP VIP on the WAN due to your rule. So it's obvious the you cannot see any IP of this subnet.^^

You nat any traffic on WAN to the CARP VIP apart from the interface address. But the CARP VIP is naturally occupied by the master node, and the backup cannot use it.

Traffic from OPNsense itself might rather come from 127.0.0.0/8, however. So you have to nat this subnet to the WAN interface address.