Assignment of OpenVPN port to an Interface shuts down access to Netgate 2100
-
I have a Netgate 2100 that is set up with an OpenVPN server. I can readily connect to it remotely with the SparkLabs Viscosity client. When I define a VPN interface, however, in Interfaces → Interface Assignments, where it looks like this,
and I enable that interface, all access to the Netgate itself is blocked. This is also not a matter of having Allow firewall rules for the new interface. They do not help.
What’s more, simply disabling the new interface does not bring back access to the Netgate. I have to restore settings from a backup of the state the settings were in, before I made that change in Interfaces → Interface Assignments.
I also manage a second Netgate 2100, where I do not have that problem. The ultimate goal was to enable Avahi mDNS repeating between the LAN and OpenVPN subnets. On the one 2100 this works, on the second I cannot get it to work, because the interface breaks OpenVPN functionality.
-
@DominikHoffmann are any subnets overlapping?
-
@SteveITS: Yes. I had one client connecting in my site-to-site VPN at 192.168.4.2/24, another at 192.168.4.2/24, and a third at 192.168.4.5/24. Now they are at 192.168.4.6/29, 192.168.4.14/29 and 192.168.4.22/29. Hopefully, that fixes things.
-
Now I have the same issue on one of my other Netgate devices. It’s an 1100. As soon as the interface defined for the
ovpns1network port goes live, I am blocked from accessing the web GUI.I am going in and am restoring a configuration from before I started defining the interface. That fixed it on the 2100.
From this very unexpected behavior I conclude that this is a bug. I am about to update this 1100 to 24.03. I will report back with my findings about whether the behavior is the same or not.
-
@DominikHoffmann said in Assignment of OpenVPN port to an Interface shuts down access to Netgate 2100:
@SteveITS: Yes. I had one client connecting in my site-to-site VPN at 192.168.4.2/24, another at 192.168.4.2/24, and a third at 192.168.4.5/24. Now they are at 192.168.4.6/29, 192.168.4.14/29 and 192.168.4.22/29. Hopefully, that fixes things.
This actually related to a different issue. I blindly responded, thinking it would go into a different thread.
So, the answer is, no, I don’t have overlapping subnets at all.
-
I have since found that, while this inexplicably affects a live OpenVPN connection, after a reboot of the firewall, with the OPENVPN interface in place and activated, access to the device via OpenVPN works without issues.
Definitely looks like a bug to me.
-
@DominikHoffmann Since you can reproduce it I'd create a bug report at redmine.pfsense.org.