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