Messages

Hello there, I´m kinda new to the OPNSense and general firewall topic. Im currently having issues with allowing Steam to authenticate my user.

I have two interfaces:

WAN (192.168.2.236)
LAN (192.168.0.1)

On the LAN I have configured the following rules as stated in the Steam firewall configuration guide (https://help.steampowered.com/en/faqs/view/2EA8-4D75-DA21-31EB)

If I now open Steam I run into an timeout. The connection log from Steam says the following in the .txt file.

I can´t see any blocking on the LAN side, so I think I setup everything correctly there. Even any LAN-Any-Allow rule won´t do it.

On the WAN site I can see alot of blockings from the default deny / state violation. I assume that Steam is sending their authentication over an CDN. This has a different IP and port, so the firewall thinks its a random packet and denys it.

How can I fix this problem?

Hello there,

I just got OPNsense up and running. In my current configuration, I have two interfaces:

LAN (192.168.0.1/24)
WAN (192.168.2.236/24)

In my LAN network, I have a client connected through a Wi-Fi access point. The client receives its network configuration via Dnsmasq DHCP. DNS is configured manually on the client's network adapter.

I created an outbound NAT rule to allow the LAN network to communicate with the internet. I attached the NAT rule below.

However, the firewall handles the traffic as if it originates from the firewall host itself and allows the traffic through the let out anything from firewall host itself rule, effectively bypassing the default deny behavior. I attached my current firewall rules as well.

I also disabled all LAN interface rules, but the traffic still passes through directly.

Additionally, I attached a log screenshot where you can see the traffic being forwarded to the WAN gateway by the let out anything from firewall host itself rule.

I do not want this behavior. Every allowed connection should be explicitly defined by my own firewall rules. No traffic should be able to leave the LAN unless I manually permit it in the rules tab.

What am I doing wrong?

Hello everyone,

I currently have a "server" with the following specifications:

- i7-6700
- 32GB RAM

HyperV runs on the server as a hypervisor with an OPNsense (24.7.12_4) and a Linux VM.

The firewall has the following interfaces:

- WAN (192.168.2.0/24) = actual home network
- LAN (192.168.100.0/24) = network where the Linux VM is located => behind the firewall
- MGMT (10.10.20.0/24) = management network, e.g., to access the GUI from the hypervisor
- OpenVPN (10.99.99.0/28) = tunnel network for OpenVPN

The VPN works fine as long as there are no demanding tasks such as RDP. However, as soon as I want to access the Linux VM via RDP, it starts to lag, i.e., the latency is very high. It is almost impossible to use the VM via RDP. So I checked the quality of the connection and found the graph in the attachment.

I have already checked/adjusted the following steps

- Set up and compared WireGuard
- Tested different MTUs
- Activated MSS fix
- Tested TCP/UDP
- Keep alive interval = 10
- Keep alive timeout = 60
- Checked VM resources => None come close to 50%
- Checked Firewall LiveLog
- Reduced RDP connection itself to 15 bits


A ping to the VM yields the following:

Code Select Expand

Ping is executed for 192.168.100.42 with 1400 bytes of data:
Reply from 192.168.100.42: Bytes=1400 Time=5ms TTL=63
Reply from 192.168.100.42: Bytes=1400 Time=10ms TTL=63
Reply from 192.168.100.42: Bytes=1400 Time=6ms TTL=63
Reply from 192.168.100.42: Bytes=1400 Time=4ms TTL=63

Ping statistics for 192.168.100.42:
    Packets: Sent = 4, Received = 4, Lost = 0
    (0% loss),
Approximate time in milliseconds:
    Minimum = 4ms, Maximum = 10ms, Average = 6ms


Excerpt from the OpenVPN client log:

Code Select Expand

⏎[Oct 26, 2025, 11:11:02] Connected via TUN_WIN
⏎[Oct 26, 2025, 11:11:02] EVENT: CONNECTED vpn.***@192.168.2.230:1194 (192.168.2.230) via /UDP on TUN_WIN/10.99.99.2/ gw=[10.99.99.1/] mtu=1500⏎

I am grateful for any response, because I am slowly running out of ideas as to what the problem could be or what I can do.

Hallo zusammen,

aktuell habe ich einen "Server" mit folgenden Specs:

- i7-6700
- 32GB RAM

Auf dem Server läuft HyperV als Hypervisor mit einer OPNsense (24.7.12_4) und einer Linux VM.

Die Firewall hat folgende Interfaces:

- WAN (192.168.2.0/24) = eigentliches Heimnetz
- LAN (192.168.100.0/24) = Netz indem sich die Linux VM befindet => hinter der Firewall
- MGMT (10.10.20.0/24) = Management Netz um z.B. vom Hypervisor auf die GUI zu kommen
- OpenVPN (10.99.99.0/28) = Tunnelnetz für OpenVPN

Der VPN funktioniert, solange es keine anspruchsvollen Aufgaben wie z.B. RDP sind einwandfrei. Sobald ich allerdings via RDP auf die Linux VM möchte fangt es an zu Laggen, sprich die Latenz ist sehr hoch. Es ist fast nicht möglich die VM über RDP zu nutzen. Ich prüfte also die Qualität der Connection und fand den Graph im Anhang.

Folgende Schritte habe ich bereits geprüft / eingestellt

- WireGuard eingerichtet und verglichen
- Verschiedene MTUs getestet
- MSS fix aktiviert
- TCP/UDP getestet
- Keep alive interval = 10
- Keep alive timeout = 60
- Ressourcen der VMs geprüft => Keine kommt annähernd an 50%
- Firewall LiveLog geprüft
- RDP Verbindung selbst auf 15 Bit runtergeschraubt


Ein Ping auf die VM ergibt folgendes:

Code Select Expand

Ping wird ausgeführt für 192.168.100.42 mit 1400 Bytes Daten:
Antwort von 192.168.100.42: Bytes=1400 Zeit=5ms TTL=63
Antwort von 192.168.100.42: Bytes=1400 Zeit=10ms TTL=63
Antwort von 192.168.100.42: Bytes=1400 Zeit=6ms TTL=63
Antwort von 192.168.100.42: Bytes=1400 Zeit=4ms TTL=63

Ping-Statistik für 192.168.100.42:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 10ms, Mittelwert = 6ms

Auszug aus dem OpenVPN Client Log:

Code Select Expand

⏎[Oct 26, 2025, 11:11:02] Connected via TUN_WIN
⏎[Oct 26, 2025, 11:11:02] EVENT: CONNECTED vpn.***@192.168.2.230:1194 (192.168.2.230) via /UDP on TUN_WIN/10.99.99.2/ gw=[10.99.99.1/] mtu=1500⏎

Ich bin über jede Antwort dankbar, weil ich langsam nicht mehr weiß woran es liegen könnte, bzw. was ich machen kann.