@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.

@jimp ok, thanks I see that now. both the VPN servers are Asus AX-11000 routers, so I guess I'll have to install a pfsense box at one of those locations because I don't see any way to change the CN.

I confirm your solution is so simple and working very well.

I just renew the server certificate, client reconnecte to the server instance and continue to work like before.

Thanks again!

Ditto. I couldn't replicate it on 2.6.0 / 22.01.

Looks like it was fixed by https://redmine.pfsense.org/issues/12172

@viragomann
I believe the problem is related to OpenVPN.
Today the link SSH worked, but I lost it while I was working.
From the log I see

Nov 28 08:41:19 openvpn 46588 MyLoginName/MyRemoteIP:46059 [MyLoginName] Inactivity timeout (--ping-restart), restarting

But I was working both on the pfSense dashboard and on a web panel of the server in DMZ.

.
Then I see many rows of this type, every 5-10 seconds.

Nov 28 08:44:02 openvpn 46588 MyLoginNam/MyRemoteIP:45524 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2210 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Finally I would not want it to be related in some way to the problem I have already reported in this post; after starting the VPN connection, after about a minute I lose the ability to access the internet although I have configured the Outbound.

Fix found, for those interested the solution (I needed) can be seen here:
Link
https://www.linuxserver.io/blog/2017-05-01-how-to-run-pfsense-with-pia-vpn-but-still-use-plex-remote-access

The section which is new that appears to fix the issue is named How to bypass VPN for Plex Server connections to plex.tv

But i'd advise following the entire guide to ensure all settings are correct if you have problems still.

Hope this helps!