@johnpoz said in How to disable data encryption question.: @pwood999 I would think if using ncp to neg the encryption, it would only need to be set on the server. I have never setup openvpn without encryption ;) Server and clients all have to agree on a common cipher, so they all need to have 'none' chosen as the only option in the data cipher list and fallback cipher.

@Deadringers As mentioned in your other thread, rules on the OpenVPN tab have priority over ones on the interface tab. However, to get request packets on incoming traffic routed back properly, a pass rule on the interface tab must match the incoming traffic. This means, you have either to remove all pass rules from the OpenVPN tab or modify them so that they do not match to the forwarded traffic. The same is true for floating rules, if there are any applied to the VPN interface.

That sounds like a local network config issue on the target system. There are some cases where Windows will only accept inbound traffic from its own subnet unless it thinks it's on a certain type of network. Like if it's set to public vs private but maybe not exactly that. If you need to fudge that you could setup a hybrid outbound NAT rule on the LAN to make the source of traffic appear to be the local network, but that can break or complicate certain protocols. It's best to fix the local network config on the client system.

I forked this off into a new thread so it would all be together since it's likely a different issue than the post it was on before. If you are still having this problem on 2.7.0, please read through the following: Most likely there is a configuration problem that has always been wrong but some change on the backend changed and now your previously "working" settings which happened to be incorrect in some way stopped working. A few common things we have seen are: SSL/TLS setups where people had filled in a tunnel network on the client when they should not SSL/TLS setups with a /24 tunnel network where the Client-Specific Overrides were not setup correctly breaking LAN-to-LAN routing Static Key configurations using the wrong subnet size for the tunnel network (e.g. /24 when it should have been /30) Not explicitly setting the same topology on both sides Some other routing conflict preventing the correct entries from being in the tables A configuration that worked by chance before that was never correct (e.g. routes in System > Routing instead of in OpenVPN natively) Policy routing rules overriding the VPN and sending the client traffic in some unexpected path Missing or incorrectly configured default gateway (e.g. set to auto when it should be set to a WAN or WAN failover group) Compare your setup against the reference here: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html There are a lot of troubleshooting suggestions for that sort of stuff at https://docs.netgate.com/pfsense/en/latest/troubleshooting/connectivity.html But to boil that down a bit, you should check: Look at the OS routing table on both sides, make sure there are entries for the default route and opposite side LAN(s) and that those routes are pointing to the correct OpenVPN interface(s). When you ping from the firewall make sure to ping from both the OpenVPN interface itself (default source) and again using the LAN interface as a source. That tests routing between the LANs in both directions, not just to/from the OpenVPN interface directly, which is a much different test. When pinging from a client on the LAN, look at its states under Diagnostics > States on both firewalls, there should be two entries on each, one as it enters the firewall and one as it exits the firewall. If something like outbound NAT is catching it, the NAT would show in these states. If the traffic is taking the wrong path, that would also show (e.g. it should go in LAN, out VPN, in VPN, out LAN). If the packets are exiting a WAN unexpectedly it may be from those clients hitting a policy routing firewall rule, so you might need to add a rule above whatever rule it's hitting to pass VPN traffic without a gateway set. That should give you a better idea of what's going on and what needs fixed.

@matt84 I'd be happy to share my configs with the devs.

I have rolled back to 2.6 too.

Kill disconnects the client and it's free to immediately reconnect (e.g. maybe to the next server in its list if it has multiple) Halt tells the client it should terminate completely (e.g. stop the process) so it will not reconnect. https://docs.netgate.com/pfsense/en/latest/monitoring/status/openvpn.html#ssl-tls-client-server-mode

The the LAN at 1 can ping 2 but not the other way around then your routing is probably OK and it's most likely a NAT or firewall rule issue. There are a lot of troubleshooting suggestions for that sort of stuff at https://docs.netgate.com/pfsense/en/latest/troubleshooting/connectivity.html But to boil that down a bit, you should check: Look at the OS routing table on both sides, make sure there are entries for the opposite side LAN(s) and that those routes are pointing to the correct OpenVPN interface(s). When you ping from the firewall make sure to ping from both the OpenVPN interface itself (default source) and again using the LAN interface as a source. That tests routing between the LANs in both directions, not just to/from the OpenVPN interface directly, which is a much different test. When pinging from a client on the LAN, look at its states under Diagnostics > States on both firewalls, there should be two entries on each, one as it enters the firewall and one as it exits the firewall. If something like outbound NAT is catching it, the NAT would show in these states. If the traffic is taking the wrong path, that would also show (e.g. it should go in LAN, out VPN, in VPN, out LAN). If the packets are exiting a WAN unexpectedly it may be from those clients hitting a policy routing firewall rule, so you might need to add a rule above whatever rule it's hitting to pass VPN traffic without a gateway set. That should give you a better idea of what's going on and what needs fixed.

10.0.0.0/8 (255.0.0.0) [10.0.0.0 – 10.255.255.255] 172.16.0.0/12 (255.240.0.0) [172.16.0.0 – 172.31.255.255] 192.168.0.0/16 (255.255.0.0) [192.168.0.0 – 192.168.255.255] https://en.wikipedia.org/wiki/Private_network -Rico

@MikkelBalle said in Multiple clients - VPN provider is sometimes assigning same subnet to different clients: Is there anything else I can do to avoid the issue? I don't think so. But in my experience the problem only occurs if gateways have the same ip-address, the same subnets don't matter. So maybe you should look into this weird behavior of your setup.

@skysurf76 said in Request for suggestions for setting up remote firestick access to local LAN resources via OpenVPN on PFSense: install OpenVPN on the firestick I wouldn't even think that is an option to be honest.. The easy solution would be at the location the firestick is would be to create a vpn client connection on their router to the home where the server is pfsense. Now with any android device you could prob side load openvpn client?? But you going to trust where you get this side load apk?

@michaelschefczyk I started from zero added everything from zero as it was a branch office Firewall with just 2 users and this configurazione: OpenVPN Access Server (for when I need to access my other servers and I'm not in the office or at home as I limit my firewall/servers and my customers one only to my own IPs) One OpenVPN Server Site To Site Shared Key where one pfsense in cloud was connection (stopped working) One OpenVPN CLient to the main site with PfSense with shared key which stopped working. So I started from zero I added just Openvpn Client as SSL/TLS and in NO WAY I could make it working and the certificates are ok, if from the firewall I ping the other side it's working just it does not rotate from LAN through the VPN. I disabled it and I configured Clied as Shared Key and BUM IT WAS WORKING. So I started to add users, Nat Rules and lalalalal. It was working... Then I added first Server (Remote access) and... it stopped working... if I disable the Remote Access server and I rtestart the client connection it works again. it's evidently a problem of routing and the subnets are all UNCOMMON and all DIFFERENT as they have always been. I don't know what did they mess up but surely the fact that SSL/TLS site to site is broken is something abnormal moreover they tell that SHARED KEY IS DEPRECATED and we should implement SSL/TLS and they break the new one... Moreover to whom can we ask? No one knows...

@chudak I think one of the other fixes in the app was something about fixed issue with display of available update I normally use openvpn, but I do have tailscale setup as my backup, I am just so use to openvpn its my go to. when I was adding the new profiles for my new certs on my ipad, I noticed I had not added tailscale to it - it was very easy ;)

Thanks guys useful info! Didn’t realise ping was changeable to interface as it’s came up as auto - but never clicked it to reveal the rest (dumb I guess) Did the reset to previous config just in case - didn’t help but after a few hours an few reboots without changing anything everything started working again so assuming there was a problem at the remote server end tho it was over many different countries and servers and the phone Nordvpn app was ok all the time - tho that’s running IKEv2 not upd OpenVPN if that changes anything - so who knows

@viragomann I reposted, thanks https://forum.netgate.com/topic/181119/solved-pfsense-2-6-0-system-logs-message-openvpn-failed-to-start