@viragomann , first, thanks again for your help and support on this. for all and benefit of the forum : Took me a long time to figure out , as there was several issues , I bypass all tests done going to outcome 1 - my hardware was not strong enough : changes where not applied properly all the time - > this is why I had non consistent behaviors ( I set manually the "Firewall Maximum Table Entries", so apparently no error, but all changes were not applied) Solution to this 1st point : ordered a new box ( that's why it took some time to get it from china ... ) 2 - I had duplicate ranges in my IP's ( the one assigned by VPN was another one as well on another link of my FW ) Having solved these 2, I have the VPN connection created, stable with a GW defined. In the meantime, I have in the new box a wifi connection, that I 'm gonna use as fail-over solution. I will be able to make tests unlink from the VPN, and see if now I encounter the same problems Thanks

@ralienpp said in Communication between clients from different OpenVPN networks: Is such a setup supposed to work, in principle? What troubleshooting methods can I use to understand the root cause of the problem? Your issue is strictly routing. The fact that VPNs are used is relevant, as when up, they simply provide an IP connection. So, check your routes and make sure the various devices can find a route, either via default route or specific routes.

@knothing said in How to use multiple WANs to make fater peer-to-peer connection?: LAGG Suppos I have created LAGG interface. What next?

@graeme-thomas said in Telnet to host via VPN not working: It seems like the vpn is not allowing icmp or telnet to route. Use Packet Capture or Wireshark to see how far the packets are getting and whether you're getting a response. For example, you could run Packet Capture on the pfsense end of the VPN to see if the packets get that far. However, I can assure you that OpenVPN passes pings as I have done that many times. If your pings aren't getting through, then you likely have some rule issue.

BTW: That Package Manager message is a general footnote/explanation: [image: 1632992610435-package_manager.png] -Rico

Ok, Then this is as clear as it gets : @gertjan said in OpenVPN will not connect: TLS Error: TLS handshake failed means : This : [image: 1632913190836-cc3c65c4-515a-4d7b-942a-70bce8617643-image.png] or, more specific : one or more items in this list (marked with a red cross ) : [image: 1632913309386-3492f3a5-889b-4025-8f9f-5d95e8e77358-image.png] doesn't correspond with the OPVN client file (OpenVPN client settings). The server disagrees with the client. The servers throws out an 'error' : TLS Error: TLS handshake failed. edit : and before you think : "why does this happen to me ?" The answer is a solid : "go talk with the admin". We all see this error ones in a while. Rarely, it works 'right away'. ( at least, it never did for me ;) ) What I normally do : I compare the config file of the server and the client. These are small text files. Easy to read. This is the old fashioned way of making to devices talk to each other : compare their settings on both sides - using a paper and pencil. Btw : also compare your OpenVPN server version number - and the OpenVPN client version number. If they differ, you also have to read the OpenVPN doc of both version, that is, the details of all the settings used. You're good for a visit at openvpn.org - the section 'manual'. Just you know an OpenVPN setup can be activated in less then 8 minutes : do this https://www.youtube.com/watch?v=jQHqPq7ftz4 ;)

@viragomann That fixed the problem, thank you very much! It looks like only VPNUnlimited has this issue, PureVPN and VPNSecure do not require to select "Don't pull routes"

@lesquestionsdetoto Hi, any idea ?

@stephenw10 said in I need to restart the OVPN tunnels after a pfSense reboot: Does the client get the correct routes? Do you see blocked traffic?

@jimp I will try, thanks you!

Looks like the issue was pfBlocker. Every time I tried to make rule changes I would get notice that there wasn't enough memory to load the rules. Pulling out pfBlocker and having it clean out the config fixed it. I've never seen pfBlocker affect anything other than WAN. Threw me for a loop.

@marci and what does the fqdn resolve too, from your ping its resolving to that ping www.digitec.ch PING www.digitec.ch (198.18.0.75) 56(84) bytes of data. So clearly your never going to be able to go there if its resolving to such an IP. The other question is how and the F are you getting any response from that IP? 64 bytes from 198.18.0.75 (198.18.0.75): icmp_seq=1 ttl=63 time=18.3 ms I guess its possible your ISP has such a network internal to their network.. That would be bad practice for sure. But it is possible - but the bigger question is how/why your resolving the fqdn to that IP in the first place? That site for sure is not being hosted on such an IP. Even if was recently decided to make that public space now, kind of how 1.1.1.1 was once not valid public IP space, and now is. In the current state of deployment if that was the case - it wouldn't work for pretty much anyone because it is still listed as bogon (which do not route on the public internet - or atleast are not suppose to). And if that is the case - why has arin not updated to reflect that it is now owned by company xyz, vs still listing it as special use space. if I had to take a guess to why it works when you connect via your phone to some vpn, is your phone (different dns, doh maybe) or the vpn dns is resolving it to the correct IP, while how you have pfsense setup its not resolving correctly. But no your not going to get there if it resolves to that 198.18 address. Since it is not valid IP, nor is even suppose to route on the public internet.

@romanvekil said in pfSense OpenVPN on VPS client not access internet: here wireshark listening vpn interface form pc when connected Would like to know if you can see these packets on pfSense OpenVPN interface likewise. I suspect, you can't. In this case, I'd recommend to tear down the OpenVPN server and start from scratch. Have read some threads here in the past, where people complaining similar issues and never got it working.

Please close the topic. It was Debain 10 Iptables and nftables conflict.

@viragomann yah, figured out what the issue was. seems like because the routing policy was set to *, it was messing up where to send the traffic. Once I explicitly set the gateways for each of the VLAN's, it worked.

@droidus said in Connection Help: I am using the openvpn app OpenVPN connect? This is what I use and it writes a verbose log file. [image: 1632261577672-d93e8af4-5f11-4e0c-8793-9103176cc8fc-image.png] It can be displayed by hitting the upper right icon.