IPSEC Connection

Background

IPSEC

Internet Protocol Security (IPSEC) is a suite of tools that are used for securing network traffic at the IP layer. There are two protocols that provide different security assurances:

  • Authentication Header (AH) - Provides data integrity (will know if data is modified between senders), data source authentication (will know if the source isn’t what is expected for that connection), and protects against replay attacks.

  • Encapsulating Security Payloads (ESP) - Provides similar capabilities, plus confidentiality (someone in the middle can’t see the data).

There’s also something called Security Associations (SA) which provide a bundle of algorithms to dynamically exchange keys and establish a secure connection over AH or ESP. IKE is one of those.

Modes

Both ESP and AH can operate in two modes:

  • Transport mode - Provides security services between two hosts, applied to the payload of the IP packet, but the IP headers are left in the clear for routing.

  • Tunneling - The entire IP packet is encrypted and/or authenticated, and it become the payload of a new IP packet with a header to send it to the other end. At the other end, the packet is encrypted and send based on the decrpyted headers.

transport vs tunnel

Given it seems unlikely there’s a network behind this host, I’m going to guess I’ll need Transport mode for this host.

Install strongswan

I’ll use the strongswan client to connect to the VPN. I’ll install it with:

apt install strongswan

Build Config Files

I’ll need to edit /etc/ipsec.conf and /etc/ipsec.secrets to connect. This reference has details on the ipsec.conf file.

This post is a good starting point for building my conf files.

First the ipsec.secrets file:

# This file holds shared secrets or RSA private keys for authentication.

%any : PSK "Dudecake1!"

Next, ipsec.conf:

# ipsec.conf - strongSwan IPsec configuration file

config setup
    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=no

conn conceal
    authby=secret
    auto=add
    ike=3des-sha1-modp1024!
    esp=3des-sha1!
    type=transport
    keyexchange=ikev1
    left=10.10.14.15
    right=10.10.10.116
    rightsubnet=10.10.10.116[tcp]

  • charondebug="all" - be more verbose to help me troubleshoot the connection.

  • authby="secret" - use PSK auth.

  • ike, esp, and keyexchange are set based on information from ike-scan.

  • left and right represent my computer and the target computer.

  • type=transport - use ipsec transport mode to connect host to host.

A lot of these options took a lot of trial and error to get right. It’d be difficult to walk through all the failed connections I made and the number of guesses I had to make to get a working config (it was a lot, especially given that even with debug output, the feedback is weak). I will show one such case. I originally had the config above without [tcp] on rightsubnet.

Connection

Once I have the correct configuration in place, it will connect:

root@kali$ ipsec restart 
Stopping strongSwan IPsec...
Starting strongSwan 5.7.2 IPsec [starter]...

root@kali$ ipsec up conceal 
initiating Main Mode IKE_SA conceal[1] to 10.10.10.116
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.10.14.15[500] to 10.10.10.116[500] (176 bytes)
received packet: from 10.10.10.116[500] to 10.10.14.15[500] (208 bytes)
parsed ID_PROT response 0 [ SA V V V V V V ]
received MS NT5 ISAKMPOAKLEY vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.10.14.15[500] to 10.10.10.116[500] (244 bytes)
received packet: from 10.10.10.116[500] to 10.10.14.15[500] (260 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.10.14.15[500] to 10.10.10.116[500] (100 bytes)
received packet: from 10.10.10.116[500] to 10.10.14.15[500] (68 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA conceal[1] established between 10.10.14.15[10.10.14.15]...10.10.10.116[10.10.10.116]
scheduling reauthentication in 10078s
maximum IKE_SA lifetime 10618s
generating QUICK_MODE request 2936760209 [ HASH SA No ID ID ]
sending packet: from 10.10.14.15[500] to 10.10.10.116[500] (164 bytes)
received packet: from 10.10.10.116[500] to 10.10.14.15[500] (188 bytes)
parsed QUICK_MODE response 2936760209 [ HASH SA No ID ID ]
selected proposal: ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA conceal{1} established with SPIs c17de99e_i d3321544_o and TS 10.10.14.15/32 === 10.10.10.116/32[tcp]
generating QUICK_MODE request 2936760209 [ HASH ]
sending packet: from 10.10.14.15[500] to 10.10.10.116[500] (60 bytes)
connection 'conceal' established successfully

PreviousExplanationsNextGDB / GDBServer

Last updated