[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

RE: [Openvpn-users] RE: Re: MTU questions

  • Subject: RE: [Openvpn-users] RE: Re: MTU questions
  • From: "Brent Gardner" <bgardner@xxxxxxxxxxxx>
  • Date: Fri, 10 Dec 2004 17:04:28 -0700
  • Importance: Normal

On Friday, 10 December 2004, M Lu wrote:

> Hi Brent,
> When you are working on bridging, could you explain me a 
> little bit and a 
> sample config is great if possible. I am really interested in 
> this kind of 
> setup.
> Thanks a lot.


This is the configuration I am working with.  So far, it is working 
very well for me.  I hope that this humble effort at documentation 
helps you.  I will copy this to both OpenVPN-users and Leaf-user in 
case it might help someone else.  I apologize in advance if it is 
regarded as noise.  I've been using LEAF for a few years now but I'm 
fairly new to OpenVPN and I'm mostly a Windows admin so if there are 
any errors I hope someone will point them out.

Brent Gardner
Network Administrator
IPRO Tech, Inc.

My private network sits behind a Dachstein firewall.  On the Dachstein 
box I open UDP port 1194 on the external interface and forward it to 
UDP port 1194 on the VPN server on the private network.

My VPN server is a machine on the private network, a peer to all the 
other hosts on the network.  It runs Bering-uClibc v2.2.  The machine 
has only one physical NIC.

network address:
(subnet mask:

gateway address:
(this is the address of the private side of the Dachstein firewall)

VPN server address:

Since the VPN operates in bridge mode I've set things up so that VPN 
clients are assigned IP addresses by the same DHCP server that serves 
the private network.  All DHCP assignments are by reservation only.  
Addresses assigned to VPN clients are in the range -  There's only about 50 seats on the private network so 
there is no subnetting but I have grouped hosts into certain IP 
address ranges based on their purpose to make it easier to see 
anomalies in the logs.  VPN clients are also assigned a subnet mask of, the addresses of our internal DNS servers and no gateway 

Since I'm still testing this system I removed the shorewall firewall 
from the VPN machine to reduce complexity.

Here's my /etc/network/interfaces file from the VPN server.  
Everything from the stock file is commented out except for the 
following lines:

  auto lo
  iface lo inet loopback

  auto br0
  iface br0 inet static
        bridge_ports eth0

Note that eth0 does not get configured.  Rather, eth0 is made a part 
of bridge br0, and br0 gets configured with IP address information 
valid for the physical network on which the VPN server resides, 
including the gateway.

Also note that at this point tap0 is not added to the bridge.  Because 
the bridge is initialized before OpenVPN tap0 does not yet exist.

Here's my etc/openvpn/openvpn.conf from the server:

  lport 1194
  proto udp
  dev tap0

  tun-mtu 1500
  tun-mtu-extra 32
  mssfix 1450
  fragment 1450

  dh dh2048.pem
  ca certauth.crt
  cert server.crt
  key server.key
  crl-verify revoked.pem
  key-method 2

  ping 10
  ping-restart 120


  up /etc/openvpn/up.script

  verb 4
  mute 10

Please keep in mind that I have just upgraded the server from OpenVPN 
v1.6 to v2.0rc1 (thanks again to Charles Duffy).  Some of the options 
above are no longer necessary but I haven't had time to fine-tune the 

When OpenVPN runs against this .conf file it creates the virtual 
interface tap0, but there are no commands native to OpenVPN to cause 
it to make tap0 part of a bridge.  If a client tries to authenticate 
with the VPN server at this point they will be able to do so, but 
after that they won't be able to do anything useful because OpenVPN 
is not yet connected to any networks.  Standard Linux commands must be 
used to add tap0 to a bridge.

Here is the contents of /etc/openvpn/up.script:

  brctl addif br0 tap0
  ip link set tap0 up

These commands add tap0 to the bridge and bring up the interface.  Now 
if a client connects they will be bridged onto the private network, 
the same as if they had plugged into one of my switches, just slower 
and farther away;)  Remember that the script must be made executable.  
I did that by running 'chmod 755 up.script'

Here is the client-side .conf file:

  remote 1199
  dev tap
  dev-node vpn

  tun-mtu 1500
  tun-mtu-extra 32
  fragment 1450

  key-method 2
  ca certauth.crt
  cert client.crt
  key client.key

  keepalive 10 60


  verb 4
  mute 5

Again, I've just upgraded the server from OpenVPN v1.6 so some of the 
above options may no longer be needed.  I haven't finished tweaking.

My clients run OpenVPN v2.0rc1 with Mathias Sundman's wonderful GUI 
v1.0-beta26 on Windows 2000 or XP.  I renamed the TAP-Win32 device to 
'vpn' to match the 'dev-node vpn' line in the .conf file above and 
manually set the MAC address.  I set TCP/IP properties for the 
connection to obtain IP address and DNS server information 

The clients of course will all have some kind of network connection 
which will allow them to access the Internet.  This will be 
represented on their local machine by a dial-up connection, a PPP-OE 
connection, a wireless connection, or a local area connection.  
Regardless, that connection must be assigned IP address, subnet mask, 
gateway address, and DNS server information that is valid for the 
physical (or wireless) network to which they are connected.  Most 
likely this information will be provided to the client PC by their 

When OpenVPN is run against this .conf file it enables the TAP-Win32 
virtual interface which has been named 'vpn', traverses the Internet 
via whatever connection is available and tries to connect to UDP port 
1194 on my Dachstein firewall (  The firewall forwards 
the traffic to port 1194 on the VPN server where, assuming successful 
authentication, it connects to the virtual interface tap0 which is 
bridged with eth0 which is physically connected to the private network.

At this point Windows thinks the connection named 'vpn' has just been 
enabled (which it has).  Since the connection is configured to get IP 
address information via DHCP Windows will now initiate the DHCP lease 
process.  All of the DHCP-related packets will be encrypted by OpenVPN 
running on the client and sent out over the Internet, through my 
firewall, to my VPN server, where OpenVPN running on the server will 
decrypt the packets and copy them out onto my private network.  The 
DHCP server will respond to the packets oblivious to the fact that the 
client to which it is granting a lease actually resides on the other 
side of the country.

When the lease process is complete the client PC will have at least 
two active network connections, one to their local ISP including a 
gateway address, and another to the private network which does not 
have a gateway address.  This prevents confusion in the client-side 
routing table and prevents traffic intended for the Internet from 
being routed needlessly through the VPN connection and onto the 
private network.

In regards to client-side personal firewalls:
I don't recall that I had to do anything special to get OpenVPN to 
work with the default settings of Windows XP SP2's firewall, but it 
works.  I also have it working on machines running ZoneAlarm, where I 
had to assign the TAP-Win32 adapter to the trusted zone and add the 
IP address assigned to the 'vpn' connection to the trusted zone.

My to-do list: add shorewall back into the mix, throttle the VPN to 
prevent saturation of our T1.

Openvpn-users mailing list