Here's the problem I'm trying to solve.  The WiFi network is connected to a pfSense box which sends its traffic out over VPN.  The same pfSense box acts as a OpenVPN server allowing access to the LAN remotely.  The problem is that because the configuration are set to redirect-gateway, the IOS OpenVPN app setting that allows you to select which network to use OpenVPN doesn't work properly.  What happens when you select "Cellular Only" is that IOS won't automatically switch back to the WiFi network.  If I take away the redirect-gateway, this problem goes away but now the IOS traffic goes out via 4G without passing through the VPN.  Anyone encounter this?

You have to add the interface addresses with /32 to the main page of OSPF settings, and mark them as do not redistribute and accept filter. I've made that quite a bit better in frr but it's not out for 2.3.4 users just yet. Soon, though.

@Derelict: If enabling the server has any effect on existing traffic, it sounds like you have chosen a subnet for the tunnel network that conflicts with something. Usually that means the server won't install the route because it already exists. Maybe you did something different. What did you use for the tunnel network? I used 192.168.3.0/24 for my tunnel network.  It's all working now after setting up the interface and adjusting NAT rules.  Thanks for that.  Now I just need to figure out if it's possible to use a different route when I'm on my home WiFi network.  I can't use the OpenVPN setting that says "Cellular Only" as I'm using redirect-gateway and that doesn't allow the iPhone to switch back to WiFi when it's available.

@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.