If anyone else is configuring a VPN between an OpenBSD
responder and a Debian Buster initiator with Strongswan
on the Debian box, the following notes may spare you
some pain.

First, configure the OpenBSD responder using the FAQ and the
X.509 Certificate Authentication section. A hearty thanks to
the writers!!

For Debian, we don't need the pfx files. Copy the
client1.domain.tgz (created per the FAQ in the same X.509
section above) to the Debian box.

Inside client1.domain.tgz is local.pub. Copy that to
/etc/iked/pubkeys/fqdn/client1.domain on the OpenBSD
responder. Of course use the real name (which doesn't really
have to resolve on the wider Internet) instead of
"client1.domain."

On the OpenBSD responder, your /etc/iked.conf should be
something like:

responder_ip="INSERT_ RESPONDER_IP_HERE"
vpn_net="INSERT_SUBNET_HERE"
mysrcid="INSERT_SRCID_HERE"
mydns="INSERT_DNS_SERVER_IP_HERE"
set fragmentation
ikev2 'responder_x509' passive esp \
        from 0.0.0.0/0 to $vpn_net \
        local $responder_ip peer any \
        srcid $mysrcid \
        config address $vpn_net \
        config name-server $mydns \
        tag "ROADW"

I believe you do need the set fragmentation line above.
You can make up something for vpn_net, like 172.16.5.0/24.

For DNS, I set up unbound to listen on vether0 and set
"mydns" to be the IP of vether0. Make sure vpn_net is
allowed in an access-control line in unbound.conf.

Then start iked. That's it for the OpenBSD side.

The Debian side took me longer.

I initially saw this error on the OpenBSD responder side:
"pool configured, but IKEV@_CP_REQUEST missing" and
"ikev2_dispatch_cert: failed to send ike auth."

The error on the responder happens if you don't configure vips on
the Debian initiator. A search for "CP_REQUEST" led me to RFC5996
and the source code in /usr/src, which makes it clear
that not assigning a local address through vips on the Debian
box was the source of much of my anguish.

The rest of this is about configuring the Debian initiator.

On the Debian box:
sudo apt install strongswan
sudo apt install strongswan-swanctl

Go to the directory you copied client1.domain.tgz to.
mkdir vpn
cd vpn
tar -xvzf ../client1.domain.tgz
sudo cp certs/client1.domain.crt /etc/swanctl/x509
sudo cp ca/ca.crt /etc/swanctl/x509ca
sudo cp private/client1.domain.key /etc/swanctl/private

Here is the /etc/swanctl/swanctl.conf:

# -----------------------------------
connections {
   joeschmoe {
      local_addrs  = YOUR_LOCAL_IP_HERE
      remote_addrs = OPENBSD_RESPONDER_IP_HERE
        vips = 0.0.0.0
        encap = yes

      local {
         auth = pubkey
         certs = client1.domain.crt # CHANGE
                                    # "client1.domain"
         id = client1.domain        # CHANGE
      }
      remote {
         auth = pubkey
         id = SRCID_HERE # same as $mysrcid on the
                         # OpenBSD responser
      }
      children {
         joeschmoe {
            remote_ts = 0.0.0.0/0
         }
      }
      version = 2
   }
}
authorities {
        joeschmoe {
                cacert = ca.crt
        }
}
# -----------------------------------

A couple of notes about swanctl.conf: I thought I needed
fragmentation = force, but I think that's only for IKEv1 and
everything seems to work without it. Just lower the mtu on
the interface (use nm-connection-manager or nmcli ).

The examples on strongswan.org
I saw had "remote_ts = 0.0.0.0" instead of "remote_ts =
0.0.0.0/0" -- nothing worked for me until I added the "/0"
to the end.

Now do
sudo /usr/sbin/swanctl -q
sudo /usr/sbin/swanctl --initiate --child joeschmoe

And that should bring it up. I see an error "adding DNS
server failed" but resolving does work for me through the
VPN since I changed /etc/resolv.conf too. I've tried a few
things to get rid of the DNS server error message and the
"handling INTERNAL_IP4_DNS attribute failed" message, but
nothing has worked for me so far.

I hope this helps!




Reply via email to