Messages

Do you not have to select the rulesets the policies get applied to?
Or does selecting none automatically mean it is applied to all?

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

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.
You cannot view this attachment.
.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?

This 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)
You cannot view this attachment.

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

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:

• Created my own CA
• Created an OpenVPN Server Cert
• Created a User
• Created a User Cert
• Set up my OpenVPN Instance
• Set a LAN Firewall rule to allow the OpenVPN Port

Firewall -> Settings -> Advanced:

• Checked -> Reflection for port forwards
• Unchecked -> Reflection for 1:1
• Checked -> Automatic outbound NAT for Reflection

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:
You cannot view this attachment.
(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)
You cannot view this attachment.

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.

I found it to work only if you use the Destination/Invert checkbox (not the source) which makes more sense.
Or am I wrong?