OPNsense Forum

English Forums => 25.7 Series => Topic started by: lukazy on August 21, 2025, 02:23:02 PM

Title: Fighting with OpenVPN...
Post by: lukazy on August 21, 2025, 02:23:02 PM
Hi,

this is not my first install of OPNSense but my first that is OPNsense 25.7.1.

I have set it up pretty standard, nothing crazy:

Firewall -> Settings -> Advanced:
The OPNSense otherwise works fine, it is the Networks gateway, can connect to the internet fine, clients can connect to the internet fine.

But for the love of god I could not get it working.

UPDATE: Now it is 'working', at least sort of (scroll past my weird experiment)

Weird experiment (can be ignored)


I have given up on that and wanted to try another way.
I now have set up a second OPNSense instance (this time it is 25.7) as a VM (the main one is the active gateway).

Under Firewall -> NAS - Port Forward I have forwarded the VPN Port to the second instance.
The second instance has OpenVPN configured and for troubleshooting I have disabled all packet filtering on the second one.

I know this setup is janky but that is not the point.

I now can connect to my VPN.
I cannot hover use RDP to connect to my Server (RDP works fine within the network so I'm ruling out that the server has anything to do with it).
Here is the Firewall-Log of the main OPNSense Box:
Firewall-Log.png
(11.11.11.2 is my VPN Client & 192.168.153.101 is my Windows Server)

Ok nothing a simple Firewall rule can't fix right?
So then I go and create rules on the LAN interface.

A pass from the source to the destination IP with all ports does not work...
A pass any any rule does not work...

I then created rules that match the blocked packets exactly (I know it is a bit much but for testing but may as well try):
In and Out, both directions, exact IPs and Ports (I know the 42012 is just a random temporary port but I was kinda lost at this point)
Firewall-Rules.png

But the Firewall still blocks them as shown in the Log.
I do not have any Block rules, just a few more that allow traffic to other systems.
Why those packets are getting blocked by the default deny/state violation rule when I have explicit (or just a pass any any) rules that would allow them I do not understand.

Did 25.X introduce something new that would cause this kind of behaviour?

Another thing I found which was kind of weird is that my Port Forward Rule looks like this:
Interface  Proto Address  Ports  Address Ports IP Ports Description
WAN  TCP/UDP  192.168.153.53  49196  192.168.153.253  49196  Forward to second OPNSense instance

Notice the 192.168.153.53? This is not the IP of the OPNSense Box. It's IP is 192.168.153.254.


In Order to get it working I had to create this Port Forward Rule on the OPNSense Box:
Interface  Proto Address  Ports  Address Ports IP Ports Description
WAN  UDP  192.168.153.53  49195  192.168.153.254  49195  Forward from .53 to own LAN-Address (WHY???)

Notice the 192.168.153.53? This is not the IP of the OPNSenses WAN interface as you would imagine. It's WAN IP is 192.168.178.2 and it's LAN IP is 192.168.153.254.

I found out through the firewall log that my attempts at connecting to the OpenVPN Server were blocked and the destination was shown as .53.
I think during setup that the OPNSense Box got a DHCP Address (I have a Windows AD with DHCP running) that may have been .53.
But I have long changed the OPNSense Box LAN IP to .254  and the WAN IP to 192.168.178.2 and the box has seen a couple reboots and had all of its services reloaded through the console.
The WAN port has the IP 192.168.178.2 and is connected to a FRITZ!Box 7590 and is configured as an exposed Host so all traffic will go to OPNSense. The FRITZ!Box is just so I can get Internet.

Why OPNSense still thinks .53 is relevant I don't understand. I even exported the config, looked for the .53 IP in that config, found nothing relevant and uploaded that config to the machine again.
By the way, there is no other device inside the network with the IP 192.168.153.53.

I have 2 other instances of OPNSense at different other locations (all behind a router as an exposed host like in this case) and none of them have a Port Forward Rule.
Just a simple Firewall rule to allow the OpenVPN Port.
But I guess on those the traffic comes in directly to the WAN Address (as you would imagine) and not some weird non existing IP (the .53 here).

What am I missing here?
It's either something obvious and I can no longer see the forest for the trees or there is something seriously broken.

Any help is greatly appreciated.
Title: Re: Fighting with OpenVPN...
Post by: viragomann on August 21, 2025, 03:12:10 PM
Quote from: lukazy on August 21, 2025, 02:23:02 PMI cannot hover use RDP to connect to my Server (RDP works fine within the network so I'm ruling out that the server has anything to do with it).
Here is the Firewall-Log of the main OPNSense Box:
The blocked packets are out of state. They are response packets from the server.

This could be due to asymmetric routing. Maybe the packets from the client to the server went another patch as the response packets from the server.

You're running now the VPN on your second OPNsense. So if the packets from the VPN client come from the second box, responses from the server have to go back to this node. This means, the server has to use this as the default gateway. Is this the case?
Title: Re: Fighting with OpenVPN...
Post by: lukazy on August 21, 2025, 03:22:12 PM
Quote from: viragomann on August 21, 2025, 03:12:10 PMThis means, the server has to use this as the default gateway. Is this the case?
The second OPNSense instance has the first one as it's gateway, did you mean that?
It can connect to the internet fine as well.

Gateway Settings of second OPNSense instance (the VM)
Gateway-Settings.png
Title: Re: Fighting with OpenVPN...
Post by: viragomann on August 21, 2025, 03:32:17 PM
I am talking about the server. I guess, it has the first OPNsense as gateway as well.
But if you want to access it from  "outside" over the second, it sense responses to the second.

You can go with this setup with masquerading the traffic to the server as well, however.
To do so go the NAT > Outbound.
Enable the hybrid mode.
Add a rule:
interface: the one facing to the server
source: OpenVPN tunnel network
destination: any
translation: interface address
Title: Re: Fighting with OpenVPN...
Post by: lukazy on August 21, 2025, 03:52:01 PM
Quote from: viragomann on August 21, 2025, 03:32:17 PMI am talking about the server. I guess, it has the first OPNsense as gateway as well.
But if you want to access it from  "outside" over the second, it sense responses to the second.

You can go with this setup with masquerading the traffic to the server as well, however.
To do so go the NAT > Outbound.
Enable the hybrid mode.
Add a rule:
interface: the one facing to the server
source: OpenVPN tunnel network
destination: any
translation: interface address
The Problem has be sort of fixed.
TLDR: The VPN to the main OPNSense instance now works, even RDP works, but I have a weird Port Forwarding Rule to it's own interface now that is needed.
I have never done that on other systems and this 'ghost' IP issue seems to be the root cause I think.

It only works with this rule in place.
Port-Forward Rule.png
.53 is not the OPNSense's IP, neither WAN (192.168.178.2) nor LAN (192.168.153.254).
But in order for the VPN connection to work I need to have this rule to forward the 'ghost' IP .53 to it's own LAN interface.... God knows why

Do you have any idea what could be the problem here?