I had quite a bit of trouble getting OpenVPN to start after networking is up, but before the the bridge is setup so that the tap0 device, which is created by OpenVPN can be added to the bridge.

The solution is simpler : let the tap0 be automatically created and added to the bridge by Gentoo Linux, then start OpenVPN with a config file instructing to use the already created tap0 device.

This post shows the configuration snippets to get things started in the right order on Gentoo.

Here is the /etc/conf.d/net file :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d.  To create a more complete configuration,
# please review /etc/conf.d/net.example and save your configuration
# in /etc/conf.d/net (this file :]!).
 
config_eth0=( "null" )
 
tuntap_tap0="tap"
config_tap0="null"
 
bridge_br0=( "eth0 tap0" )
brctl_br0=( "setfd 0" "sethello 10" "stp on" )
config_br0=( "dhcp" )
 
depend_br0() {
        need net.eth0 net.tap0
}

This files sets up eth0 (null configuration, so that it doesn’t use DHCP to get configured), creates tap0 device that will be used by OpenVPN and create the bridge br0 with those 2 eth0 and tap0 devices. The depend part ensures that when the bridge will be created, both eth0 and tap0 will have been configured.

You have to link this file to /etc/init.d as net.eth0, net.tap0 and net.br0 and add those to the default runlevel like so :

1
2
3
4
5
6
7
8
9
10

spaghetti init.d # cd /etc/init.d/
spaghetti init.d # ln -s /etc/conf.d/net net.eth0
spaghetti init.d # ln -s /etc/conf.d/net net.tap0
spaghetti init.d # ln -s /etc/conf.d/net net.br0
spaghetti init.d # rc-update add net.eth0 default
 * net.eth0 added to runlevel default
spaghetti init.d # rc-update add net.tap0 default
 * net.tap0 added to runlevel default
spaghetti init.d # rc-update add net.br0 default
 * net.br0 added to runlevel default

Finally add OpenVPN to the default runlevel as well :

1
2

spaghetti init.d # rc-update add openvpn default
 * openvpn added to runlevel default

That’s it. When you’ll restart your server, the devices will be configured in the proper order, and OpenVPN will be started and will use the automatically created tap0 device.

Gentoo + OpenVPN : getting things started in the correct order is a post from: Tech@Sakana - A sysadmin's blog

This post provided a sample script to setup a bridge suitable to use with all of the named virtualization softwares.

Here is the script I use for setting up the networking of a VM :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#! /bin/sh
 
# creating tap0 (a TAP device) and setting owner as the non-privileged user who
# will run VirtualBox
tunctl -u kattoo
 
# creating the bridge
brctl addbr br0
 
# stopping the initial networking
/etc/init.d/net.eth0 stop
 
# bringing up physical and virtual network interfaces
ifconfig tap0 up
ifconfig eth0 up
ifconfig br0 up
 
# connecting the TAP device and the physical NIC onto the bridge
brctl addif br0 tap0
brctl addif br0 eth0
 
# starting the bridge
/etc/init.d/net.br0 start

As you can see, this is pretty simple and straightforward, and there is much room for improvement

A TAP device is a level 2 (think ethernet) virtual network interface which has one side connected to a process (in our case this will be VirtualBox or any other virtualization software such as Xen, QEMU, KVM …) and the other side is connected to the hosting Linux Kernel. In our case that end will be plugged in the network bridge so that every packet entering the bridge will be forwarded to the VM as well (and the other way round too).

This example is made with Gentoo Linux in mind, so you may have to adapt a bit for your own Linux distribution.

If you use VirtualBox, you can then set the network parameters for your VM as follow :

VirtualBox parameters for a VM using bridged networking

Should you have any question or improvement to suggest, feel free to hit the comments !

Linux : Configuring a network bridge for your Virtual Machines is a post from: Tech@Sakana - A sysadmin's blog

photo credit: saschaaa

This posts gives a short intro about VLAN and a simple configuration sample on a DELL PowerConnect 5224 switch with an OpenBSD machine.

VLANs

VLANs are a common way to gather ports of multiple connected network switches in groups (VLANs), and isolate thoses different groups as if they were on different physical networks.

For this to work, Ethernet frames (as standardized by the IEEE 802.3 standard) are basically extended with an extra field specifying the VLAN identifier (this is standardized by the IEEE 802.1q standard). A packet with this extra field is said to be “tagged”.

Provided with this information, a 802.1q aware switch can deliver ethernet packets only to the VLAN member ports. When this packet leaves the switch by a port, the switch has to decide whether the frame should be sent as 802.1q (to a 802.1q aware equipment) or as 802.3 (to a non-802.1q aware equipment) by “untagging” the packet.

Likewise, when a packet reaches the switch, either it is already tagged and the switch will propagate it to the matching VLAN, or it is not and the switch will tag it with the port default VLAN identifier (known as the “PVID”).

Let’s see how to setup VLANs on a Dell PowerConnect 5224 switch and an OpenBSD machine.

Sample configuration

For this test, we have a DELL PowerConnect 5224 network switch and an OpenBSD 4.2 machine. Both of those equipments are VLAN aware.

Switch

Here are the configuration blocks regarding the VLAN setup :

vlan database
vlan 1 name DefaultVlan media ethernet state active
vlan 2 name aSampleVLAN media ethernet state active
!
interface ethernet 1/1
description OpenBSD
switchport allowed vlan add 1 untagged
switchport native vlan 1
switchport allowed vlan add 2 tagged

We basically create a VLAN “aSampleVLAN” with and the identifier 2 and setup the port 1 of the switch so that packets sent to the VLAN 2 will be sent out on this port too as tagged packet (meaning the packets will be sent as 802.1q packets, hence including the VLAN id).

The “native vlan 1″ sets the PVID, meaning that untagged packets entering the switch by the port 1 will be tagged as part of the VLAN 1.

That’s it for the switch setup.

Server

OpenBSD has a vlan(4) pseudo-device which takes care of VLANs. Once configured, a vlan pseudo-device will act just like a normal network interface which would be plugged in a VLAN.

The setup is really easy.

1. Bring up the physical network interface which is connected to the switch:
   # ifconfig xl0 up
2. Create and configure the vlan pseudo-device :
   

   # ifconfig vlan2 create
   # ifconfig vlan2 vlan 2 vlandev xl0

3. Setup the IP parameters of the vlan interface:
   # ifconfig vlan2 inet 10.253.21.102 netmask 255.255.255.0

You can make this persistent over the next reboots by configuring the /etc/hostname.* files as follow :

$ cat /etc/hostname.xl0
up

$ cat /etc/hostname.vlan2
inet 10.10.10.100 255.255.255.0 10.10.10.255 vlandev xl0 description "Interface in VLAN 2"

That’s pretty much it. You can bring up as many vlan interfaces as you want, for example if you need to have a server share resources on multiple VLAN or if you want to route packets between VLANs but you have more VLANs than the number of physical network interfaces/switch ports you want to use…

VLAN + OpenBSD : a simple configuration is a post from: Tech@Sakana - A sysadmin's blog

As far as the 5224 is concerned, you mostly have to hold Ctrl-F from the power-on till the end of the boot of the switch, which will bring the “reset to factory ?” question and solve the problem of the lost password.

The User Guide for the 5224 is available online.

Dell PowerConnect switches – Password recovery procedure is a post from: Tech@Sakana - A sysadmin's blog

The named.conf allows those updates with this config directive in the zone config block :

allow-update {mynet; };

Then you can update your DNS with the nsupdate tool with a syntax along the following lines :

spaghetti:~# nsupdate
> server 192.168.0.1
> update delete spaghetti.domain.name A
> update add spaghetti.domain.name 8000 A 192.168.0.103
> send
> quit

I was then looking for a place to hook a code snippet doing that update after an update via DHCP and I found the answer in A dynamic dns update client on Debian with dhcp3-client (many thanks dude !).

Here is the drill down :

1. install the dhcp3-client package (apt-get install dhcp3-client ): this version has easy to use hooks before and after querying the DHCP server to get network config
2. you can drop a script which will automate the nsupdate in “/etc/dhcp3/dhclient-enter-hooks.d” and it will get run right after network configuration (see the sample debug script for the variable which are available upon script execution, such as $new_ip_address)

Debian : update a dynamic DNS is a post from: Tech@Sakana - A sysadmin's blog

To see multicast group memberships in Windows XP, you can use netsh :

U:>netsh interface ip show joins
Interface Addr   Multicast Group
---------------  ---------------
192.168.139.1    224.0.0.1
192.168.137.1    224.0.0.1
192.168.136.1    224.0.0.1

Solaris (and probably other Unixen as well)

In Solaris, the netstat command can be used :

$ netstat -g
Group Memberships: IPv4
Interface Group                RefCnt
--------- -------------------- ------
lo0       224.0.0.1                 1
eri0      224.0.0.1                 1
$

Multicast : Listing group memberships is a post from: Tech@Sakana - A sysadmin's blog

This makes it easy to setup more than 1 ip address on a network card, and hence to make virtual servers.

Solaris 10: “logical-units” for network cards (NIC) is a post from: Tech@Sakana - A sysadmin's blog

A bridge is a network device used to connect two or more network segments. You can achieve this easily on OpenBSD with the following commands :

# echo 'up' > /etc/hostname.if0
# echo 'up' > /etc/hostname.if1
# echo  'add if0 add if1 up'  > /etc/bridgename.bridge0

This will setup the two interfaces if0 and if1 (replace with your own, like rl0, em0, etc etc) and add them into the bridge0.

Then you need to enable ip forwarding so that IP packets will pass from one interface to the others as needed. You do that by editing the file /etc/sysctl.conf and uncommenting the line which reads :

 #net.inet.ip.forwarding=1

This bridge is IP-less, which means it is “harder” to attack. You can still filter at MAC level and at IP level through PF (the firewall of OpenBSD).

Tested on OpenBSD 3.9

Man pages :

• hostname.if(5)
• brconfig(8)
• ifconfig(8)
• sysctl.conf(5)

OpenBSD : Creating a transparent bridge is a post from: Tech@Sakana - A sysadmin's blog

ftp somehost
ftp> put “| dd if=/dev/zero bs=100000 count=100″ /dev/null
200 PORT command successful.
150 ASCII data connection for /dev/null (192.168.0.1,32953).
100+0 records in
100+0 records out
226 Transfer complete.
local: | dd if=/dev/zero bs=100000 count=100 remote: /dev/null
10000000 bytes sent in 2.9 seconds (3388.52 Kbytes/s)

This will generate a stream of bytes from one host to another and give you the data rate at the end

Estimating network throughput / bandwidth / performance with FTP is a post from: Tech@Sakana - A sysadmin's blog

If you do this with Apache/mod_proxy, that means that you have to use the mod_proxy_connect and allow the CONNECT method.

Few pointers :

• CONNECT method
• Apache mod_proxy_connect

Proxying HTTPS throught Apache/mod_proxy is a post from: Tech@Sakana - A sysadmin's blog