AI3 logo     Tunnelling Ethernet over IP for FreeBSD
AI3 teammAI3 eventsAI3 researchAI3 publicationsAI3 reports

This document is largely based upon the work done by Husni.

It only provides some enhancements regarding automatic start-up and some fine details.

CSIM Logo WelcomeCourses
Faculty, Student, Staff
Projects and reports
Conferences, workshop and seminars
Laboratories and reasearch facilities
Information related to CSIM
Information non-related to CSIM
Address, map, phone, etc.

This document explains the configurations and procedures to enable Ethernet over IP tunneling on FreeBSD. I succesfully performed the test on a FreeBSD 4.10-RELEASE. I make no claim that it will work on other releases. I also tested it on FreeBSD 4.7-RELEASE.


The objective of this set-up is to join two Ethernet segments S1 and S2 through the Internet and bridges, as if S1 and S2 were one single Ethernet segment.

The situation can arrise where both segments are too far away to be connected by a cable (or even optic fiber). Segments need not to be connected to Internet, though an Internet connection should be available at close distance.

The solution consist of encapsulating Ethernet frames into IP packets, those packets being transmitted through Internet and decapsulated at the other end. This kind of implementation is called tunnelling Ethernet over IP.

Tunnelling Ethernet over IP

In this setting, we use a software bridge that runs on FreeBSD.

Configuration Environment

Operating system: FreeBSD 4.10
Modules (default modules)


In the following part, we will use the following conventions:

  1. Prepare two FreeBSD boxes, vtun-server and vtun-client.
    Assign an IP to the outside interface of the machines. Being the server, vtun-server will probably have a static IP, while vtun-client can do with a dynamic IP.
    It is a good idea to install sudo from the security packages (from CD).
    For those who like it, install emacs from the editor packages (from CD).
    The file /etc/rc.conf will look like:
      inetd_enable="NO" sendmail_enable="NONE" sshd_enable="YES" usbd_enable="NO" #kern_securelevel="2" kern_securelevel_enable="NO" syslogd_flags="-ss" # Flags to syslogd (if enabled). ifconfig_xl0="inet netmask" defaultrouter="" # cs router ifconfig_xl1="up" hostname=""  
    on vtun-server

      sshd_enable="YES" usbd_enable="NO" sendmail_enable="NONE" inetd_enable="NO" ifconfig_xl0="DHCP" ifconfig_xl1="up" hostname="" #kern_securelevel="2" kern_securelevel_enable="NO" syslogd_flags="-ss" # Flags to syslogd (if enabled).  
    on vtun-client

    Note that:


  2. Install vtun on both machines, from the ports collection.
    cd /usr/ports/net/vtun
    make && make install
    To save some network bandwidth, it is a good practice to install vtun on one machine first, then to copy /usr/ports/distfiles from that machine to the other before making vtun. That way, the distributions will not be downloaded again from the Internet.


  3. Edit vtun configuration on the machines.
    Comment some lines of /usr/local/etc/vtund.conf in the lion session part. The differences would be like below:
      vtun-server%diff vtund.conf vtund.conf.orig 304c304 < # ifconfig "%% netmask"; ---<br> > ifconfig "%% netmask"; 307c307 < # route "add -net netmask gw"; --- > route "add -net netmask gw"; 310c310 < # firewall "-A forward -s -d -j MASQ"; --- > firewall "-A forward -s -d -j MASQ"; 321c321 < # firewall "-D forward -s -d -j MASQ"; --- > firewall "-D forward -s -d -j MASQ";  
    The modifications of file /usr/local/etc/vtund.conf

    On vtun-server modify line 423, change the IP address that will be used by the tunnel end to avoid duplication of IP address. The IP address should read

      423c423 < ifconfig "%% netmask"; ---<br> > ifconfig "%% netmask";  
    The modifications of file /usr/local/etc/vtund.conf on vtun-server


  4. Configure the boot loader to automatically load the necessary modules at boot time.
    Once the kernel has been set into a secure mode, some modules will not load anymore, so it is safe to load them since the boot time.
    On both machines, edit /boot/loader.conf to look like:
      # -- sysinstall generated deltas -- # userconfig_script_load="YES" netgraph_load="YES" if_tap_load="YES" ng_ether_load="YES" ng_bridge_load="YES" ng_socket_load="YES"  
    The /boot/loader.conf file


  5. Install the netgraph bridge on both machines.
    cd /etc
    cp /usr/share/examples/netgrap/ether.bridge .
    chmod u+x ether.bridge
    Then edit the file /etc/ether.bridge to include the lines:
      BRIDGE_IFACES="tap1 xl1" LOCAL_IFACE="xl1"  
    The modifications of file /etc/ether.bridge


  6. Install the starter for /etc/ether.bridge on both machines.
    The netgraph bridge can only be started when the interface tap1 is up. And the interface tap1 comes up only when a vtun connection has been established. To avoid manual starting of netgraph bridge the following script will test for the interface tap1 and then only start the bridge.
    Copy that script in /etc/start-bridge, make it executable:
    chmod u+x /etc/start-bridge
      #!/bin/sh res=`/sbin/ifconfig tap1 2>&1`; while [ "$res" = "ifconfig: interface tap1 does not exist" ]; do # echo tap1 is down res=`/sbin/ifconfig tap1 2>&1`; sleep 1 done # echo $res #echo tap1 is up /etc/ether.bridge start /sbin/sysctl kern.securelevel=2  
    The script /etc/start-bridge

    Note that this script will also put the kernel in its higher security mode. It is valid because at that point the tunnel is up and working.


  7. Edit the /etc/rc.local on both machines.
    On vtun-server it will start vtun in server mode and wait for connections, it will also initiate the netgraph bridge:
      /usr/local/sbin/vtund -f /usr/local/etc/vtund.conf -s /etc/start-bridge &  
    The file /etc/rc.local on vtun-server

    On vtun-client it connects the the vtun server mode and initiates the netgraph bridge:

      /usr/local/sbin/vtund -p -f /usr/local/etc/vtund.conf lion /etc/start-bridge &  
    The file /etc/rc.local on vtun-client

    Note we use the option -p so vtun client automatically reconnects to the server, whenever the server goes down or the connectivity is lost. This option allows to start the client before the server; the connection will be made as soon as the server is ready and visible. is the IP address of vtun-server.


  8. Reboot both machines.
    Once all the cables are connected, the tunnel should be established automatically.


  9. Make sure the tunnel is connected.
      vtun-server<on>45: ifconfig tap1 tap1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet netmask 0xffffff00 broadcast inet6 fe80::2bd:85ff:fe02:1%tap1 prefixlen 64 scopeid 0x8 ether 00:bd:85:02:00:01 Opened by PID 116 vtun-server<on>46: netstat -a |grep ESTABLISHED tcp4 0 0 ESTABLISHED vtun-server<on>47: grep promiscuous /var/log/messages Aug 6 13:23:46 vtun-server /kernel: tap1: promiscuous mode enabled Aug 6 13:23:46 vtun-server /kernel: xl1: promiscuous mode enabled vtun-server<on>48: sysctl -a|grep secure kern.securelevel: 2 vtun-server<on>49: ps auwx|grep vtun root 116 0.0 2.3 2128 1376 ?? S< 4:54PM 0:15.17 vtund: lion ether tap1 (vtund) root 97 0.0 1.9 2128 1096 ?? Is 4:54PM 0:00.00 vtund: waiting for connections on port 5000 (vtund)  
    Some tests to be sure the tunnel is working



  10. Check that packets are crossing the tunnel.
    To do that, we attach one end of the tunnel to the segment it should tunnel and we check that we see some traffic at the other end of the tunnel.
    In our example (see below) we attached the inside interface of vtun-server to the hub H1, then on vtun-client, we check that we receive packed on the interface xl1:
      vtun-client<on>37: sudo tcpdump -i xl0 Password: tcpdump: WARNING: xl0: no IPv4 address assigned tcpdump: listening on xl1 13:02:29.936925 > udp 1408 13:02:29.964519 > udp 1408 13:02:29.982184 > udp 1408 13:02:30.013232 > udp 1408 13:02:30.028988 > udp 1408 13:02:30.053034 > udp 1408 13:02:30.078648 > udp 1408  
    Check the tunnel with tcpdump on vtun-client


  11. Setting up security.
    Security was not considered in this framework, but IP firewall should be used to restrict access to the vtun server. Similarily, access to the vtun client should be restricted. Lastly, encryption shold be enabled on vtun tunnel.

Setting for the workshop

Tunnel topology for SOI Asia workshop

The tunnel is established between the hubs H1 and H2. H1 is directly connected to the UDLR receiver Sony Box, while H2 is in the classroom. The machine connected to H2 gets a dynamic IP address so it becomes the vtun client, while the machine connected to H1 gets a static IP and is configured as vtun-server.

Change since Frebruary 2003 setting is with the outside interface of vtun-server. It is not connected to AI3 subnet anymore, but directly to the border of AI3 and AIT AS's. That way we save one hop (and one IP from AI3 subnet).

CSIM home pageWMailAccount managementCSIM LibraryNetwork test toolsSearch CSIM directories
Contact us: Olivier Nicole AI3    CSIM    SET    AIT Last update: Aug 2004