This document will explain howto set up an IPSec encrypted GRE tunnel on OpenBSD. In the document, both end points are OpenBSD 4.1 systems, however it should be fairly straight forward to implement on other systems.

To start, I would advise disabling pf on gre0 and enc0 until you have the encrypted tunnel working, this will eliminate pf from any toubleshooting you may have to do, you can do that by adding the following in /etc/pf.conf, make sure you re-load the pf rules.

set skip on enc0
set skip on gre0

 
Now, on to the tutorial…
Assume two hosts in disparate parts of the world with the following interfaces

Host A
   public interface 10.0.0.5
   private interface 10.0.50.0/24

Host B
   public interface 192.168.0.5
   private interface 192.168.50.0/24

 
First, enable gre on both hosts A and B by enabling the sysctl net.inet.gre.allow

# sysctl -w net.inet.gre.allow=1

 
To make it more permanent, add net.inet.gre.allow=1 to /etc/sysctl.conf.

Now, we will construct a gre tunnel to allow their private networks to communicate.

On Host A you would run the following

# ifconfig gre0 create
# ifconfig gre0 172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
# ifconfig gre0 tunnel 10.0.0.5 192.168.0.5
# route add -net 192.168.50 -netmask 255.255.255.0 172.16.0.2

 
Where did 172.16.0.1 and 172.16.0.2 come from, you might ask? These addresses create the point to point gre tunnel, you should pick them from RFC1918 space that is unused in the network(s) you will be connecting.

On to Host B

# ifconfig gre0 create
# ifconfig gre0 172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
# ifconfig gre0 tunnel 192.168.0.5 10.0.0.5
# route add -net 10.0.50 -netmask 255.255.255.0 172.16.0.1

 
Once you’ve proven a host on 10.0.50.x can communicate with a host on 192.168.50.x, you can write the gre to /etc/hostname.gre0.

Host A’s /etc/hostname.gre0 looks like this,

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 10.0.0.5 192.168.0.5
!route add -net 192.168.50 -netmask 255.255.255.0 172.16.0.2

 
At this point your GRE tunnel should be working, do not move onto implementing IPSec until your GRE tunnel is functioning, it will only complicate troubleshooting

Now, enable ipsec on both hosts A and B by enabling the sysctl net.inet.esp.enable

# sysctl -w net.inet.esp.enable=1

 
To make it more permanent, add net.inet.esp.enable=1 to /etc/sysctl.conf.

Now, in this document we will be using public key authentication, to implement x509 certificate authentication please refer to this document.

For public key encryption, you will make use of the file /etc/isakmpd/local.pub. If for some reason this file does not exist, check to see if /etc/isakmpd/private/local.key exists, if neither exists you can create them with the following commands.

# /usr/sbin/openssl genrsa -out /etc/isakmpd/private/local.key 1024
# chmod 600 /etc/isakmpd/private/local.key
# openssl rsa -out /etc/isakmpd/local.pub \
                    -in /etc/isakmpd/private/local.key -pubout

 
If /etc/isakmpd/private/local.key exists but /etc/isakmpd/local.pub does not, you can generate it with the command

# openssl rsa -out /etc/isakmpd/local.pub \
                    -in /etc/isakmpd/private/local.key -pubout

 
Now, you’ll want to copy Host A’s /etc/isakmpd/local.pub to Host B and copy it to /etc/isakmpd/pubkeys/ipv4/10.0.0.5

Note: 10.0.0.5 is a file, not a directory

Likewise, you’ll need to copy Host B’s /etc/isakmpd/local.pub to Host A and copy it to /etc/isakmpd/pubkeys/ipv4/192.168.0.5

Once these have been copied, you need to setup ipsec, Host A’s /etc/ipsec.conf should contain the following

ike esp transport from 10.0.0.5 to 192.168.0.5

 
And Host B’s /etc/ipsec.conf should contain

ike esp transport from 192.168.0.5 to 10.0.0.5

 
Note: We chose transport, because ipsec is not tunneling our subnets, the gre tunnel is taking care of that for us, we are simply encrypting between the two endpoints of the tunnel.

Now, we start isakmpd and load the ipsec rules

# isakmpd -K
# ipsecctl -f /etc/ipsec.conf

 
Now, to test if you’ve been successful, try to connect from a host on 10.0.50.x to a host on 192.168.50.x.

Assuming you can still connect, run the following on one of the end points:

# tcpdump -ni enc0
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: listening on enc0, link-type ENC
20:07:03.036687 (authentic,confidential): SPI 0x8d8b5b6b: 192.168.50.120 > 10.0.50.10: icmp: echo request (gre encap)
20:07:03.075990 (authentic,confidential): SPI 0xaf01c27a: 10.0.50.10 > 192.168.50.120: icmp: echo reply (gre encap)

 
Success! As the packet dump is telling us, you’ve a gre encapsulated packet, that is also being encrypted.

Now, to make some of those settings more permanent, add the following to /etc/rc.conf.local

isakmpd_flags="-K"
ipsec=YES

 
Now that you have IPSec over GRE working, I would strongly advise you remove the set skip rules added to your pf.conf and modify your pf rules for more stringent enforcement.
 

A: Beyond simply editing /etc/group with your favorite text editor, adding a user to the wheel group can be achieved in a few different ways.

To place a user in the wheel account when her account is first created, you would run

   $ sudo useradd -G wheel jdoe

 
Note: The above also creates the jdoe group automatically, use the -g argument if you wish her default group to be different.

If the user already exists and you wish to add her to the wheel group, you would run

   $ sudo user mod -G wheel jdoe

A: This question came to us in response to the article Backup Files and Partitions with dd and netcat.

Encrypting these files transfers is quite simple.

As in the previous article, we will setup the server to listen on port 9999 and redirect output to “backup.file”

server# nc -l -p 9999 | \\
           openssl aes-256-cbc -salt -d > file.backup
enter aes-256-cbc decryption password:

 
Once you’ve entered a password, netcat will sit there waiting for data and automatically terminate once it has received the file.

On the client side, the commands are similar, but rather than telling OpenSSL to decrypt the traffic, we’ll ask it to encrypt. We’ll assume the netcat server is 10.0.0.2.

client# openssl aes-256-cbc -salt -e < file-to-transfer | \\
          nc 10.0.0.2 9999
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

 
You’ll have to chose the same password as you did on the server, if you don’t you’ll receive errors such as

server# nc -l -p 9999 | \\
           openssl aes-256-cbc -salt -d > file.backup
enter aes-256-cbc decryption password:
bad decrypt
6194:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/usr/src/crypto/dist/openssl/crypto/evp/evp_enc.c:461:

 
As before, you can verify file integrity via checksums.

client# sha1 file-to-transfer
SHA1 (file-to-transfer) = 6476df3aac780622368173fe6e768a2edc3932c8

server# sha1 file.backup
SHA1 (file.backup) = 6476df3aac780622368173fe6e768a2edc3932c8

 
“How do I really know it’s encrypting the data?” you may ask. You could always sniff the wire, but here is a simple demonstration.

We’ll start be removing the decryption commands from the server and see what the result is.

client# cat file-to-transfer
this is a test

server# nc -l -p 9999 > file.backup

client# openssl aes-256-cbc -salt -e < file-to-transfer | nc 10.0.0.2 9999
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

server# cat file.backup
ëÇQÔ0^¥ôÖ(à0xKÑdÅ

server# openssl aes-256-cbc -salt -d < file.backup
enter aes-256-cbc decryption password:
this is a test