I'm using OpenVPN at work to support an environment that must be isolated to comply with audit requirements. Therefore, we want the redirect-gateway functionality without the def1 option, which would allow existing connections to persist, creating potential tunnels to the secured network. We are allowing bypass-dhcp to allow users to remain connected beyond their DHCP lease time. However, something is completely defeating the redirect-gateway feature! :cry: It doesn't always happen, but it's fairly common to see a connected VPN client that has access both to the secured network and to the entire corporate network. To facilitate remote connectivity, we often run the OpenVPN GUI on a Windows VM, and I have seen this on both VMware Workstation (with a NAT network configuration) and Oracle VirtualBox (with a bridged network configuration). The main issue seems to be the management of the default route, which sometimes has a duplicate like the following (from VMware Workstation & NAT using 192.168.174.0/24): [code]IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 172.27.1.13 172.27.1.14 30 0.0.0.0 0.0.0.0 192.168.174.2 192.168.174.128 10 ...[/code] The server config: [code]port 1194 proto udp dev tun ca cacert.pem cert myvpn.crt key myvpn.key # This file should be kept secret dh dh2048.pem server 172.27.1.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 172.27.0.0 255.255.255.0" push "route 172.27.2.0 255.255.255.0" push "route 172.27.3.0 255.255.255.0" push "route 172.27.4.0 255.255.255.0" push "redirect-gateway bypass-dhcp" keepalive 10 120 user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3 plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so login crl-verify crl.pem[/code] A client config: [code]client dev tun proto udp remote myvpn 1194 resolv-retry infinite nobind persist-key persist-tun ca cacert.pem cert user.crt key user.key ns-cert-type server verb 3 auth-user-pass[/code] I suspect the OpenVPN GUI is to blame, somehow reasserting the original default route or not tidying up during reconnections. I'm trying to figure out if there's a pattern to the behavior, but I thought I should submit it before digging in case it's a well-understood phenomenon.

[Resolved] Defeated redirect-gateway from extra def route

symphero

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

maikcat

please use redirect-gateway def1.

Michael.

symphero

Michael,

What I've found when using redirect-gateway def1 is that the default route is not deleted (by design), and so any pre-existing connections remain open. It seems like this is only a partial solution for a non-split-tunnel VPN, because I could do something like this on my OpenVPN client system:

$ ssh remotebox -R 22:myvpnserver:22

Once the VPN connection is up, I would be able to make a port-forwarded connection from remotebox directly to myvpnserver, precisely what I should not be able to do. (I believe I validated those steps...but it was a while ago so I don't recall exactly how far I pursued it.)

I haven't noticed this issue happening recently. If it were, then the def1 option would be better than having everything open. But it would be ideal to have redirect-gateway work correctly without def1.