@3lmar It turned out it was a totally different problem. The solution is somehow related to pfsense, because I would not have found it without pfsense's package capture. My windows 10 notebook on the OpenVPN was trying to connect via port 80, which seemed strange. I learned it did that, because the share wasn't on the same subnet. The solution was to disable NetBIOS over TCP/IP: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/direct-hosting-of-smb-over-tcpip Sorry for having disturbed you. Maybe this helps anybody else, who like me wouldn't expect a problem with windows pcs connecting to windows pcs. I should have stayed with linux.

@johnpoz said in Strange VPN Kill Switch Problem: https://forum.netgate.com/topic/67692/openvpn-kill-switch/6 That would be the other solution but is more prone to user error and I had to much open states with it if I recall correctly. You can also combine both to be really secure.

@bcruze said in PIA server changes: @cobrahead said in PIA server changes: @bcruze said in PIA server changes: There is also that super helpful ping command How can find PIA servers using the ping command? I am not trying to figure out which server I am using, I was looking for the entire list of servers, which used to be posted on their website. i misread. i thought you meant by IP address I apologize It's all good.

@dmallia said in VPN Speed: @ryu945 said in VPN Speed: What is your RAM usage? I have 3GB assigned to pfsense and it stays at 2.45GB used (approx 82%). no changes when I test vpn speed. The fact that such a slow speed has you use so much RAM makes me wonder if it is a RAM capacity issue. I know higher speeds need more RAM. That said, that does seem like a lot of RAM being used for that much speed. You can try giving it more RAM. I wonder if this is the issue because I have literally seen old wireless routers completely cut out when they try to pull bandwidth to fast. I assumed it was a lack of RAM to run the connection. Also, what is your RAM speed?

For some reason, it is working now.

@jared_ said in Need help routing OpenVPN to another gateway on the LAN: I have pfSense sitting on a network, the WAN interface is disabled and the LAN (192.168.1.0/24) has OpenVPN (172.16.100.0/24) server listening. That's not the proper way to connect a VPN server. Youf LAN devices will send response packets to requests from VPN clients to the default gateway instead back to pfSense, since they don't have a proper route for these IPs. If you want to run the VPN server behind a NAT router either remove it from LAN and put it into transit network, connected to the router and add a static route for the VPN tunnel network to the router pointing to the VPN server and add static route for the LAN to the VPN server pointing to the router add a static route for the VPN tunnel network pointing to pfSense to each LAN device you want to have access do masquerading on pfSense Lan interface.

@marvosa I'm sorry, but i don't know exactly what you mean. If I want to make the WAN Network accessible trough VPN, where the OpenVPN Service is listen, this is currently not possible. Other OpenVPN Implementations (e.g. untangle) add a direct route to the OpenVPN Server to solve the Problem. I think this should also be possible on PfSense, but i don't know how.. :( If you need more information, i can provide them to you.

@peter_apiit said in Create OpenVPN client but encounter error: https://protonvpn.com/support/pfsense-vpn-setup/ Did you asked proton for an update on their https://protonvpn.com/support/pfsense-vpn-setup/ ? It's based on an old version of OpenVPN, probably the 2.4.x series. The latest pfSense 2.5.2 uses the last (nearly) version of OpenVPN : 2.5.2 (version numbers are identical, this is purely a coincidence). The 2.5.2 and 2.4.x (OpenVPN !) are nearly identical. But their are differences. The question is : what does Proton use ? Btw : I'm not using proton myself. edit : This is what I would do : if their 'client app' uses OpenVPN, and that clients logs, uses the client log and the it's opvn file - and compare these with the pfSense OpenVPN opvn file and OpenVPN client logs.

@bingo600 said in Open VPN Site to Site and Remote Clients Combination: Dialin Client ip ranges @viragomann Thanks a lot for your advice guys; The dial in tunnel was not added to the Site 2 Site remote networks list, therefore could not be routed. Thanks again

Yeah domain override would work - just make sure that unbound allows via ACL queries from the other site IP range. Also keep in mind that if your looking for machineX, which might be machineX.sitea.tld, when it moves and gets a new dhcp lease in site b. You would want to find it via machineX.siteb.tld fqdn If you setup your machines to use suffix search for both siteA.tld and siteB.tld would be possible for the user to just look for machineX

You can use machine certificates for authentication. Certificates stored in local computer store or slipstreamed into openvpn config file. This makes vpn connection to establish with no authentication prompts.

It was compression issue. I understood it when looking at server OpenVPN logs and seeing error IP packet with unknown IP version=15 seen Some compression was turned ON on client side but any compression was disabled on server side. I was sure this misconfig would be detected automatically

@denndsd , have you tried to disable all mitigation settings? I had similar problem, which I managed to sort out only with downgrade to 2.4.

@peterlecki said in Remote Access VPN connects but unable to access LAN IPs: @peterlecki Is pfSense the default gateway on the destination device? It was not. That would be worth to mention. When request traffic is from outside its subnet the destination device send respond packets to its default gateway. To get the packets back to pfSense you can remove pfSense from the LAN and put it into a transit network. Then add routes to pfSense for the LANs pointing to the gateway and add a route to the gateway for the VPN tunnel network pointing to pfSense.

Ok, I figured it out. Lost hours and losing my mind but got it. The openVPN client assigned IP (10.8.0.x scope) can not be pinged for whatever reason, so gateway was considered down and traffic was defaulting to an alt (default) gateway. Disabling gateway monitoring or (better) specifying a working IP to monitor (I used 10.8.0.1 which is the openVPN server) fixed it.

@KOM , @marvosa thanks for the feedback, the problem occurred after upgrading from version 2.4 to 2.5.1 of pfsense. I performed a clean install on both sides with version 2.5.1 and recreated the rules again working correctly, I don't know if due to this update there was some inconsistency in the rules or internal routing of pfsense causing the problem.

@viragomann Thanks a million! You have done a great job by marking all the places to check. I have used a wrong client.ovpn file. With your help, the hard work of 3 days ended with a success.