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.
M-
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.
602-324-4776
www.iprocorp.com
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: 10.0.0.0/16
(subnet mask: 255.255.0.0)
gateway address: 10.0.0.1
(this is the address of the private side of the Dachstein firewall)
VPN server address: 10.0.12.1
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 10.0.12.2 -
10.0.12.255. 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
255.255.0.0, the addresses of our internal DNS servers and no gateway
address.
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
address 10.0.12.1
netmask 255.255.0.0
broadcast 10.0.255.255
gateway 10.0.0.1
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
tls-server
dh dh2048.pem
ca certauth.crt
cert server.crt
key server.key
crl-verify revoked.pem
key-method 2
ping 10
ping-restart 120
comp-lzo
up /etc/openvpn/up.script
up-restart
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
configuration.
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 64.2.118.81 1199
dev tap
dev-node vpn
disable-occ
up-delay
tun-mtu 1500
tun-mtu-extra 32
mssfix
fragment 1450
key-method 2
tls-client
ca certauth.crt
cert client.crt
key client.key
keepalive 10 60
comp-lzo
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
automatically.
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
ISP via DHCP.
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 (64.2.118.81). 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.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
