Messages

TCP Pakete haben Folgenummern und die Firewall überprüft diese normalerweise auf Plausibilität. Das wird damit ausgesetzt.
Damit wäre es möglich, dass eine Bösewicht ein gefaktes Paket einschleust.

Wenn du die Sloppy State Regel aber auf die Quell-IP des WatchyourLan Containers beschränkt und auf Quell-Port 22 (SSH) sehe ich damit kein nennenswertes Risiko.

Hab es per "Sloppy State" Regel umgesetzt, und per Source/Destination IP und Destination Port beschränkt, somit sollte die Angriffsfläche sehr verkleinert werden.
Action: Pass
Interface: User
Direction: In
TCP/IP Version: IPv4
Protocol: TCP/UDP
Source: 10.20.10.2/32
Destination: 10.20.20.16/32
Destination Port: 22 (und 8840 für watchyourlan)
advanced: checked
State Type: sloppy state

als auch im LXC container per ufw den Zugriff definiert/beschränkt.

Danke nochmals.

Eine Möglichkeit wäre, das Gerät nur auf demselben Subnetz anzusprechen.

Dies war mein Workaround bisher.

Ansonsten mit all den IPs in jedem Subnetz, ist die saubere Möglichkeit, asymmetrisches Routing zu vermeiden, eine Outbound NAT Regel dafür anzulegen und die Quell-IP durch die Interface IP der Firewall zu ersetzen. Die Filterung kannst du ja dann auf der OPNsense machen.

Muss mich hierzu mal weiter einlesen.

Die unschöne Lösung ist, auf allen betroffenen Interfaces eine "Sloppy State" Regel zu erstellen (Floating od. Interface Gruppe), die die Antwortpakete durchlässt, ohne deren Zustand zu prüfen.
Das findest du in der Firewall Regel in den Advanced features > State Type > sloppy state.

Was wäre hier der Nachteil? Hat es Sicherheitsnachteile?
Also die Umsetzung funktioniert, erhalte somit keinen block von OPNSense und die Verbindung bleibt bestehen.

Danke für die Hilfe hierher

Asymmetric routing is the problem, also your solution is working, making a FW rule which allows the connection with "sloppy state" under advanced settings.

Is there any disadvantage for security using this rule?

Somit habe ich aber das Problem, dass quasi die Gateway IP bei der VM aufscheint und ich nicht die ufw Regeln so einfach setzen kann.
Lösung wäre das Management der VM über das Interface laufen zulassen in welchem mein PC läuft?
Sprich SSH über 10.20.10.70 und per ufw Regel 10.20.10.2 drauf zugreifen lassen, statt über 10.20.20.16.

Maybe someone here has some input.

I'm trying to implement the following but I've run into a problem that I can't exactly explain to myself. I want to install a WatchyourLan container that listens on all my VLAN/LANs, but only grant access from specific devices. So I installed ufw and take over routing from docker itself, next disabling iptables for docker. This has worked so far, until I add the interface from which subnet I manage the VM via SSH.

So I reset the VM and only added the interfaces and look and behold I found the problem, the OPNSense blocks the SSH traffic after a certain time.
[Picture-1]

Overview:
VM - 10.20.20.16/24 - VLAN ID 20 Homelab
[Picture-2]
PC - 10.20.10.2/24 - VLAN ID 10 User

VM as well as OPNSense runs on Proxmox as VM
As soon as I am in the same subnet with the PC, no problem, clearly it is not routed either
Creating a firewall rule that allows the traffic, the connection is blocked by OPNSense after 30 seconds
MAC addresses checked if anywhere identical, no only those of the VLAN with the parent interface
[Picture-3]

Furthermore, the fixed IPs of those VLAN/LANs stored for the VM are not visible in the ARP table under OPNSense or are short and disappear again.

Proxmox hardware
[Picture-4]

Why I haven't encountered the problem yet, because I don't have a VM with the same interface as my management PC.
Thx for the input.

Vielleicht hat hier jemand noch einen Input.
Ich versuche folgendes umzusetzen bin aber auf ein Problem gestoßen, was ich mir selbst nicht genau erklären kann. Will einen WatchyourLan Container installieren der auf all meinen VLAN/LANs lauscht, jedoch nur von spezifischen Geräten Zugiff darauf gewähren. Also ufw installieren und routing vom docker selbst übernehmen, somit iptables für docker ausschalten. Dies hat soweit funktioniert, bis ich das Interface hinzufüge, von welchem Subnet aus ich die VM manage per SSH.

Somit VM zurückgesetzt und nur die Interfaces mal hinzugefügt und siehe da Problem gefunden, die OPNSense blockiert nach einer gewissen Zeit den SSH Traffic.
[Bild1]

Überblick.:
VM - 10.20.20.16/24 - VLAN ID 20 Homelab
[Bild2]
PC - 10.20.10.2/24 - VLAN ID 10 User

VM als auch OPNSense läuft auf Proxmox als VM
Sobald ich mit dem PC im gleichen Subnetz befinde kein Problem, klar wird auch nicht geroutet
Erstellen einer Firewallregel die den Traffic erlaubt, wird die Verbindung nach 30 sec geblockt von OPNSense
MAC Adressen gecheckt ob irgendwo ident, nein nur die des VLANs mit dem parent Interface

[Bild3]
Des Weiteren sind im ARP Table unter OPNSense die für die VM hinterlgeten fixen IPs jener VLAN/LANs nicht ersichtlich bzw. kurz und verschwinden wieder.

Proxmox Hardware
[Bild4]
Warum ich bis jetzt noch nicht auf das Problem gestoßen bin, weil ich keine VM habe welche ein gleiches Interface hat in welchem sich mein Management-PC befindet.

It could be my solution
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
The specific non local traffic gets routet through tunnel and translated to the WAN of site B. I tried at ping to 1.1.1.1, the live log shows the Nat Rules is working, but I think its not possible to get a reply from 1.1.1.1 because of the outbound nat? now the request ist not 10.20.10.90 but the public WAN IP?
Do I need to translate it back to the WG Tunnel?

I would like to route the data traffic as shown in the network diagram. Device X (debian_test_vm) should use the red path through the WG tunnel to the WAN of site B.
Here I will upload necessary pictures https://imgur.com/a/lqIS3ur.
I have set up all the necessary rules, but the WAN at site B is not working, as I found out when troubleshooting, I think.

What is working so far is the tunnel itself. I can ping device Y from device X as I can see in the live log view.

Another thing I see, but I am not sure if it is a miss understanding, shouldn't there be the Gateway of WG Tunnel Gateway 10.250.0.2?

Code Select Expand

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1  10.20.10.1 (10.20.10.1)  0.746 ms  0.703 ms  0.678 ms
2  10.20.10.1 (10.20.10.1)  0.626 ms !H  0.620 ms !H  0.572 ms !H

traceroute to site B device

Code Select Expand

traceroute to 10.42.0.10 (10.42.0.10), 30 hops max, 60 byte packets
1  10.20.10.1 (10.20.10.1)  0.589 ms  0.559 ms  0.535 ms
2  10.250.0.2 (10.250.0.2)  10.999 ms  10.972 ms  10.946 ms
3  10.42.0.10 (10.42.0.10)  10.924 ms  10.871 ms  10.816 ms

Also packet capture does not show any traffic on the WG Tunnel incoming to not local ip addresses, like ping 1.1.1.1 is not showing up.

Code Select Expand

Interface Timestamp SRC DST output
***VPN
wg0 2024-09-08
23:05:14.429997 length 88: 10.20.10.90 > 10.42.0.10: ICMP echo request, id 9067, seq 1, length 64
***VPN
wg0 2024-09-08
23:05:14.430216 length 88: 10.42.0.10 > 10.20.10.90: ICMP echo reply, id 9067, seq 1, length 64
***VPN
wg0 2024-09-08
23:05:15.431483 length 88: 10.20.10.90 > 10.42.0.10: ICMP echo request, id 9067, seq 2, length 64
***VPN
wg0 2024-09-08
23:05:15.431676 length 88: 10.42.0.10 > 10.20.10.90: ICMP echo reply, id 9067, seq 2, length 64

Other troubleshooting tipps?