[strongSwan] FreeBSD 12.x .vs. 13.x - change in strongswan as well?

[Tobias Brunner]

Hi Karl,

>>> And, it appears, Windows is insisting on using the CN when presenting 
>>> the identity (instead of the field(s) in the SAN) unless you set the 
>>> option on the VPN profile to allow an override -- and then you have 
>>> to hand-key it on each connection.  I don't believe there is any way 
>>> to tell Windows to use the SAN identity or identities on its own.
>>
>> Yes, as documented on [1], the Windows client uses the CN value as EAP 
>> identity with EAP-TLS (i.e. user certificates).  I didn't know this 
>> can actually be changed, so that might be something we could add to 
>> the docs.  Could you provide details  on this?  Anyway, without 
>> explicit changes on the client, this only works if the certificate 
>> contains a matching SAN.
> 
> Yes.... here's where it is; you have to go at the connection from the 
> control panel, not from the Windows 10+ "quick list" in settings.
> 
> And then click "Properties" which gets you this:
> 
> At the very bottom is "use a different user name."  Select that and you 
> will get prompted for it when you go to connect; if the SAN includes the 
> email address (which it has to for it to be useful as a S/Mime 
> certificate, for example) you can enter it there and it works.

Thanks.  That looks simpler than I expected (I assumed it required 
fiddling with group policies or the like).

>> The problem is that the EAP identity does not contain a type, so 
>> unless the data is ASN.1 (e.g. a full binary DN), the rules at [2] 
>> apply when the identity is parsed.  In your case, with
>>
>>> the "CN" of these certs is the full name of the person, not an email 
>>> address
>>
>> the SAN would have to be of type dNSName as that's the default 
>> fallback for the parser.  Considering that the full name probably 
>> contains spaces that might be a bit weird but it's perfectly legal as 
>> dNSName is of type IA5String, which accepts all ASCII characters, and 
>> DNS names may consist of any 8-bit characters (only to host names 
>> apply some further restrictions).
> 
> Gotcha.  If I have to reissue then I may as well change the CN to the 
> email address, which isn't horrible for user I suppose; at least its 
> consistent with what they know.  I've got this out in the field (my own 
> personal server is a "who cares" but for everyone else...) and that plus 
> the local CA setup has been automated and working out there for quite 
> some time.  What I may do is tell people how to override for now but 
> change the back end stuff on issuing so when certificates roll over the 
> CN is the email address instead of the user's full name.

Sounds reasonable.

> I don't like the idea of issuing certs with a DNSName that isn't 
> properly-formed; who knows what might try to use that as a lookup (it 
> would fail if handed to a resolver, obviously, but still.)

Don't know of any component that would do that, but yeah, it's probably 
not ideal.

> If I ping the connection from the server it is transmitting. Looking at 
> the client end I see the traffic coming in and the reply traffic going 
> back out, but I never get the reply back on the server.  The only thing 
> I see coming back from the client at all on the server end is IKE 
> keepalives, which implies that the phone or the network is blocking 
> encapsulated outbound traffic or (perhaps) Microsoft has screwed the 
> pooch with their internal VPN code in the most-recent update.  Without 
> being able to tcpdump the devices in the middle (the phone, obviously, 
> never mind the telco network) figuring out exactly who's doing me dirty 
> is not easy.

Hm, the IKE keepalives (or any other IKE packets) take the same path the 
UDP-encapsulated ESP packets from the client will.  So if the client 
actually sends a UDP-encapsulated ESP packet back, it's really weird 
that it gets dropped.  In particular, because the pings are small enough 
to rule out fragmentation issues.  So unless there is a firewall that 
does deep inspection and drops ESP packets from the client this is quite 
weird.  Does it happen with tethered non-Windows clients, too (e.g. 
macOS or Linux)?
> Not being able to wireshark or tcpdump in the phone doesn't help me 
> trying to run this down, obviously, and I suspect this is some sort of 
> active interference with port 500 

Note that UDP port 4500 is relevant here as the NAT situation triggers 
NAT traversal (i.e. UDP encapsulation).

> I'm going to be spending a fair bit more time going after this for 
> obvious reasons; I have a sneaky suspicion this is either in the phone 
> firmware or carrier but need to verify that by finding an open hotspot 
> where I can see if it works as it has for the last several years there 
> and I may have to root a phone device so I can get in there with a root 
> shell and see if I can find something there.  If not then obviously its 
> being blocked in the carrier infrastructure or their tethering 
> provisioning pushed to the phone.

I guess it's possible that Android does something weird.  For instance, 
treat packets with destination port 4500 specially somehow.  As 
responder, that's necessary in order to process UDP-encapsulated ESP 
packets in the kernel and forward IKE packets to userland on the same 
port/socket.  But since Android is only forwarding traffic it obviously 
shouldn't do that.  If you can use a Linux client behind the Android 
device and it happens there as well, you could try using a custom server 
port [1] to see if port 4500 is the problem (that won't work with the 
built-in clients in Windows or macOS, though).

Regards,
Tobias

[1] 
https://docs.strongswan.org/docs/5.9/features/natTraversal.html#_custom_server_ports