I've set up an OpenVPN server on a machine with a private IP address of The gateway is at, and it hands out 10.0.0.* addresses to other machines on the network. The VPN is set up with bridging. My /etc/network/interfaces file looks like this:

# Bring these interfaces up automatically
auto lo br0

# The loopback network interface
iface lo inet loopback

# The bridge connection
iface br0 inet static
    bridge_ports    eth0
    bridge_stp      on

# The primary network interface
iface eth0 inet manual
    up ifconfig $IFACE up
    up ip link set $IFACE promisc on
    down ip link set $IFACE promisc off
    down ifconfig $IFACE down

The server config file (/etc/openvpn/server.conf) looks like this:

port 1194
proto udp
dev tap0
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
ca ca.crt
cert VPNserver.crt
key VPNserver.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt

push "route"

push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
tls-auth ta.key 0
max-clients 20
user nobody
group nogroup
status openvpn-status.log
log-append  /var/log/openvpn.log
verb 3
crl-verify crl.pem

I think server-bridge and the line below it might be in need of adjustment. Is OpenVPN supposed to be creating a subnet for itself and for connecting clients? At first I was under the impression I could just have OpenVPN assign IP addresses in the same subnet as long as they were outside the router's DHCP range; now I'm not so sure.

Anyway, here are the symptoms of the current config. The client machine (which lives in a network -- you'll see this in the output to follow) is able to connect, but only the IP of the OpenVPN server is pingable and I can't browse the web. I'm connecting from a Linux CLI; here's some of the output I get which leads me to believe that routing is the problem. I've bolded the output that seems relevant to me.

Fri Jun  3 12:54:51 2011 [VPNserver] Peer Connection Initiated with [AF_INET]SERVER.PUBLIC.IP.ADDRESS:1194  
Fri Jun  3 12:54:53 2011 SENT CONTROL [VPNserver]: 'PUSH_REQUEST' (status=1)  
Fri Jun  3 12:54:53 2011 PUSH: Received control message: 'PUSH_REPLY,route,redirect-gateway def1 bypass-dhcp,route-gateway,ping 10,ping-restart 120,ifconfig'  
Fri Jun  3 12:54:53 2011 OPTIONS IMPORT: timers and/or timeouts modified  
Fri Jun  3 12:54:53 2011 OPTIONS IMPORT: --ifconfig/up options modified  
Fri Jun  3 12:54:53 2011 OPTIONS IMPORT: route options modified  
Fri Jun  3 12:54:53 2011 OPTIONS IMPORT: route-related options modified  
Fri Jun  3 12:54:53 2011 ROUTE default_gateway=  
Fri Jun  3 12:54:53 2011 TUN/TAP device tap0 opened  
Fri Jun  3 12:54:53 2011 TUN/TAP TX queue length set to 100  
Fri Jun  3 12:54:53 2011 /sbin/ifconfig tap0 netmask mtu 1500 broadcast  
Fri Jun  3 12:54:53 2011 /sbin/route add -net SERVER.PUBLIC.IP.ADDRESS netmask gw  
**SIOCADDRT: File exists  
Fri Jun  3 12:54:53 2011 ERROR: Linux route add command failed: external program exited with error status: 7**  
Fri Jun  3 12:54:53 2011 /sbin/route add -net netmask gw  
Fri Jun  3 12:54:53 2011 /sbin/route add -net netmask gw  
**Fri Jun  3 12:54:53 2011 /sbin/route add -net netmask gw
route: netmask doesn't match route address**  
Usage: route [-nNvee] [-FC] [<AF>]           List kernel routing tables  
   route [-v] [-FC] {add|del|flush} ...  Modify routing table for AF.  

   route {-h|--help} [<AF>]              Detailed usage syntax for specified AF.  
   route {-V|--version}                  Display version/author and exit.  

  -v, --verbose            be verbose  
  -n, --numeric            don't resolve names  
  -e, --extend             display other/more information  
  -F, --fib                display Forwarding Information Base (default)  
  -C, --cache              display routing cache instead of FIB  

  <AF>=Use '-A <af>' or '--<af>'; default: inet  
  List of possible address families (which support routing):  
   inet (DARPA Internet) inet6 (IPv6) ax25 (AMPR AX.25)  
   netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP)  
   x25 (CCITT X.25)  
**Fri Jun  3 12:54:53 2011 ERROR: Linux route add command failed: external program exited with error status: 4**  
Fri Jun  3 12:54:53 2011 GID set to nogroup  
Fri Jun  3 12:54:53 2011 UID set to nobody  
Fri Jun  3 12:54:53 2011 Initialization Sequence Completed  

So I guess I'm looking to:

  1. Make these errors go away
  2. Be able to access machines other than the OpenVPN server on the network
  3. Route all traffic (web browsing, etc) through the VPN
  • Can you show us your client configuration as well? – Zoredache Jun 3 '11 at 23:05

If you are bridging, then you probably shouldn't be pushing any routes.

  • If I remove these lines: push "route" push "redirect-gateway def1 bypass-dhcp" ... all the errors go away. However, I can only ping the OpenVPN server (nothing else in the network), and while I can browse the Internet, traffic is not being routed through the tunnel. (In other words, if I go to whatismyip.com, it gives me the public IP of the client rather than the server.) – pittstains Jun 4 '11 at 13:51
  • OK, so technically, you're right, @Zoredach. More detail in my own answer this question, below. – pittstains Jun 9 '11 at 11:24

OK, so technically @Zoredache is correct. My question was, "What are the proper routes to push for a bridged OpenVPN server?" and I shouldn't be pushing route (which should probably be route anyway). Removing that line solved the first part of my problem.

The second part of my problem (not being able to ping other machines on the network) was related to a detail which I failed to mention, which is that this server lives on a VMWare virtual machine. Thanks to this blog post, I discovered that "the ESXi virtual switch drops promiscuous packets by default," and I learned how to configure the VM not to do that.

I wasn't able to achieve the third goal of routing all traffic through the VPN, but I decided it wasn't crucial for this particular deployment. The comments in the default config suggest that by uncommenting push "redirect-gateway def1 bypass-dhcp" I would "configure all clients to redirect their default network gateway through the VPN, causing all IP traffic such as web browsing and and DNS lookups to go through the VPN," but when I uncommented it I couldn't get outside of the network at all.


When using a routed openvpn the interface is implied. However when using a bridged openvpn you can no longer assume anything can be implied. It should be possible to inform which ip the route flows through. Like (command line linux): ip ro add via

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.