Hello,
I want to integrate a remote OpenBSD 7.2 machine into my local network.
So it will be reachable via a local IPv4 address like 192.168.0.206. My
local router and IPSec server is a LANCOM 1781EW+.
The setup works already, but only if iked uses IPv4 and not IPv6. (I
have a working IPv6 setup with strongSwan on Android tough.)
# cat /etc/iked.conf
ikev2 "rathaus" active esp \
from 192.168.0.0/24 to any \
from dynamic to 192.168.0.0/24 \
peer vpn.example.com \
srcid o2@rathaus \
psk "will-change-to-certs-if-testing-is-finished" \
request address any \
iface lo1
This config works if the peer entry is a IPv4 address or if
vpn.example.com has only an A record. If vpn.example.com has an AAAA
record or peer is a IPv6 address it will not work.
Working:
# iked -d
ikev2_init_ike_sa: initiating "rathaus"
spi=0x6fa20e5d5cc463ce: send IKE_SA_INIT req 0 peer 91.65.56.196:500
local 0.0.0.0:500, 518 bytes
spi=0x6fa20e5d5cc463ce: recv IKE_SA_INIT res 0 peer 91.65.56.196:500
local 192.168.1.210:500, 38 bytes, policy 'rathaus'
spi=0x6fa20e5d5cc463ce: sa_free: reinitiating with new DH group
ikev2_init_ike_sa: initiating "rathaus"
spi=0x22213067a8f10273: send IKE_SA_INIT req 0 peer 91.65.56.196:500
local 0.0.0.0:500, 742 bytes
spi=0x22213067a8f10273: recv IKE_SA_INIT res 0 peer 91.65.56.196:500
local 192.168.1.210:500, 487 bytes, policy 'rathaus'
spi=0x22213067a8f10273: send IKE_AUTH req 1 peer 91.65.56.196:4500 local
192.168.1.210:4500, 327 bytes, NAT-T
spi=0x22213067a8f10273: recv IKE_AUTH res 1 peer 91.65.56.196:4500 local
192.168.1.210:4500, 239 bytes, policy 'rathaus'
spi=0x22213067a8f10273: ikev2_ike_auth_recv: obtained lease: 192.168.0.206
spi=0x22213067a8f10273: ikev2_ike_auth_recv: obtained DNS: 192.168.1.254
spi=0x22213067a8f10273: ikev2_childsa_enable: loaded SPIs: 0xcffacc66,
0xe1e53f59 (enc aes-256-gcm)
spi=0x22213067a8f10273: ikev2_childsa_enable: loaded flows:
ESP-192.168.0.0/24=0.0.0.0/0(0)
spi=0x22213067a8f10273: established peer
91.65.56.196:4500[UFQDN/o2@rathaus] local
192.168.1.210:4500[UFQDN/o2@rathaus] policy 'rathaus' as initiator (enc
aes-256-gcm group modp2048 prf hmac-sha2-256)
Not working:
# iked -vd
ikev2 "rathaus" active tunnel esp inet6 from 192.168.0.0/24 to 0.0.0.0/0
from 0.0.0.0 to 192.168.0.0/24 local any peer
2a02:810d:0:bf:c816:fbf3:8a40:7821 ikesa enc aes-128-gcm enc aes-256-gcm
prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1
group curve25519 group ecp521 group ecp384 group ecp256 group modp4096
group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc
aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf
hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth
hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group
ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group
modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc
aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc
aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth
hmac-sha1 group none esn noesn srcid o2@rathaus lifetime 10800 bytes
4294967296 psk 0xfoobar config address any iface lo1
ikev2_init_ike_sa: initiating "rathaus"
spi=0x12efeecdd9b0e8b6: send IKE_SA_INIT req 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local :::500, 518 bytes
spi=0x12efeecdd9b0e8b6: recv IKE_SA_INIT res 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 38 bytes, policy 'rathaus'
spi=0x12efeecdd9b0e8b6: sa_free: reinitiating with new DH group
ikev2_init_ike_sa: initiating "rathaus"
spi=0x4657d2d35de226ed: send IKE_SA_INIT req 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local :::500, 742 bytes
spi=0x4657d2d35de226ed: recv IKE_SA_INIT res 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 487 bytes, policy 'rathaus'
(Around this point the router reports: "IKEV2C_O2 connected")
spi=0x4657d2d35de226ed: send IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 359 bytes
spi=0x4657d2d35de226ed: retransmit 1 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
spi=0x4657d2d35de226ed: retransmit 2 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
spi=0x4657d2d35de226ed: retransmit 3 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
spi=0x4657d2d35de226ed: retransmit 4 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
spi=0x4657d2d35de226ed: retransmit 5 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
spi=0x4657d2d35de226ed: recv IKE_AUTH res 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 36 bytes, policy 'rathaus'
(Around this point the router reports: "Dead Peer Detection Timeout")
spi=0x4657d2d35de226ed: sa_free: retransmit limit reached
ikev2_init_ike_sa: initiating "rathaus"
spi=0x1dff88d310751f63: send IKE_SA_INIT req 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local :::500, 742 bytes
spi=0x1dff88d310751f63: recv IKE_SA_INIT res 0 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 487 bytes, policy 'rathaus'
spi=0x1dff88d310751f63: send IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500, 359 bytes
spi=0x1dff88d310751f63: retransmit 1 IKE_AUTH req 1 peer
2a02:810d:0:bf:c816:fbf3:8a40:7821:500 local
2003:c8:2721:cc00:f773:7319:68a6:8ed8:500
(This loops forever.)
The traces on the LANCOM router side look the same (for me) for IPv4 and
v6 connections at first. It reports "connected" but then, as the
iked-log suggests, it continuous to receives IKE-AUTH-REQUESTs.
[VPN-Status] 2022/10/30 00:31:57,176 Devicetime: 2022/10/30 00:31:57,391
VPN: IKEV2C_O2 connected
[VPN-Status] 2022/10/30 00:31:57,176 Devicetime: 2022/10/30 00:31:57,391
VPN: WAN state changed to WanConnect for IKEV2C_O2
(2003:c8:2721:cc00:f773:7319:68a6:8ed8) IKEv2, called by: 01e99fd4
[VPN-Status] 2022/10/30 00:31:57,176 Devicetime: 2022/10/30 00:31:57,391
vpn-maps[15], remote: IKEV2C_O2, connected, static-name, connected-by-name
[VPN-Status] 2022/10/30 00:31:57,176 Devicetime: 2022/10/30 00:31:57,407
internal DNS resolution for IKEV2C_O2
IpStr=>0.0.0.0<, IpAddr(old)=0.0.0.0, IpTtl(old)=0s
IpStr=>0.0.0.0<, IpAddr(new)=0.0.0.0, IpTtl(new)=0s
[VPN-IKE] 2022/10/30 00:31:58,129 Devicetime: 2022/10/30 00:31:58,357
[IKEV2C_O2] Received packet:
IKE 2.0 Header:
Source/Port : [2003:c8:2721:cc00:f773:7319:68a6:8ed8]:500
Destination/Port : [2a02:810d:0:bf:c816:fbf3:8a40:7821]:500
Routing-tag : 0
Com-channel : 15
| Initiator cookie : 6E 91 F2 B5 5E 03 58 8F
| Responder cookie : 7E 28 3D 6F A3 BC A6 7D
| Next Payload : ENCR
| Version : 2.0
| Exchange type : IKE_AUTH
| Flags : 0x08 Initiator
| Msg-ID : 1
| Length : 359 Bytes
ENCR Payload
| Next Payload : IDI
| CRITICAL : NO
| Reserved : 0x00
| Length : 331 Bytes
| IV : 00 00 00 00 00 00 00 00
| Encrypted Data : B6 BB D1 1E 7D 2B 6A CA 2D 6D 6E 1B CD 29 B3 A6
| 20 2A 82 83 71 09 AB 3A 70 9B AB EA 30 04 4F 79
| E7 E4 E4 27 3A 1A 95 52 16 E0 7A A7 79 14 60 63
| 67 CA 39 C2 67 C3 8C 87 A3 0F DA 05 84 0E BF 5C
| AB 73 88 FD 61 14 61 84 13 C3 5E 2A 2A 77 A3 64
| E2 5B 5A A8 6F 9C 1F 8A 9B 49 33 35 B6 C7 76 9D
| 5B 56 A1 44 00 81 98 8A A8 C7 7C 76 B0 8B 99 DF
| 73 3F 22 96 7B 80 8B 51 C1 B8 5B F2 4B 99 F6 CF
| DE D5 22 52 50 B6 41 82 39 0B F3 A3 50 C0 FD 0D
| BD 42 25 C1 0D 29 3E EC 1B 36 0C 37 FF CC 31 43
| C6 53 0B 89 0E 40 AC 3B 19 A3 A4 69 A9 53 A4 BF
| 65 E0 65 13 E6 64 2C FD E3 3B E8 47 37 A4 D2 AE
| 16 4F D5 DF C5 B5 FE 6A D2 36 E9 44 06 2B F7 B6
| 57 15 EF 7A 70 84 70 55 9E 92 75 AD C3 0F 77 57
| 29 B7 64 D5 49 3D 16 D9 FD 76 E9 EC 70 AB A8 13
| F2 AC EF 14 1A 13 E0 45 53 2B 76 0A 61 D7 E1 21
| B6 8F 14 7C A9 6D 98 A2 DD A1 68 AF BD 20 6F A5
| 26 EC 3E 49 F7 11 73 E0 E0 8B E8 9A 62 28 29 23
| A2 AF 22 74 90 CC AF 59 A3 1C D2 0F A4 E7 41
| ICV : 03 F5 BA 36 39 45 8F 9B 5A 82 97 26 78 40 8B 2D
[VPN-Debug] 2022/10/30 00:31:58,191 Devicetime: 2022/10/30 00:31:58,357
Peer IKEV2C_O2 [responder]: Received an IKE_AUTH-REQUEST of 359 bytes
(encrypted)
Gateways:
[2a02:810d:0:bf:c816:fbf3:8a40:7821]:4500<--[2003:c8:2721:cc00:f773:7319:68a6:8ed8]:4500
SPIs: 0x6E91F2B55E03588F7E283D6FA3BCA67D, Message-ID 1
Payloads: ENCR
QUB-DATA:
[2a02:810d:0:bf:c816:fbf3:8a40:7821]:500<---[2003:c8:2721:cc00:f773:7319:68a6:8ed8]:500
rtg_tag 0 physical-channel WAN(1) vpn-channel 15
transport: [id: 557124, UDP (17) {incoming unicast, fixed source
address}, dst: 2003:c8:2721:cc00:f773:7319:68a6:8ed8, tag 0 (U), src:
2a02:810d:0:bf:c816:fbf3:8a40:7821, hop limit: 64, DSCP: CS6, ECN:
Not-ECT, pmtu: 1500, (R) iface: INTERNET (3), next hop:
fe80::1212:ff:fe00:6598], local port: 4500, remote port: 4500, flags:
UDP_ENCAPSULATION
+IKE_SA found and assigned
[VPN-Status] 2022/10/30 00:31:58,191 Devicetime: 2022/10/30 00:31:58,358
Peer IKEV2C_O2 [responder]: Received an IKE_AUTH-REQUEST of 359 bytes
(encrypted)
Gateways:
[2a02:810d:0:bf:c816:fbf3:8a40:7821]:4500<--[2003:c8:2721:cc00:f773:7319:68a6:8ed8]:4500
SPIs: 0x6E91F2B55E03588F7E283D6FA3BCA67D, Message-ID 1
+Received duplicate -> retransmitting corresponding response
This repeats forever. I can send the whole trace (123KB) off list.
BTW I tried so force iked to use IPv4. First with
ikev2 "rathaus" active esp inet \
and than with
peer vpn.example.com local 192.168.1.210 \
(192.168.1.210 is the local IP of the OpenBSD server.)
Which both leads to
# iked -vd
parent: create_ike: policy address family mismatch
control exiting, pid 54466
ca exiting, pid 32732
ikev2 exiting, pid 98707
So my only workaround for now is to use a domain with only an A record.
