Virtual Ethernet Tunneling is a hybrid between software bridging and IPSec tunneling. OpenBSD 2.6 and later support this feature but there have been significant changes with respect to configuration in several releases. OpenBSD 2.9's implementation does not work with these examples. The setup can be described as two software bridges with one of the interfaces on each bridge tied together with an IPSec tunnel. This configuration allows a subnet to be bridged between any sized IP network securely and transparently. VETs can be configured using a three step process: configuring the IPSec policy and flows, binding an IPSec policy and flows to a virtual interface, and adding that virtual interface into a bridge group with a real Ethernet interface. Configuring the IPSec policy (Security Associations) has gone under some interface changes since it was first introduced. The examples I will provide static SAs using IPSECADM on OpenBSD 2.8. Once a policy and flow are created it is time to bind these to a virtual interface. OpenBSD reserves enc0 for all IPSec traffic inbound without a policy associated with it, this means you can't use it for your tunnel. The following example will describe how to bind our policy to the enc1 interface. The last step is quite familiar if you've done bridging. Place the enc1 interface in a bridge group with your Ethernet interface and bring it up. At this point we can see both the enc1 interface is up and bridge0 is up by running ifconfig -a. Some common pitfalls when configuring VETs is the apparent loss of network when configuring the tunnel remotely. The best way to bring up the tunnel is out-of-band i.e. serial, but that is not always possible. Another pitfall is an attempt to put both interfaces on the same network or even to use a single interface; both configurations will cause the kernel to panic or other undesirable results.

Each host must be configured with complimentary SAs and flows for IPSec to work correctly. SPIs (Security Payload Index) is just a key to pass over the wire so the kernel can lookup the correct SA.

  hostA# ipsecadm new esp -spi 1001 -src 24.161.76.7 -dst 129.21.111.215 -forcetunnel -enc blf -auth sha1 -key a3f87876d0767177b921df5707f6a5835d480b54 -authkey a3f87876d0767177b921df5707f6a5835d480b54

  hostA# ipsecadm new esp -spi 1000 -dst 24.161.76.7 -src 129.21.111.215 -forcetunnel -enc blf -auth sha1 -key a3f87876d0767177b921df5707f6a5835d480b54 -authkey a3f87876d0767177b921df5707f6a5835d480b54

  hostA# ipsecadm flow -dst 129.21.111.215 -proto esp -addr 24.161.76.7 255.255.255.255 129.21.111.215 255.255.255.255 -require -out -src 24.161.76.7

  hostB# ipsecadm new esp -spi 1000 -src 129.21.111.215 -dst 24.161.76.7 -forcetunnel -enc blf -auth sha1 -key a3f87876d0767177b921df5707f6a5835d480b54 -authkey a3f87876d0767177b921df5707f6a5835d480b54

  hostB# ipsecadm new esp -spi 1001 -dst 129.21.111.215 -src 24.161.76.7 -forcetunnel -enc blf -auth sha1 -key a3f87876d0767177b921df5707f6a5835d480b54 -authkey a3f87876d0767177b921df5707f6a5835d480b54

  hostB# ipdecadm flow -proto esp -dst 24.161.76.7 -spi 1000 -addr 129.21.111.215 255.255.255.255 24.161.76.7 255.255.255.255

  The second step is to assign your virtual interface, enc1, to a SA. The format IP/SPI/Protocol is used to bind SAs. SPI(Security Payload Index) was assigned earlier using ipsecadm and the protocol ID is 50 when using ESP.

 hostA# ifconfig enc1 dstsa 129.21.111.215/1001/50

 hostA# ifconfig enc1 srcsa 24.161.76.170/1000/50

 hostA# ifconfig enc1 up

 This is followed by adding both enc1 the real Ethernet interface, on the network you want to bridge, to a bridge group and bringing the bridge up.

 hostA# brconfig bridge0 add enc1 add fxp0 up