Some_notes_on_openvpn,_bridging_and_freebsd

title: Some notes on OpenVPN, bridging and FreeBSD date: 2005-05-01 10:55:18

• (This is OpenVPN version 1.6, btw.)
• Bridging can be done pretty easily. Use the device tap0 directive in your config file, then set these sysctl variables: net.link.ether.bridge_cfg: dc2,tap0 -> dc2,tap0 net.link.ether.bridge: 0 -> 1

This assumes, of course, that dc2 is the inside interface you want bridged over the VPN. * If OpenVPN exits for some reason, you need to turn bridging off by setting the net.link.ether.bridge sysctl to 0 before starting OpenVPN again. Near as I can figure, this is because the new tap0 interface is different from the old one, even though it has the same name, because it was created by a different PID. * No problems getting OpenVPN to run under djb's daemontools so far, as long as I toggle bridging as part of the startup script. * On one machine, the inside interface being bridged was sis0, an onboard ethernet interface. This led to worlds of hurt: if OpenVPN went down then started again, everything would look good but the bridge wouldn't work -- I could no longer ping that interface from the other side of the bridge. Furthermore, trying to ping from that machine to the other side of the bridge got me this error: ping: sendto: no buffer space available Googling for this turned up many, many references to this problem. It seems to be a long-standing bug in FreeBSD, present to this day (!) and with no fix (!!), that may or may not have something to do with particular ethernet drivers. I thought I would have to install Linux and rebuild it -- this was on Friday afternoon, and the VPN is meant to be set up this Monday -- but I took a chance and bought some different ethernet cards (Linksys LNE100TX-CA ver 5.1, which in FreeBSD show up as dc(4) devices; thank you, London Drugs) and so far I haven't seen the problem again. * The machine with the problematic sis0 interface is a 2GHz P4; the other side is a 3GHz P4. Both have 512MB of RAM. If I restart OpenVPN on the slower machine, pings take about 30-40 seconds to start working again; if I restart the faster side, it's almost instantaneous. (Both sides know the address of the other side, and both are set to re-initiate the connection if it goes down.) * For testing, the setup is something like this: Client A -- Slow machine -- (OpenVPN here) -- Fast machine -- Client B

Copying a big-ass file from Client B to Fast Machine takes 1 minute; if Client A copies the same file to itself, it takes about 1 minute 20 seconds; if Slow Machine copies the same file to itself, it takes 1 minute 40 seconds; and finally, if Client B copies that same file from Slow Machine to itself, it takes 1 minute 10 seconds. (Copying is done by scp in all cases; Client A and Slow Machine are connected by a crossover cable, as is Slow Machine and Fast Machine; Fast Machine and Client B are connected through by a switch or two.)