@viragomann

I always wondered if the space matters.

It turns out I'm wrong in what "works" -- while the routes are being created for both server subnets (and traffic is passing from Server->Client and back), Client-initiated traffic will only route to the first listed subnet.

I've removed the space, and things look promising. We'll see if this holds up. If so, I can't believe it's something so stupid.

@justanotheruser

pfSsh.php playback svc restart openvpn server 1

And here in a cron:
10 10 * * * root /usr/local/sbin/pfSsh.php playback svc restart openvpn server 1

@viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

Possibly there is network or route overlapping on that interfaces with the remote 10.30.51.0/24.

This is correct. The 10.30.51.12, 10.30.52.12 and 10.30.53.12 hosts are Windows Servers acting as routers for local 192.168.6.0/24 networks. This overlapping is causing the connectivity problem on the VPN when the 192.168.6.0/24 NIC is enabled. I could make this secondary LAN unique in each site so that there is no overlapping, but for now this is Ok.

@viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

As far as I know this is needed by pfSense to route traffic to OpenVPN.

Ok..

Well, everything is working fine so far.. Thanks! 😬

@gertjan said in OpenVPN server broken after upgrade:

@squeakie

pfSense 2.5.2 uses a new version of OpenVPN - see the pfSense release notes.
This might, depending settings used, have an impact on the server client traffic.
Did you exported clients settings ?
Check also if "Tunnelblick 3.8.7a (build 5770)" supports the OpenVPN version that is used by pfSEnse :

[2.5.2-RELEASE][root@pfsense.athome.net]/root: openvpn --version OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 24 2021 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10

The Openvpn version is 2.5.2, identical to the pfSense CE version, that's just a coincidence.
OpenVPN 2.5.x had a lot of changes compared to 2.4.x (see OpenVPN 2.5.x release notes).

Hi,

Thank you for your response, I actually got it to work again after reading some other post that had similar issues.
I only allowed some AES 192 CBC chipers and checked the tickbox "Do not include OpenVPN 2.5 settings in the client configuration." during export.

@ilya-v authentication and encryption is better setting. Your clients just need to know to use it as well.

@jaci said in LAN Access to OpenVPN Clients without Site-to-Site:

PfSense as OpenVPN server

Also as default gateway?

The primary issue here is that PfSense is routing the entire tunnel subnet (10.99.99.0/24) to the first client address (10.99.99.2), regardless of topology (subnet/net30). If a client is connected at 10.99.99.6, it is unroutable from the Pf box. This limits only a single pingable client at a time on 10.99.99.2, which is not desired for my use case.

Normally there shouldn't be any issue. Since all the OpenVPN clients are within an L2 which is connected to pfSense, there is no need for any route at all.

If pfSense is the default gateway and you have a proper firewall rule on the LAN, LAN devices direct traffic for 10.99.99.0/24 to pfSense LAN interface. pfSense passes it to OpenVPN and OpenVPN will know, how to forward the packets to the clients.

Both the server and client override configs only specify the tunnel IP range (as well as the local accessible range for the server, with deny rules in the firewall for the backup server clients).

The CSO overrides the server config, therefor it's called "override".
As long as there is no pass rule on the OpenVPN interface, no access will be allowed anyway.
If you have an interface assigned to the OpenVPN server, remember that the OpenVPN tab is an interface group including all OpenVPN instances. Rules on this tab will have priority over interface tabs.

Anyone?

@ovidius
Do you have firewall rules on the client site LAN to allow access to the server?

@pinballwiz said in NordVPN Obfuscated Server Use:

I was hoping that I could switch to a obfuscated VPN server to alleviate VPN detection so that all sited work,

Not on networks that behave like the internet. There must be a source IP and destination IP.
Otherwise there will be no traffic.

And yes, it probably happens : big companies (employees) subscribe to the same VPN offers as you. They test out all VPN servers for that VPN provider in every country of that provider, note down the IP used, put them all on a list, and block these.

@gertjan said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

He isn't pushing "10.0.10.0 255.255.255.0" (right ?)

No he isn't pushing it - but you wouldn't need too.. The problem I saw with his configuration was that pfsense showed no route for his tunnel.

tunnel.jpg

So something glitched or his instance wasn't actually running as I showed. If the instance is running there should be routes on pfsense for that tunnel network. See where I tuned off my instance and the route went away.

My point about pushing as well - is there is really no reason to have to add those. As long as you list them as local networks they are auto pushed.. You don't need to add them to the options box, etc.

@audiobahn
If a device is accessible from other devices within the same subnet, but not from the VPN or other network segments it should be accessible from outside with NAT though, because this way the packets get a source IP from its own subnet.

However, in most cases it is the firewall on the respective device itself, which is simply blocking outside access. So the NAT is a hack and not recommended. You should better configure the devices firewalls accordingly.

There are only rare dumb devices, which have no possibility to configure a gateway, where NAT is a good workaround.

Likely because OpenVPN is single-threaded? The faster that one core is, the better.

@viragomann

Thanks for your clear explanation, got some rules to set up!

Yes, right and no change :)

@mikeyno said in Using DNS from VPN Provider (ExpressVPN):

The help text implies that "Pull DNS" should cause pfSense to use DNS servers assigned by the OpenVPN server.

Agree. So there might something be wrong.

@m0l50n said in Errors on OpenVPN logs server:

I mean, 2 clients from the same location connecting to the same OpenVPN server (same WAN IP) on same protocol (UDP) can be problematic?!?!?

Not problematic.
The ports are different.
You have a OpenVPN set up to listen on port 1200
and you have another OpenVPN server set up to listen on port 1195.
Two complete separate instances, using their own settings.

Example : many web server have two processes running :
One web server, listing on port 80, doing the ancient "http" stuff.
Another web server using other settings (with some TLS settings added) listens on port 443 and handles the "https" access.
Both web server process serve the same data, doing the same things. It's just the "communication channel" that chances.