Re: [strongSwan] Calculating the generated MAC address when identity_lease is enabled

[Micah R Ledbetter]

Hello Tobias,

> > 5.  Even better, can I use a single conn section to match all users,
> > no matter their operating system, and enforce that they send their
> > client identifier to the DHCP server the same way?
> 
> Have a look at [1] for my suggestion to Harald (who had a similar
> question) for a possible code modification to do this (i.e. get the
> client certificate, extract the first dNSName SAN and then forward that
> as host name in the DHCP request).
> 
> [1] https://wiki.strongswan.org/issues/2581

Ah hah. I'm not sure that's the right path for my project, but I'll take it 
under consideration.

Thanks for taking the time to answer my questions - you've gone above and 
beyond, and I understand the identity matching and DHCP systems much better now.

- Micah

Re: [strongSwan] Calculating the generated MAC address when identity_lease is enabled

[Micah R Ledbetter]

Hello Tobias,


> A MAC address is 48 bits, so the 32 bits after the first two bytes
> are taken from the 64-bit SipHash-2-4 value (just by casting to an
> uint32_t) which is then run through htonl() and copied to the address
> buffer.  To calculate the value the 128-bit key
> 0x000102030405060708090a0b0c0d0e0f is used.

Ahhh. I missed that `id` was uint32_t. That clears up my confusion.
Thanks!

> If you use FQDNs as client identities they will be sent in a hostname
> option (12) in the DHCP request, which you might be able to use
> directly.

Ok, that sounds like a better solution. However, I am having trouble
making it work.

I put a lot of detail into my message below to provide all the context
I could, but the crux of my question now is this: can I configure the
strongSwan server to force all clients to use an FQDN as their
identifier, as you suggest? Or alternatively, can I force this by
changing the way I generate certificates?


Different clients send different identifiers


It seems that different clients send different things as identifiers:

 -  macOS and iOS appear to send the bare Common Name from their
certificate. For example, if the cert CN is macosclient.example.com
a conn section with
rightid=macosclient.example.com
will match when the client attempts to connect.

 -  Windows appears to send a DER-encoded X.509 Common Name object
For example, if the cert CN is windowsclient.example.com, it sends:
30:24:31:22:30:20:06:03:55:04:03:0c:19:77:69:6e:64:6f:77:73:63:
6c:69:65:6e:74:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d
... and that is matched by a conn section like
rightid="/CN=windowsclient.example.com"

 -  strongSwan (clients) are configurable. They appear to send the same
thing that Windows sends by default, but can be configured to work
the same as macOS, and even more ways besides, depending on what
they have set as their 'leftid'


First attempt: rightid=%client.example.com
==

I found some documentation here:


> Since 5.0.1 rightid for IKEv2 connections optionally takes a % as
> prefix in front of the identity. If given it prevents the daemon from
> sending IDr in its IKE_AUTH request and will allow it to verify the
> configured identity against the subject and subjectAltNames contained
> in the responder's certificate (otherwise, it is only compared with
> the IDr returned by the responder). The IDr sent by the initiator
> might otherwise prevent the responder from finding a config if it has
> configured a different value for leftid.

However, I wasn’t able to make that work the way I expected. I
initially read this to mean that it would pluck the FQDN out of the
cert that the client sends and use that as an identity, but that
doesn't appear to be the correct reading.

I put two conn sections in my ipsec.conf:

conn macosclient-ikev2-pubkey
rightid=%macosclient.example.com
auto=add
conn windowsclient-ikev2-pubkey
rightid=%windowsclient.example.com
auto=add

(This isn’t ideal, because it requires a separate conn section for each
user. Is there a way to avoid that?)

With that configuration, the macOS client can connect just fine, but
the Windows client cannot. (Note that the certificates were generated
the same way, but of course with different hostnames.)

Am I misreading the documentation? Is there some way to work around
this for built-in IPSEC clients, like on Windows, which don’t appear to
let me configure what is sent as the identifier?


Further exploration: two conn sections per user
===

As I mentioned above, I found that Windows clients will connect if
the rightid is something like

rightid="/CN=windowsclient.example.com"

However, the biggest problem with this is that I don’t know the
operating system that my users will be on in advance. I provide VPN
profiles for macOS and iOS (as .mobileconfig files), Windows (as a
Powershell script), and Linux (as strongSwan configuration files); my
users install whatever is appropriate for their operating system.

That means that I’d need to have two conn sections for each user.

conn USER-macos-ikev2-pubkey
rightid=%user.example.com
auto=add
conn USER-windows-ikev2-pubkey
rightid="/CN=%user.example.com"
auto=add

That’s not ideal, but I could make it work if I have to.

Is there a better way?


Open questions
==

A recap of my questions, since this got pretty long:

1.  Can I configure the strongSwan server to force the clients to send
the FQDNs as identities?

2.  Alternatively, can I generate certificates differently to force the
clients to send the FQDNs as identities?

3.  Am I misreading the documentation about rightid=%fqdn? If so, what
is it intended to do?

4.  Can I avoid 

[strongSwan] Calculating the generated MAC address when identity_lease is enabled

[Micah R Ledbetter]

Hello,

I am trying to configure my DHCP server to provide a domain name for each 
connected strongSwan client. To do that, I need to know the MAC address before 
the client connects, so that I can configure the DHCP server to assign it the 
correct IP address that corresponds to its DNS entry.

I am using IKEv2 and the dhcp plugin, I have enabled identity_lease, and when 
my clients connect, they are assigned an IP address from my DHCP server. 
However, I haven't yet found a way to precalculate the MAC address that 
strongSwan will assign to the client. Because of this, the DHCP server doesn't 
know to assign the IP address that corresponds to the IKEv2 identity, so 
currently, all my clients are getting a random address from the DHCP pool.

Is there a way to do this? Assuming so, how likely is it for the hash algorithm 
to change in the future - that is, how much of a bad idea is it to depend on 
strongSwan's current MAC-generating behavior?

## My failed attempt from reading the source code

Note for future readers: I am looking at git revision 
c21fff303aa09aca6495643fe98fb5e164b4f6c1

I found the prepare_dhcp() function in 
src/libcharon/plugins/dhcp/dhcp_socket.c. It appears to set the first two bytes 
of the  MAC to 0x7A and 0xA7 (lines 223 and 224), then calculates SipHash-2-4 
of the client's identity and sets the remaining MAC bytes to the result (line 
228).

However, I became confused here, because the MAC address I am seeing on my DHCP 
server is 7a:a7:bc:8b:b5:ec. After the hardcoded 0x7A and 0xA7 bytes, there are 
only four bytes, but the SipHash-2-4 documentation I'm reading, as well as the 
commit message for commit 1255de5a2076dc591dfa1ffefffea077bd218319 which 
appears to have added this functionality, claims that SipHash-2-4 returns 64 
bits / 8 bytes.

I did attempt to generate a SipHash-2-4 hash of what I believe my client is 
sending as its identity, and looked for even a partial match, thinking that 
perhaps the remaining 4 bytes are simply discarded at some later time. However, 
I could not find such a partial match.

It is quite possible I messed something up related to byte ordering, or out of 
a misunderstanding of SipHash-2-4, or because I am wrong about what my client 
is sending as its IKEv2 identity. Also, I'm afraid I have only some familiarity 
with C, so I am floundering trying to decide where to go from here in my 
investigation.

Have I missed something? And more importantly, is there a better way to do this?

Thanks very much for any help.

Re: [strongSwan] Windows 7 connection dies after a few minutes, but the client never notices

[Micah R Ledbetter]

On Fri, Sep 13, 2013 at 3:29 AM, Martin Willi mar...@strongswan.org wrote:

 The server tries to initiate an exchange, but the client does not
 respond to it. After five retransmits, the server has to assume the
 client is dead and closes the tunnel. Probably because of a DPD action
 it tries to re-establish the IKE_SA, but it cant: Because EAP
 authentication is asymmetric, only the client can re-initiate the
 tunnel.

Wanted to follow up and say: this was exactly right. I set the DPD
delay to 60 minutes (3600s) and the problem went away completely.

Thanks very much for your help.

- Micah

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Windows 7 connection dies after a few minutes, but the client never notices

[Micah R Ledbetter]

Hello,

I'm having a problem with Windows 7 clients where the connection dies
after a few minutes. The server notices and drops it, but the client
thinks it's still connected (even though it can no longer talk to the
remote network).

The logs do this:

20130911-174604 06[KNL] received a XFRM_MSG_MAPPING
20130911-174604 06[KNL] NAT mappings of ESP CHILD_SA with SPI
c593df3b and reqid {1} changed, queuing update job
20130911-174604 02[MGR] checkout IKE_SA by ID
20130911-174604 02[MGR] IKE_SA employees-win7[1] successfully checked out
20130911-174604 02[MGR] checkin IKE_SA employees-win7[1]
20130911-174604 02[MGR] check-in of IKE_SA successful.
20130911-174615 07[JOB] got event, queuing job for execution
20130911-174615 07[JOB] next event in 7s 144ms, waiting
20130911-174615 01[MGR] checkout IKE_SA
20130911-174615 01[MGR] IKE_SA employees-win7[1] successfully checked out
20130911-174615 01[IKE] giving up after 5 retransmits
20130911-174615 01[CHD] running updown script: 21
PLUTO_VERSION='1.1' PLUTO_VERB='down-client'
PLUTO_CONNECTION='employees-win7' PLUTO_INTERFACE='eth0'
PLUTO_REQID='1' PLUTO_ME='172.16.1.15' PLUTO_MY_ID='vpn.doubleline.us'
PLUTO_MY_CLIENT='172.16.0.0/17' PLUTO_MY_CLIENT_NET='172.16.0.0'
PLUTO_MY_CLIENT_MASK='17' PLUTO_MY_PORT='0' PLUTO_MY_PROTOCOL='0'
PLUTO_PEER='24.173.214.18' PLUTO_PEER_ID='192.168.1.229'
PLUTO_PEER_CLIENT='10.128.0.1/32' PLUTO_PEER_CLIENT_NET='10.128.0.1'
PLUTO_PEER_CLIENT_MASK='32' PLUTO_PEER_PORT='0'
PLUTO_PEER_PROTOCOL='0' PLUTO_UDP_ENC='4500' ipsec _updown iptables
20130911-174616 01[IKE] unable to reestablish IKE_SA due to asymmetric setup
20130911-174616 01[MGR] checkin and destroy IKE_SA employees-win7[1]
20130911-174616 01[IKE] IKE_SA employees-win7[1] state change:
ESTABLISHED = DESTROYING
20130911-174616 01[KNL] deleting SAD entry with SPI c593df3b

So it has a working checkout and checkin cycle at 17:46:04, but
then by 17:46:15 something has failed, it retransmits the checkout 5
times with no response, and ends the connection.

This timing problem is not consistent. I have been connected for
almost an hour before it started happening, but nine times out of ten,
it happens between 8 and 10 minutes in. If the client is constantly
talking to the remote network (even just doing a `ping -t` on
Windows), I don't have this problem.

This is ipsec.conf:

config setup
plutostart=no

conn employees-win7
keyexchange=ikev2
dpdaction=clear
dpddelay=30s
rekey=no
ike=aes256-sha1-modp1024!
esp=aes256-sha1!
left=172.16.1.15
leftsubnet=172.16.0.0/17
leftfirewall=yes
leftauth=pubkey
leftcert=vpn.example.com.crt.pem
leftid=vpn.example.com
right=%any
rightsourceip=10.128.0.0/20
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any
auto=add


And this is strongswan.conf:

charon {
threads = 16
dns1 = 172.16.3.246
filelog {
/var/log/charon_debug.log {
append = no
default = 4
flush_line = yes
time_format = %Y%m%d-%H%M%S
}
}
}

The client is configured exactly as recommended on the wiki:
http://wiki.strongswan.org/projects/strongswan/wiki/Win7EapConfig

The client is running Windows 7 Pro with all updates applied. The
server OS is Ubuntu 12.04.3 LTS with all updates applied, and `ipsec
version` reports Linux strongSwan U4.5.2/K3.2.0-52-virtual.

I've tried changing a couple of things (`dbdaction=restart`,
`reauth=no`, `dpddelay=60m`) without a change in this behavior. I've
also tried making the settings exactly the same as on this page to no
effect: 
http://wiki.strongswan.org/projects/strongswan/wiki/Win7EapMultipleConfig

I also found a mailing list post with this same unable to reestablish
IKE_SA due to asymmetric setup message from a few months ago, but it
didn't have any replies:
https://lists.strongswan.org/pipermail/users/2013-May/009185.html

I would greatly appreciate any help. Thanks.

- Micah

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users