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

2018-03-31 Thread 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] IPsec broken for iphone with ios11?

2018-03-31 Thread Harald Dunkel
On 03/29/18 18:23, Harald Dunkel wrote:
> Hi folks,
> 
> is it just me, or is IPsec broken for ios 11 (iphone)? I can establish
> an IPsec connection once, but if I reconnect then the routing appears
> to be broken. I cannot ping the DNServer on the remote net.
> 
> My ipad (ios 10) with a similar profile has no such problem.
> 
> Can anybody reproduce this?
> 

Using the new ios 11.3 or macos 10.13.4 the problem vanished.


Regards
Harri