|
|
|||
iked certificate based VPN's
Hello !
So I've gone and setup an OpenBSD test rig to get certificate based VPN's working. Currently we use ipsec/isakmpd flawlessly on loads of Soekris devices, which work like a charm. I've almost got it working, however my Windows clients were failing to connect with "error 13801: IKE credentials are unacceptable", from my research this seems to be a certificate error, however iked starts, loads the config and accepts the certificates. After running iked with -T I see the SA's establish, but Windows clients get "error 1931 the context has expired". running iked with -dvvvT it seems the VPN is established, but the Windows clients disconnect with the above error. My config: OpenBSD 5.6 behind a router with port 500 and 4500 forwarded on. pf is disabled on the VPN server. em0 is not configured, em1 is the only nic configured. Code:
# ifconfig em1 em1: flags=28843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6> mtu 1500 lladdr 08:00:27:f5:3d:a7 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.1.125 netmask 0xffffff00 broadcast 192.168.1.255 Code:
# cat /etc/iked.conf ikev2 passive esp \ from 192.168.1.0/24 to 10.10.10.0/24 local 192.168.1.125 peer any \ srcid 192.168.1.125 \ config address 10.10.10.7 iked output Code:
ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x1e179837 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 ikev2_pld_ts: count 1 length 16 ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 ikev2_pld_ts: start 10.10.10.0 end 10.10.10.255 ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 ikev2_pld_ts: count 1 length 16 ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 ikev2_pld_ts: start 192.168.1.0 end 192.168.1.255 ikev2_msg_send: IKE_AUTH response from 192.168.1.125:500 to <external IP of client>:52610 msgid 1, 1428 bytes pfkey_sa_add: update spi 0x1e179837 ikev2_childsa_enable: loaded CHILD SA spi 0x1e179837 pfkey_sa_add: add spi 0xcd819b16 ikev2_childsa_enable: loaded CHILD SA spi 0xcd819b16 ikev2_childsa_enable: loaded flow 0x2a4240400 ikev2_childsa_enable: loaded flow 0x2d2cf6800 sa_state: VALID -> ESTABLISHED from <external IP of client>:52610 to 192.168.1.125:500 policy 'policy1' tcpdump Code:
tcpdump: listening on em1, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 21:48:11.803166 <external IP of client>.52610 > 192.168.1.125.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 0137fad4aceaa33b->0000000000000000 msgid: 00000000 len: 880 [tos 0x78] 21:48:11.842117 192.168.1.125.500 > <external IP of client>.52610: isakmp v2.0 exchange IKE_SA_INIT cookie: 0137fad4aceaa33b->3d328df795b5e9f2 msgid: 00000000 len: 269 21:48:11.908562 <external IP of client>.52610 > 192.168.1.125.500: isakmp v2.0 exchange IKE_AUTH cookie: 0137fad4aceaa33b->3d328df795b5e9f2 msgid: 00000001 len: 2676 (frag 11829:1472@0+) [tos 0x78] 21:48:11.908623 <external IP of client> > 192.168.1.125: (frag 11829:8@1472+) [tos 0x78] 21:48:11.908753 <external IP of client> > 192.168.1.125: (frag 11829:1204@1480) [tos 0x78] 21:48:12.069494 192.168.1.125.500 > <external IP of client>.52610: isakmp v2.0 exchange IKE_AUTH cookie: 0137fad4aceaa33b->3d328df795b5e9f2 msgid: 00000001 len: 1428 Code:
# ipsecctl -sa -m FLOWS: flow esp out from ::/0 to ::/0 type deny SAD: No entries sadb_flush: satype unspec vers 2 len 2 seq 1 pid 27240 sadb_flush: satype unspec vers 2 len 2 seq 1 pid 27240 sadb_register: satype esp vers 2 len 2 seq 1 pid 19674 sadb_register: satype esp vers 2 len 20 seq 1 pid 19674 supported_auth: hmac-sha1 iv 0 min 160 max 160 hmac-md5 iv 0 min 128 max 128 hmac-ripemd160 iv 0 min 160 max 160 hmac-sha2-256 iv 0 min 256 max 256 hmac-sha2-384 iv 0 min 384 max 384 hmac-sha2-512 iv 0 min 512 max 512 supported_encrypt: null iv 0 min 0 max 0 des-cbc iv 64 min 64 max 64 3des-cbc iv 64 min 192 max 192 blowfish iv 64 min 40 max 448 cast128 iv 64 min 40 max 128 aes iv 128 min 128 max 256 aesctr iv 128 min 160 max 288 supported_comp: deflate iv 0 min 0 max 0 lzs iv 0 min 0 max 0 sadb_register: satype ah vers 2 len 2 seq 2 pid 19674 sadb_register: satype ah vers 2 len 20 seq 2 pid 19674 supported_auth: hmac-sha1 iv 0 min 160 max 160 hmac-md5 iv 0 min 128 max 128 hmac-ripemd160 iv 0 min 160 max 160 hmac-sha2-256 iv 0 min 256 max 256 hmac-sha2-384 iv 0 min 384 max 384 hmac-sha2-512 iv 0 min 512 max 512 supported_encrypt: null iv 0 min 0 max 0 des-cbc iv 64 min 64 max 64 3des-cbc iv 64 min 192 max 192 blowfish iv 64 min 40 max 448 cast128 iv 64 min 40 max 128 aes iv 128 min 128 max 256 aesctr iv 128 min 160 max 288 supported_comp: deflate iv 0 min 0 max 0 lzs iv 0 min 0 max 0 sadb_addflow: satype unspec vers 2 len 24 seq 3 pid 19674 src_mask: :: dst_mask: :: protocol: proto 0 flags 0 flow_type: type deny direction out src_flow: :: dst_flow: :: sadb_addflow: satype esp vers 2 len 24 seq 3 pid 19674 src_mask: :: dst_mask: :: protocol: proto 0 flags 0 flow_type: type deny direction out src_flow: :: dst_flow: :: EXTCERTUSAGE = serverAuth,clientAuth so it can't be the "Enhanced Key Usage" at fault, can it? The date and time are correct, the certificate is valid and not expired. I've recreated my certs numerous times with different configurations as per mouedine.net albeit with the static IP provided by the ISP being the address of em1 rather than an external interface, seeing as this box is behind a firewall. I'm banging my head against a wall at the moment and hoping someone can help/point me in the right direction TIA |
|
|||
It has been a very long time I have played with IPSEC on OpenBSD. There are some fragments in your tcpdump. You could try to prevent fragmentation by using a lower MTU and see whether the fragmention is the cause of your problems.
Increase the verbosity of your tcpdump output by using -vvv, use a snap length of 1500 (-s 1500) and the output will give you a lot of more clues of what is going on. BTW the howto at http://mouedine.net/ is already several years old
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
||||
Hello, and welcome!
I run IKEv2 with certs, but only between OpenBSD systems; third party connections are not in use and I have no experience with them to share. Quote:
I note you are using IP addresses in iked.conf. As I'm using certificates, I use FQDNs for srcid and destid, and my certificates match the FQDNs. As an example: Code:
ikev2 active esp \ from 10.0.3.2 to 10.0.3.1 \ srcid netbook.jggimi.homeip.net \ dstid fw2.jggimi.homeip.net The error you're getting from Windows (13801) has these possible causes. If you're missing one of the two required certs, #3 might be why. If your cert and servers don't align exactly, #4 could be why, and you may want to switch to matching certificate names with FQDNs, as I do.
|
|
|||
Thanks, for replying
I'd exported the client certificate and ca and installed them on the Windows side in the person and trust root cert auth locations. When checking the cert's in the Windows certificate manager they both appear valid. Changing the srcid back to the hostname of the box. Which is also the hostname of the dynamic external IP. EG 192.168.1.125 resolves to box.blah.uk as does the ISP's dynamic IP, using a ddns service with a cname of box.blah.uk pointing to the ddns hostname. Changing the srcid from an IP to the FQDN reverts the error from 1931 to 13801. Using ipsecctl -sa -m I see the SA's establish. I've not configured ipsec.conf which i assume is correct for an iked setup? There's no mention of it in the man pages. |
|
||||
You are correct, ipsec.conf is used with IKEv1. I've found ipsecctl(8) still very useful with IKEv2, for operands -sa and -F.
I think this may be one of the references regarding FQDN I'd found when first provisioning IKEv2, and it may be helpful as it is persuant to Win7. It isn't the definitive comment I recall seeing ... that is one I can no longer locate. |
|
|||
I've not been able to get it working, from what I can tell the configuration is correct - that leaves me to believe either the BT Homehub3 or fragmented packets are causing issues.
As much as I'd love a Soekris at home, I can't justify the expense and would rather get more Sonos than a Soekris. I may ditch the BT router and replace it with a PC for now until I can decide on a low power device which will ideally run OpenBSD, my RPi model a with FreeBSD crashes and only has 1 Nic, so don't want to go down that route and will avoid any sort of Linux. |
|
|||
Thanks jggimi, I might do that too
Currently bidding on a second hand Soekris, which would be nice, but not as powerful/new as the ones we use at work - however I'm hoping to get it cheap! |
|
|||
I never got that Soekris
I did however pick up a Dell Optiplex, installed a second NIC and setup a router, I was a tad lazy and went for L2TP/IPSec VPN. In the future I may move over to a certificate based VPN. As I found on my searches plenty of people have issues connecting with mobiles to this setup, as did I at first until I looked in /var/log/messages and tweaked the VPN configuration accordingly. For anyone interested I wrote a blog post once I had it working: http://bit.ly/1N40OOl Any feedback would be greatly appreciated |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
M:Tier ssl certificate | shep | OpenBSD Installation and Upgrading | 5 | 12th November 2013 06:36 PM |
Security Would you knowingly trust an irrevocable SSL certificate? | J65nko | News | 0 | 24th May 2013 06:56 PM |
iked support for ECDSA keys | cakersq | OpenBSD Security | 2 | 4th March 2013 03:27 PM |
Trustwave issued a man-in-the-middle certificate | J65nko | News | 2 | 21st February 2012 10:41 PM |
Further evidence of Certificate Authority break-ins | J65nko | News | 0 | 27th October 2011 08:18 PM |