IPsec with OpenBSD
Published: 06/12/2010
Reference trace file:
openbsd_ipsec_main_mode.cap
As shown in the article OpenBSD IPsec Site-to-Site Quickstart Guide, configuring an OpenBSD machine as an IPsec office gateway for secure connections to other branch offices is quite easy, and most important of all, free. We can thank the inclusion of isakmpd in the operating system for performing all the work automatically (after initially configuring it, of course). Here we replicate a site-to-site connection between two offices and look at the IPsec connection forming between them. This is what the basic setup looks like:
The gateway for Office 1 has an external interface address of 1.1.1.1 while Office 2's gateway has 1.1.1.2. Both gateways were configured per the article referenced above. I started a tcpdump capture on the first gateway as the second gateway was booting and coming online.
IPsec, form thyself...
In the first packet, Gateway2 sends out an IKE initiation. It proposes Main Mode and a single transform policy: AES-CBC / SHA using RSA signature authentication and DH Group 2.
Show packet content
Initiator cookie: 516A1B2EADE09D53
Responder cookie: 0000000000000000
Next payload: Security Association (1)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 184
Security Association payload
Next payload: Vendor ID (13)
Payload length: 56
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 44
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 1
Transform payload # 0
Next payload: NONE (0)
Payload length: 36
Transform number: 0
Transform ID: KEY_IKE (1)
Encryption-Algorithm (1): AES-CBC (7)
Hash-Algorithm (2): SHA (2)
Authentication-Method (3): RSA-SIG (3)
Group-Description (4): Alternate 1024-bit MODP group (2)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Key-Length (14): Key-Length (128)
Vendor ID: 6C0DCD481DEAE8AE0B0A68384B3072F9
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 6C0DCD481DEAE8AE0B0A68384B3072F9
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
Next payload: NONE (0)
Payload length: 20
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
|
Gateway1 then responds:
Show packet content
Initiator cookie: 516A1B2EADE09D53
Responder cookie: 59114DC2626F41DE
Next payload: Security Association (1)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 184
Security Association payload
Next payload: Vendor ID (13)
Payload length: 56
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 1
Next payload: NONE (0)
Payload length: 44
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 0
Proposal transforms: 1
Transform payload # 0
Next payload: NONE (0)
Payload length: 36
Transform number: 0
Transform ID: KEY_IKE (1)
Encryption-Algorithm (1): AES-CBC (7)
Hash-Algorithm (2): SHA (2)
Authentication-Method (3): RSA-SIG (3)
Group-Description (4): Alternate 1024-bit MODP group (2)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Key-Length (14): Key-Length (128)
Vendor ID: 6C0DCD481DEAE8AE0B0A68384B3072F9
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: 6C0DCD481DEAE8AE0B0A68384B3072F9
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Next payload: Vendor ID (13)
Payload length: 20
Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
Next payload: NONE (0)
Payload length: 20
Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
|
At packet 3, Gateway 2 sends over its Diffie-Hellman public key information:
Show packet content
Initiator cookie: 516A1B2EADE09D53
Responder cookie: 59114DC2626F41DE
Next payload: Key Exchange (4)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 228
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: NAT-D (RFC 3947) (20)
Payload length: 20
Nonce Data
NAT-D (RFC 3947) payload
Next payload: NAT-D (RFC 3947) (20)
Payload length: 24
Hash of address and port: 51468DA31326A8C5AAD0B2B436F2EAF36362E0B5
NAT-D (RFC 3947) payload
Next payload: NONE (0)
Payload length: 24
Hash of address and port: 6B19D951CBBB4B13A4F16B17C30F49A3FE520882
|
The fourth packet is where Gateway1 sends over its DH key and is the last in the six-packet Main Mode exchange where the information is delivered to the other end unencrypted.
Show packet content
Initiator cookie: 516A1B2EADE09D53
Responder cookie: 59114DC2626F41DE
Next payload: Key Exchange (4)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
Flags: 0x00
.... ...0 = Not encrypted
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x00000000
Length: 228
Key Exchange payload
Next payload: Nonce (10)
Payload length: 132
Key Exchange Data (128 bytes / 1024 bits)
Nonce payload
Next payload: NAT-D (RFC 3947) (20)
Payload length: 20
Nonce Data
NAT-D (RFC 3947) payload
Next payload: NAT-D (RFC 3947) (20)
Payload length: 24
Hash of address and port: 6B19D951CBBB4B13A4F16B17C30F49A3FE520882
NAT-D (RFC 3947) payload
Next payload: NONE (0)
Payload length: 24
Hash of address and port: 51468DA31326A8C5AAD0B2B436F2EAF36362E0B5
|
In the final two packets of Main Mode, each side validates the other's identity. Each gateway had the peer's public key information already added into /etc/isakmpd/pubkeys/ipv4/. Since the key agreement was established via DH after packet 4 but before packet 5, all traffic starting at packet 5 is encrypted. After packet 6 is sent, the two sides form their IKE Security Association and are ready to engage into IKE phase 2.
From packet 7 through 15, both sides go through IPsec Quick Mode and determine their IPsec Security Associations. The information within these packets are protected by the encryption parameters agreed upon in IKE phase 1.
By the time we reach packet 12, roughly twelve seconds into the trace, some ESP traffic goes out. This is most likely me sending ICMP packets from one side to the other via the private address ranges behind each gateway. I also send out some ICMP requests from the other side as well over the next minute. You'll notice that there are only two SPI (Security Parameter Index) values within the whole trace, each specific to the originating gateway.
Closed for the day
At packet 100, I decided to power off Gateway 2, at which point it immediately sends four ISAKMP Informational packets to the other side. A few seconds later, Gateway 1 tries to start another IPsec session by sending out a couple of Main Mode initiations, but alas, Gateway 2 has checked out for the day because it thinks it has done its eight-hour shift.
Go back to the main articles list.