@Derelict: You will have to make the username and password match what PIA is expecting. Might need to talk to them about it. They are the ones you are paying cash, after all. Else port more logs surrounding that. there might be something else in-play. Reenter the username/password and re-save. I guess I'll try a third time setting it up.  /sigh

;D

No, I do not see they need a TLS key. Create a CA in pfSense using the blob contained within<ca></ca> Create a certificate in pfSense using the blobs contained in the and In the OpenVPN client: Server Mode: Peer-to-Peer (SSL/TLS) Protocol: TCP Device Mode: tun Interface: WAN Server host or address: vpn.trust.zone Server port: 443 Place the correct username and password Be sure TLS authentication is unchecked Be sure the CA you created is selected in the Peer Certificate authority Be sure the certificate you created is chosen in the Client Certificate. Encryption Algorithm: AES-256-CBC Auth Digest algorithm: SHA512 (eyeroll) Be sure Don't pull routes is unchecked

On 2.4-RC i'm using the "Service watchdog" package, for some other tasks. Maybe it can restart OVPN too. /Bingo

I ended up switching to using ipsec, which I wanted to use anyway but didn't feel like working out the NAT translation. Ended up working out well. Though for some reason PFSense reports that VyOS didn't send the MODP for the ESP group even though I have it configured. Not the worst thing since the key is runs PFS, but still not ideal. Still would love to figure out why PFSense is having this routing issue. I suppose if it gets real bad I will have to convince my boss to pay for official support. Considering the thousands that we saved from not using Cisco….

Didnt realize it was that simple haha. Thanks a lot!

That would kind of be up to PIA. Then it would be up to you how you route traffic over both circuits if allowed by them.

If you are not using redirect gateway on the remote access server you need to add the 10.0.20.0 and 192.168.1.0 networks to the Local Networks on the Remote Access OpenVPN server. You also need to make sure those branches know how to route back to 10.17.0.0/24 You need to make sure all firewall rules pass the necessary traffic.

I just saw another system with a down/up openvpn earlier today. The problem there was one-way traffic. Traffic could flow from the side that showed down to the site that showed up but traffic could not flow from the site that showed up to the site that showed down. The tunnel was partially up. Pings sent across from the "down" side would go out the tunnel, be received and replied to by the other side, but would never arrive. It was a CARP VIP on the down side that the ISP was losing the MAC address for. They would accept traffic from that address but couldn't deliver traffic to it.

Unless you want inbound connections from PIA, then just remove or disable all rules on the OpenVPN tab and the PIAVPN assigned interface tab. Treat it like a WAN interface. If you do not want OPT1 to access LAN, then place a rule on OPT1 blocking traffic to destination LAN net. If you do not want LAN to access OPT1, then place a rule on LAN blocking traffic to destination OPT1 net.

Need more details. In general the trick to port forwarding into pfsense and across OpenVPN to a server on the remote side is: 1. Assign an interface on the destination side. The side with the target server on it. 2. Make sure the rules on the OpenVPN tab do NOT match the incoming, port-forwarded traffic on the destination side. Make sure the traffic is matched by the rules on the assigned interface. That gets reply-to working so reply traffic isn't routed out the default gateway on the destination side.

That's essentially what I did with some Linux laptops I had to issue at my last job. Ran a job that would check for something that should be there, if not then load openvpn. Sound logic.

There are two options. A. Create a secondary OpenVPN server and keep the two separated. B. Assign his user a static IP in the pool and create firewall rules to prevent access to your server. Under client specific overides you can add something like ifconfig-push 192.168.1.200 255.255.255.0 to assign his client that IP.

As a matter of feedback, removing and reinstall the package worked for me too.  Soooo nice to have the functionality back.

Hi Screenshot attached. When the second rule is enabled there is no internet access from the IP specified in Alias Blockpc. When the rule is disabled internet access is available. [image: Firewall_Rule.png] [image: Firewall_Rule.png_thumb]

Yep, that'll do it too :) Plus, I was mistaken, there is a route to your tunnel network (10.25.2.0/29).  However, I was surprised to see it at only a /29… you're only going to get 5 users out of that, but... maybe that's all you need.

Dude your NOT going to change the SOURCE ports of traffic to the same thing.. It DOESN"T WORK THAT WAY!!! You are completely misunderstanding what they are doing with their 10 port, or your explaining it WRONG!! If you have some application that randomly listens on some port between 1000 and 2000?  And the firewall in front of you will only forward 10 ports then your screwed.. Never going to work..

Hi! I have default gateway switching enabled but seems it doesn't work. In failover mode I don't see default route in the routing table. Squid also doesn't work with dual WAN (it use the default gateway). I had it working until recently, but for some time this configuration does not work too. Maybe these two problems have the same reason. I'm not sure. Best!