[strongSwan] FreeBSD 12.x .vs. 13.x - change in strongswan as well?
tobias at strongswan.org
Tue Oct 18 16:00:12 CEST 2022
>>> 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 , 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 
>> 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
>> 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.
> 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
> 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  to see if port 4500 is the problem (that won't work with the
built-in clients in Windows or macOS, though).
More information about the Users