@Scurz: Hi all, After lots of tries, I haven't found a solution. I'm setting up an openvpn server. My network is : LAN interface : 10.50.99.16 OPT1 : 10.8.0.1 OpenVPN : IPv4 Tunnel Network : 10.8.0.0/24 IPv4 Local network(s) : 10.50.99.0/24 My routing table as a client is : 10.8.0.0    255.255.255.0        On-link          10.8.0.2    311         10.8.0.2  255.255.255.255        On-link          10.8.0.2    311         10.8.0.255  255.255.255.255        On-link          10.8.0.2    311         255.255.255.255  255.255.255.255        On-link          10.8.0.2    311         224.0.0.0        240.0.0.0        On-link          10.8.0.2    311 In my case, I can ping my own gateway (10.8.0.1) but I can't reach the subnet 10.50.99.0/24. Do you have any idea? There is no NAT, everything is open in the lan rules. Thank you You need a separate subnet for the "tunnel network"; one that doesn't conflict with your OPT1 subnet.

00goat, I was getting the exact symptom this morning when I first set my MacBook up with Viscosity. In Viscosity turn on the Details and then open the log, third tab. I will give you pretty good clues as to what's FUBAR. In my case it was a cipher setting I had to comment out and I also had to turn on username/password prompting. But your server settings could be different so have a go at the Viscosity logs first. Doug

post your firewall rules. you might have a PBR rule thats routing incorrectly.

i know how. PM me for contact info.

Updated package and checked, yup now using remote-cert-tls server

After many hours of trail and error finally figured it out changed port 25745 UDP and it worked, like they say "where there's a will there's a way"

^^^^ I get the same situation with Linux.  IPv4 works fine, with IPv6 I can ping only the local end of the tunnel. Has anyone managed to get OpenVPN to work with IPv6, on either Linux or Windows?

It's not there any more because it's no longer necessary. :-) OpenVPN 2.4 has a new Windows service/GUI setup that no longer requires administrator privileges to run.

Thank you.

This may or may not be the problem … Long ago I ran into the same problem with openvpn and DD-WRT. I had three client users created. If one were in use another PC could not use it at the same time. A different client user id had to be used. Try a different user profile for each actual user or each unique device. Then the same user profile will never try to sign on at the same time using another device. (I have a unique id for each device since the same physical person might try to sign on from multiple devices.)

Commercial VPNs provide pipes for lots of simultaneous users. Their gigabit connection might give you 5Mb if a boatload of users are on the same connection at the same time. Later on, you might get many multiples of that faster. StackSocial offers a lot of lifetime VPNs for relative pocket change. Through them, the cost is very low. Take a look. I purchased two since they were so low priced.

The verbosity was originally set to 3, then I set it to 5 for the attached log dump, then back down to 3. It didn't really give me much more insight into the issue. I've tried the two in Canada and then 2 in the US. Same issues. Even when the VPN is connected, I am unable to even do a ping test on that interface. Absolutely nothing will travel over it.

Thanks for your answers.  I got my VPN running with PureVPN, so I am learning as I go as well.

There is a small icon in the action center and it turns green when openvpn is connected. Got it and I can now connect. I see that while I get a different subnet for IPv4, I just get an IPv6 address in the same prefix in my home network.  This will cause problems as it will likely not be able to connect to anything on my local network.  I'll try changing it to a different prefix.

I've started having this issue with PIA. The service has been rock solid on my pfsense box for 5 months, and just in the past week or so, I noticed that the VPN connection does not stay up. It drops with this error after about 5 minutes consistently.

If your upload on pfsense is 10mbps, and a client connects to pfsense even if its internet is gig/gig - any traffic that pfsense would need to send to this client would be limited to 10mbps. So if your routing internet through this vpn for example, or trying to download a file from something on the other end of the vpn - your speedlimit would be the 10mbps of pfsense upload.

The network you are connecting from isn't also using 192.168.1.0/24 as its LAN is it? What you are trying to do "just works" for thousands if not hundreds of thousands if not millions of people. All day, every day, no days off. There is no trick to making it work except for figuring out what you did wrong. Step 1: Stop looking at 2.3.3_1 vs 2.3.3 as source of the problem. It is not there. Step 2: Stop looking at pfSense as the problem. When those two truths are accepted you will be on your way to finding whatever it is that you have configured incorrectly. UPDATE 1:  Upgrading a working configuration from 2.3.3 to 2.3.3_1 does not break the OpenVPN LAN access. UPDATE 2:  Changing an OpenVPN setting (i.e. SHA1 to SHA256) after upgrading breaks OpenVPN LAN access. You can't just change server settings without making the corresponding changes to the client configurations. And UPDATE 2 is more of a connect or can't connect scenario. Not a can or cannot access some resources scenario. Slow down, work a hop at a time, check DNS resolution and pings. Take packet captures if you have to and figure out where you sent your traffic the wrong way.