Sasansgh, if I were in your place, I would have contacted PIA's customer support team and ask them the resolution of my query, because they would be in a better position to resolve your query.

I would start by checking MTU sizes with the ping command. Why not use IPSEC for your site-to-site tunnel ?

@johnpoz Any chance you have an idea here?

You gave 2 examples where vpn make sense - circumvention is the key... If what you are looking to protect yourself is your isp saying hey you can not do that p2p because you shared xyz whatever. Ok then sure vpn works.. If you want to circumvent some geographic restriction, again sure vpn can make it look like your coming from region A while your really in B.. But lets be clear here - your not protecting yourself ;) Your hiding shit you could get in trouble for or trying to break someones policy on where you can come from. So you policy route your this traffic, and this traffic only. If your son wants to p2p.. then policy route his p2p traffic out the vpn. If you want your media player to stream something from region B, then policy route that connection out vpn in region B.. Lets be honest here, your not "protecting" yourself from big bad isp here ;) To be honest if you want to download p2p stuff you be much better off getting a seedbox somewhere in a country that has lacker laws and doing it all there, and then just use secure channels to that box to move what you want to and from it, https, sftp, etc. Routing all your traffic through a vpn is just nuts.. Paying some company X$ to protect you is nuts - better off just getting a box somewhere else and routing/doing what you want to do that is ?able there..

Your not going to run a business behind a carrier grade nat.. Get a new connection would be suggestion 1. Suggestion 2, get a vps somewhere. Run a vpn connection to that, and tunnel down any traffic you need to tunnel down into your actual location. But better yet would be to put the services the public needs to get to there in the first place. Your not going to find a "vpn" service to do what you can do way cheaper and easier with a simple vps or multiple vps all over the globe, etc.

Must've been legacy config or some such as the uninstaller doesn't clear down old files. Uninstall, manual deletion of old files from c:\Program Files\OpenVPN and a full reboot before reinstall seems to have done the trick. This can be closed but uninstaller needs work ;)

I haven't tried this myself, but it may be worth a shot. Create one user only and export the ovpn config. Save the config as user1_split.ovpn. Copy and rename the same config as user1_full.ovpn. Edit user1_full.ovpn and manually add "redirect gateway def1" (check correct syntax) You may also need to add "--route-nopull" so the server won't push other gateways and override your manually set "redirect gateway def1". See: https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway --route-nopull When used with --client or --pull, accept options pushed by server EXCEPT for routes and dhcp options like DNS servers. When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface.

Hello, Thak you for your reply. I already try this possibility but with this solution the user will not be able to connect during the day when she is not at home but in office.

I tried already before and it works. That is correct solution Thank you,

If that was me I would put the bridges on their own interface at the pfSense 1 side and create a transit network for the link between the sites. In other words, I would get the unify bridge off the LAN over there and on its own interface. Then it's a matter of making router decisions in pfSense itself instead of dealing with asymmetric routing for the hosts on the pfSense #1 LAN. But, yeah. In order to swing the routing for the two networks from one interface to the other you might need to use something like FRR/OSPF. I would not attempt that before adding the transit network described above though.

OK so that's a port forward on the OpenVPN interface. I would not NAT to the tunnel address there. I am not 100% certain that the DNS resolver even listens on the tunnel address. I would NAT to a LAN address or probably localhost (127.0.0.1) Forward both TCP and UDP. DNS can use both. But it looks like what you have should work. Pretty sure you do not need an assigned interface to do that.

I get that. But the client was also able to access vlans on different subnetd when connected to the VPN server while originating from a home vlan. That is what confused me. (As noted earlier, this does not occur if connecting to the VPN server from outside the home)

What kind of safenet token? If the authentication is out-of-band (like Duo) or something can be prepended/appended to the user's password (like an OTP) it can probably be made to work. I don't know of any way to do a second discrete password entry.

The user certificates are in the .p12 file. Try exporting with Microsoft Certificate Storage enabled. You are exporting for Linux, not Windows!

By default pfSense passes nothing into WAN. You need firewall rules to pass traffic into WAN. Even pings.

You shouldn't need to change anything. All of my setups let the client immediately reconnect. Are there any errors in the client or server logs when it fails?

@imparker Glad to hear..

Hence opened a bug - https://bugzilla.redhat.com/show_bug.cgi?id=1611812