@Rico said in pfsense - TLS error TLS handshake failed: Second you need to disable Block private networks and loopback addresses (Interfaces > WAN) Not needed, since the source would be public - unless the nat router in front of pfsense was doing source natting? Which normally not the case. As you can see from actually looking at the rules block drop in quick on igb1 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8" block drop in quick on igb1 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8" block drop in quick on igb1 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12" block drop in quick on igb1 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16" They are only block when source matches rfc1918, not dest.. So forwarding the case of double nat to pfsense wan IP that is rfc1918 is not an issue with the default block private networks rule that is on wan. So no need to disable it - unless the source is going to be rfc1918.

Added to what @NogBadTheBad said : Start up a new OpenVPN server on - example - port 1195. Assign this user - his credentials - to this VPN. Assign the OpenVPN interface of this instance to an Interface. Now you can use this firewall for this interface to fine-grain the access on IP "destination". When a user comes in using a VPN, he can access - typically - your LAN(s). But all devices on these LANs have their own access codes. The server your user should access has it's own user privileges set up, right ? Btw : put your server on a DMZ ....

Of course... thank you. I was looking at the rules over and over and never thought of looking at the "Remote Network" in the VPN settings.

Can someone at least give me an idea of which exported profile I should be using.

Post a screenshot of your rules so we can see what you've done.

It might be best for you to leave them at their defaults unless you have a specific reason for changing them. Some say that compression isn't required at all. This was an interesting read that talks a lot about compression and its effects: https://hamy.io/post/0003/optimizing-openvpn-throughput/

Yes, of course !

That's normal. Those routes are internal to OpenVPN (iroutes) which is explained in the text on the fields in the overrides. If you want the subnets to be routed into OpenVPN in the routing table you need to enter them as IPv4/IPv6 Remote Network(s) entries on the server, not in overrides.

In Peer to Peer ( SSL/TLS ) mode i have tried add "keepalive 2 5" in Custom options on Server side (if type high values, it did not help in client reconnection, but on client reboot higher values works, it's important that keepalive was lower, than client reconnection time take), and seems that it helps shows correct link state on Server side. Seems that client make "reconnection" very fast, that Server status did not catch new connect in default pfSense's "keepalive 10 120" or something look like this.

This is a pfSense forum. I have no idea about OpenWRT's ipchains rules or whatever they are, sorry.

This is the solution that worked Get the username under: System > User Manager. It's the common name. VPN > OpenVPN > Client Specific Overrides Click Green plus Under Advanced enter the static IP: ifconfig-push 192.168.2.99 255.255.255.0; Firewall -> Rules -> OpenVPN Add rule with Action "Pass" on Interface "OpenVPN" Enter "Source" as the IP address 192.168.2.99 Enter "Destination" as the IP to grant access, such as 192.168.1.53 Set Port to MS RDP 3389 Save Add another rule with Action "Block" and Interface "OpenVPN" Set source to the VPN static IP: 192.168.2.99 Destination is set to "any" Save Make sure the "Pass" rule you added is above the "Block" rule

Yeah I'm aware, I'm only asking if you guys know about it. :)

I managed to solve this but the mobiles still don't connect through the tunnel, does anyone have a good idea?

You need to go to the Certificate Manager and add your VPN's CA certificate authority cert there first. Make sure you set the Method to Import an existing Certificate Authority. Paste your CA cert under Certificate Data then Save. The cert includes the starting and ending dashes so make sure to include those. Now you can run the wizard under VPN - OpenVPN - Clients. Most fields are self-explanatory. Go through it and see what happens. Come back if you have questions or problems.

Sure, come back when you've got a config you can reproduce the problem with.

Just some hints to tie things down a little.. You can easily make your tunnel network a /30 or (/29 if more than one remote address is needed) for just one laptop doing a roadwarrior setup such as that. Then on your OpenVPN firewall rule make "source" the same as your tunnel. 10.0.0.0/30 /29 ect.. Make destination your local LAN if you only have one local subnet to worry about. It is most likely absolutely safe to leave it as is but if your inclined to worry or just want to tinker more.. this is an option for you. Good luck!