Messages

[Verbleibendes Problem:]

Moin,
Verbleibendes Problem:

Ich möchte einen Service von außen erreichen (ähnlich wie VPN ins Heimnetzwerk). Da ich einen deutsche Glasfaser Anschluss habe, wurde mir mitgeteilt, dass ich einen Shared IP Anschluss habe und das es trotz dem kein Problem wäre in mein Netzwerk zu kommen. Anleitung von DG im Anhang wie man sowas hinbekommen sollte.

Fragen:

Ich habe meine externe IPv4 (obwohl ich eine IPv6 haben sollte). Wo kommen da die Anfragen an? Bzw. kann ich sehen ob diese überhaupt irgendwo geblockt wurden? Laut Anleitung sollte das nur mit IPv6 gehen...

Reicht es aus den Port im WAN freizuschalten und im Nat eine Portweiterleitung vom WAN ins DMZ Vlan zu erstellen?

Gruß Technix

Versuch macht klug. Ist das denn eine ordentliche öffentliche IPv4 Adresse, die du da zugewiesen bekommst?

Ist die OPNsense direkt am WAN oder ist da noch ein Router dazwischen? Wenn direkt, sollte es relativ einfach sein, mal einen Port auf dem WAN zu öffnen und von außen testweise darauf zuzugreifen. Wenn das geht, wird offenbar seitens Deutsche Glasfaser alles ordentlich durchgeroutet.

Und bitte folge nicht diesem Beispiel aus Deinem Anhang. Kein RDP direkt ins Internet. Das klingt nämlich für mich nach "ähnlich wie VPN ins Heimnetzwerk"

Hoffe trotzdem auf Rückmeldung, ob es nun funktioniert wie gewünscht  :)

Was hat denn der Proxmox host mit dem generellen routing zu tun?
Das ist ausschliesslich eine Einstellung der Firewall. Völlig falscher Ansatz.
Ich denke, es ist eher - ich schrieb es bereits - mit dem 1:1 NAT von der FW zu tun.

bfo

Warum sollte die OPNsense Pakete auf die IP des Proxmox Hosts "natten"? Die kennt diese IP doch gar nicht. Ich denke da ist was am Host falsch eingestellt.

Wie sehen denn deine Outbound NAT Regeln aus? Mach doch mal Screenshots von:
- Outbound NAT
- Interfaces->Overview mit aufgeklappten Interfaces
- Routing Table unter System->Routes-Status

Verbiegst Du in irgendeiner Firewall Regel das Gateway?

Wenn Du das 1:1 NAT im Verdacht hast: kannst Du es nicht einfach mal für ein paar Minuten deaktivieren?

A bug? No. Maybe it's not very intuitive.

All involved networks need to be defined in the main server to be added to the routing table. The client specific override only configures which client is getting which local networks and which remote networks are on the other side of the peer.

I'd do a separate instance for remote access and one for site2site.
Have this already in production and works really fine

Yes that's definitely the way I would recommend. Have it in production like that.

You still need to specify all local and remote networks in the main server. In client specific override you specify which client will use it.

Hast du bei Outbound NAT was eingestellt? Mich wundert der Name der Regel, die da beim ICMP angewandt wird.

Ich bleibe dabei, dass der Laptop die Ursache sein könnte. Beim Netzwerk drauf geachtet, dass Windows das neue Green Netz als privates Netz seiht und nicht als öffentliches? Das passiert gerne mal.
Dann lässt Windows keine Pings durch.
Im Log wird ja nix geblockt.

Die Regel sollte jeglichen Verkehr von Green erlauben. Bist du sicher, dass das Laptop pingbar ist? Windows spielt einem da gerne Streiche.

Sonst einfach unter Firewall in die Live View schauen und überprüfen, ob da ICMP Requests geblockt werden. Dürfte aber nicht. Denke es liegt am Laptop.

Did you try the official docs? I wrote examples there

Do you mean this one: https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html . Yes, sure. There are some points I did not understand. I cannot find the IP adresses 10.111.1.1 and 10.111.1.2 in the diagram and do not understand the purpose of these addresses in general. Furthermore if I configure it as described the box becomes unreachable (no ping, no ssh, no web) in the moment when the tunnel comes up (so I have to reboot without wan connection to undo the configuration).

Those IPs are just examples. They are needed as a sort of transfer-net. They are used as an interface to route traffic. Policy based IPsec tunnels don't use a transfer-net.
Do you use by coincidence IPs from that example somewhere else in your network? This would be an explanation for the box going ,,offline".

Wenn man sich mit dem Grundprinzip von Firewalls und in diesem Falle insbesondere mit OPNsense beschäftigt hätte, wüsstest du woran es liegt.

Üblicherweise erstellt man die Regeln auf dem Interface, wo die Pakete an der OPNsense eintreffen.

D.h. Wenn du von einem ins Netz A in ein Netz B möchtest, erstellst du eine Regel auf Interface A mit Destination Netz B mit entsprechenden Protokoll/Port oder eben any. Dann dürfen Pakete von Netz A nach Netz B und die Antwortpakete dürfen auch wieder zurück.

Schau Dir mal ,,disable reply-to" in den entsprechenden Firewall Regeln an.
Vielleicht liegt es daran.

Wifi hardware manufacturer?

Unifi for example has a feature called DHCP guard. If enabled only the specified DHCP server is allowed for this network. Or maybe you have port isolation enabled for that network?

Du denkst es m.E. von der falschen Seite.

1. Es gibt eine WAN Verbindung über die Fritzbox.

2. Deine OPNsense baut 2 WireGuard und 1 OpenVPN Verbindung über diese WAN Strecke auf.

3. Diese Client-Verbindungen kannst Du als Gateway für Clients hinter der sense nutzen.

4. Du steuerst selbst welche VLANs/oder auch einzelne IPs über welchen Gateway rausgehen. Das kannst Du sogar noch mit einem Kill-Switch garnieren, so dass es auch keinen Fallback gibt.

Hast Du denn die Netzwerke als Allowed-IPs in der Wireguard Config drin? Oder geht der gesamte Traffic durch den Tunnel?

Es gibt immer 2 Ebenen:
1: der Traffic muss richtig geroutet werden
und
2: wenn 1 gegeben ist, kann man mit Firewall-Regeln den Traffic einschränken/erlauben.