Messages

Eine "Allow Ping" Regel hatte ich aber schon gesetzt:
pass, WAN, in, IPv4+6, ICMP, WAN Adresse, Rest

"WAN Adresse" ist da hoffentlich nicht als Quelle gesetzt?

Wenn ich eine floating Regel in/out, pass, IPv4+6, beliebig zum Testen aktiviere, dann funktionieren alle PING (8.8.8.8 - SUBDOMAIN.dedyn.io oder any_string.SUBDOMAIN.dedyn.io

Könnte bedeuten, dass die andere WAN Regel nicht zutrifft.

In FW-Live sehe ich 192.168.178.5 (OPNsense im FritzBox Netzwerk) und 192.168.178.255 mehrfach blockiert:

WAN

2025-10-03T23:37:25

192.168.178.59:59624

192.168.178.255:58866

udp

Default deny / state violation rule

	WAN		2025-10-03T23:37:25	199.21.149.124:41941	192.168.178.5:60558	tcp	Default deny / state violation rule
	WAN		2025-10-03T23:37:25	104.255.154.159:41911	192.168.178.5:50877	tcp	Default deny / state violation rule

192.168.178.5 sehe ich da nur als Ziel mit irgendwelchen Ports, du du wohl nicht erlaubt hast.
192.168.178.255 ist die Broadcast Adresse. Pakete an diese empfängt jedes Gerät im Subnetz.

Okay, dann ist es vermutlich in den System > Gateway Einstellungen zu finden. Dann kann es da einfach gelöscht werden.

Da steht die FB IP bei WAN und bei LAN.
Nachdem du LAN statisch konfiguriert hast, musst du auch die Gateway IP manuell gestetzt haben.

In Interfaces: LAN
Bei dir wahrscheinlich Schnittstellen: LAN

Hast du da ein Gateway eingetragen??

Sieht aus, als ob du in den LAN Interface Einstellungen die FritzBox als Gateway angegeben hättest.
Am LAN ist kein Gateway zu setzen!

Curl from windows will fail to respond. In the firewall logs all I can see is a pass going 100.53 -> 110.2

No need to obscure private IP addresses at all. Nobody outside of your network will be able to access it.
Clear text makes troubleshooting easier.

Please post your NAT port forwarding rule and and the firewall rules on VLAN 100.

Run a packets capture on VLAN 100 and on VLAN 110, while you curl your website. Best to run both simultaneously.
Post the capture then.

Also check if Caddy logs anything regarding this.

It would also be helpful to enable the logging of default blocks and in all rules on both involved interfaces and post the firewall logs.

OPNsense hängt mit Sicherheit über WAN (igc0) an der FritzBox und am LAN (igc1) hängt der ASUS Router, an dem alle Clients hängen. So sind auch die LAN-Kabel eingesteckt. Das habe ich gerade nochmals überprüft.

Viele Router für den Anfang.
Aber gut, wenn die OPNsense als Exposed Host an der FB hängt, sollte sie von außen erreichbar sein, sofern das überhaupt was reinkommt.
Hast du schon irgendwann mal erfolgreich Zugriff aus dem Internet auf dein Netzwerk gehabt?

Die Routing Tabelle ist über System: Routes: Status abrufbar.
Bitte auch die Gateway Konfiguration dazu: System: Gateways: Configuration

Mich stört das "let out anything from firewall host itself" im Regel-Log am LAN:

LAN      2025-10-03T17:20:19   192.168.50.4:57262   192.168.178.1:80   tcp   let out anything from firewall host itself

Was ist da die Quell-IP?
Wenn du die involvierten IPs erklären würdest, würde eine Analyse leichter fallen.

Ziel ist auf jeden Fall die FritzBox, und ein Paket zu dieser sollte nicht am LAN raus gehen, wenn sie am WAN angeschlossen ist.

You messed up the rule settings.

On the VPN interface there is no rule needed at all. You should delete it.

On the VLAN interface to some changes:
source: NordVPNUKVLAN net
destination: any
gateway: NORDVPNUK_VPNV4

In der FritzBox ist "Exposed Host" eingestellt, aber fritz.box oder 192.168.178.1 erreiche ich ebenfalls nichtmehr, obwohl das FW-Log auch hier grün ist:

• LAN

  2025-10-03T17:20:19

  192.168.50.4:57262

  192.168.178.1:80

  tcp

  let out anything from firewall host itself

• LAN

  2025-10-03T17:20:12

  192.168.50.1:58177

  192.168.178.1:53

  udp

  let out anything from firewall host itself

• WAN

  2025-10-03T17:20:20

  192.168.178.5:2140

  34.999.8.122:443

  tcp

  let out anything from firewall host itself (force gw)

• WAN

  2025-10-03T17:20:20

  192.168.178.5:65485

  52.19.999.51:443

  tcp

  let out anything from firewall host itself (force gw)

Das sollte schon funktionieren.

Allerdings gehen die Pakete bei dir offenbar LAN Interface ruas, wie die ersten beiden Regeln zeigen. Die FritzBox hängt doch am WAN?
Ich frag mich auch, wo sie reinkommen.
Vielleicht solltest du mal deine Routingtabelle offenbaren.

Ping-Test über wieistmeineip.de ist grün

Bei mir auch, allerdings habe ich keine ICMP von außen erlaubt und das Firewall Log zeigt die Pings auch als geblockt. Die OPNsense hat selbt die öffentliche IP am WAN.
Da frag ich mich, wie die zu dem erfreulichen Ergebnis kommen.[/list]

Deine OPNsense sitzt demnach ja hinter einem anderen Router. Ist da alles weitergeleitet, was du testest, also hier mal ICMP und TCP 80 u. 443?

Wenn ja, geh mal auf Interfaces: Diagnostics: Packet Capture, selektiere WAN Interface und ICMP Protokoll, ggf. setze noch deine Quell-IP bei Host und starte das Capture.
Dann starte einen Ping und schau anschließend, ob da Pakete zu sehen sind.

Ich nehme an, du pingst aus dem Internet.

Wenn da nichts ist, hat es was mit der Weiterleitung, oder du bekommst schon von deinem ISP nichts weitergeleitet.

Vorgehen analog Tutorial mit Adaption an aktuelle Felder und Einstellungen:
https://forum.opnsense.org/index.php?topic=23339.0

Das hatte ich mir auch durchgesehen, hatte es aber nicht so gelöst.
Einen Sinn des TCP frontends konnte ich für mich nicht erkennen.
Ich habe eines, das auf Port 80 lauscht und jegliche Anfragen auf https redirektet, und mehrer auf Port 443.

Mir fällt dazu in deiner HAproxy Konfig auf, dass da beim Frontend: 1_HTTPS_frontend zwar "(Listening on 127.4.4.3:443)" in der Bezeichnung seht, die Bind Adresse aber tatsächlich 192.168.50.1 ist.
Aber wie gesagt, mit diesem Konfigurationsvorschlag habe ich mich nicht auseinandergesetzt.

aber nur SUBDOMAIN.dydyn.io (ohne any_string) ist nicht propagated. Ich nehme an, dass das korrekt ist, oder nicht?

Ist wohl auch keine CNAME, oder?

https://www.ssllabs.com/ssltest/analyze.html scheitert, während
https://crt.sh/ die crt.sh.IDs mit korrektem Erstell- und Verfallsdaten zeigt.
=> mit Klick auf crt.sh.ID Link, sehe ich Details, wie Serial Number, Public Key, DNS usw. sowie:
OCSP check => mit Klick: No OCSP URL available
CRL, CRLSet, disallowedcert, OneCRL - all "Not Revoked".

Das heißt, die Analyze bricht komplett ab?
Dann würde ich vermuten, dass der Host keine Zertifikat liefert. Zeigt SSLLabs eines an?

OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAIN.dedyn.io (mit oder ohne any_string) weiterhin 100% Verlust, sendto: Host is down
Liegt das an der HAProxy Konfiguration oder müsste es zuvor noch einen Fehler geben, da bei 9.) der Ping-Test auflösen müsste?

Ping müsstest du am WAN mit einer FW-Regel erlauben.
HAproxy lauscht auf einen oder mehrer Ports. Ping (ICMP) kennt keine Ports. Pings landen demnach nicht auf HAproxy.

OK, what I am missing is the part of how to set up the VLAN so that all traffic from it routes via the VPN.

All necessary steps are explained above.

If you have trouble anyway, show all details of your settings, please.

You can keep any as source, but you can also limit it to a subnet or what ever you want.

The translation target is the interface address = VPN client address.
It's the same as with WAN. Source IP in all outgoing traffic is translated to the interface address.

I see in the interfaces overview that the new interface has IPv4 and routes set to 10.100.0.2/16. Is this the range of addresses that will be handed out to clients connecting to the VLAN?

This is your VPN client IP.
It's not range, but just a single IP and you cannot hand it out to any other device.

If you route traffic to the VPN server, the suggested outbound NAT rule translates the source address into this one, so that responses are coming back to you.

There is nothing to configure in the VPN interface settings. Just enable it.
IP address assignment is done by the VPN server.

I don't know a useful tutorial for this, but ther are just a view settings necessary.
I assume, you're talking about IPv4 routing here.

• Assign an interface to the OpenVPN client instance.
  Interfaces: Assignments > Assign a new interface
  at device select the client instance, state a description, open the new interface and enable it.
  
• Add an outbound NAT rule:
  Firewall: NAT: Outbound
  Enable the hybrid mode. And add a rule to the OVPN client Interface, which you created before.
  
• Create an RFC 1918 alias and add all private network ranges to it.
  You don't want to route these over the VPN.
  
• Add a policy-routing rule to the respective VLAN interface.
  At destination check "invert" and state the RFC 1918 alias.
  At Gateway select the VPN Client gateway.
  Move this rule up to the top of the rule set.
  
  So this rule is only applied to non-private destinations and directs the traffic to the VPN server.