The windows client yes.  I'd assumed you were talking about pfsense as client.

@Derelict: Should get you going OK.  Note that this connection will be routed so broadcast discovery will not work. Two errors in the video.  The WAN rule on prirouter only needs to be UDP 1194, not TCP/UDP and the WAN rule on secrouter is unnecessary and can be eliminated completely. Thank you for your help. Actually broadcast is exactly what I want the most. Furthermore, I followed https://forum.pfsense.org/index.php?topic=46984.0 and it seemed to be covering what I am looking for, but how can I use it as point to point (pfsense to pfsense), rather than pfsense directly to the client PC?

Found my answer on below thread https://forum.pfsense.org/index.php?topic=81291.msg443963#msg443963

IPv4 tunnel network should probably be optional also because you might be doing pure IPv6, and in that case you would put an IPv6 tunnel network but no IPv4 tunnel network. The validation is in /usr/local/www/vpn_openvpn_server.php Look for: if ($pconfig['dev_mode'] != "tap") { $reqdfields[] = 'tunnel_network'; $reqdfieldsn[] = gettext('Tunnel network'); } else { ... That makes tunnel_network a required field.

Hi doktornotor, it succeeded: before I tried the same approach, but due to the concurrent presence of another problem (the missing change in depth, I suppose) I thought it was wrong… now it works. Thanks a lot, Diego

I should be doing this in the next week or so, if I do my part right the next post I make on this will be a successful-themed one!

Found great help on redit…  I suggest people go there.

Nice work Phil. Your changes works and the generated config now selects the IPv6 CARP interface address. Will make a bug report during the afternoon.

What are your pfsense server settings?  I'd love to see that server config page from pfsense to get an idea what you are doing wrong.

Fair enough.  This actually solves many problems, as many online forums are blocking me (PIA is my VPN service provider, and all their IPs are getting blocked all over the place). Had no idea the solution was so easy, really, thanks again.  This is a huge help.

192.168.0.0/22 conflicts with 192.168.1.16 on WAN (Presumably /24).  You can't do that. And your pass any any rule on WAN is bad news.  Delete it.  With that in place you can just use the internet and don't need a VPN. Why is this in OpenVPN if you're using IPsec?

I have the same issue here. It used to run flawlessly, but suddenly stoped. I already rebuilt the server, restored the configuration and got stucked on the server. Can ping, open the url in a browser but cannot reach any of the machines on the LAN side.

May have been an issue with PIA.  Mine broke for about four hours a couple of days ago, never changed a thing.  Did a restore settings from a previous back up and rebooted, came right back up.

OP, did you find a solution to this?

Thanks Coolspot. Disabling monitoring the PIA gateway fixed it.  :)

I know this is certainly a unique request. The company I work for controls what we can access online.  and I want to be able to browse through my home networks Internet.  But if I allow someone else to use it I want to make sure they can not get to my local network.

Thanks for the reply. Still not working. I've done this already. I have connections from site B to A and to C, but its not always routing correctly from C to A or from C to B. If I ping a server on site A, I get a reply. Then I ping a server on site B, I don't get any reply. After a minute or so I do try to ping A again and don't get reply, but do get reply for site B. :) I thing there is an issue with the routing somewhere on site C. Site C is a client to both A and B. I also tried tracert to both sites and the same issue. I get a route untill the gateway of site C, but not further. Same as pinging. Sometimes I do get the full route as it should be and sometimes it just hangs on the first hop. Is it an issue with NAT or the OpenVPN Service? Any suggestions? See images for the tracert info. The send part of the image is performed just few minutes after the first tracert action. Thanks, Sead [image: VPN-tracert-issue.png] [image: VPN-tracert-issue.png_thumb]

Yes.  It's just on the WANs 172.27.0.5/9. Search for "OpenVPN assigned interfaces" to see what you need to do to get a pfSense interface assigned to an OpenVPN instance.  Without doing that you can't NAT on it. I don't think any of this is possible in pfSense on IPsec.  All the phase 2 entries put routes in the system routing tables I think so there's no way to distinguish two subnets that are the same. The best thing to do is renumber something.