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
