<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 10/18/2022 10:00, Tobias Brunner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f98706be-facf-b252-312a-58d8b41c5d30@strongswan.org">Hi
Karl,
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
And then click "Properties" which gets you this:
<br>
<br>
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.
<br>
</blockquote>
<br>
Thanks. That looks simpler than I expected (I assumed it required
fiddling with group policies or the like).
<br>
<br>
</blockquote>
<p>Yep. Took me a while to find it but it definitely works.</p>
<blockquote type="cite"
cite="mid:f98706be-facf-b252-312a-58d8b41c5d30@strongswan.org">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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)?
<br>
</blockquote>
Don't know; I don't have any. But it doesn't happen with
non-tethered (e.g. Strongswan client on the Android phone); that
works fine.<br>
<blockquote type="cite"
cite="mid:f98706be-facf-b252-312a-58d8b41c5d30@strongswan.org">
<blockquote type="cite">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 </blockquote>
<br>
Note that UDP port 4500 is relevant here as the NAT situation
triggers NAT traversal (i.e. UDP encapsulation).
<br>
<br>
</blockquote>
<p>I suspect its actually 4500 that is being blocked and only in the
outbound direction from the tethered device. Otherwise you
wouldn't see the pings on the client from the server in the packet
counts (but you do) while pings from the client aimed at anything
(including the server itself) show up in the client packet counts
but there are no packets received by the server at all on either
UDP 500 or 4500, and the encapsulated ones should be coming back
in. They're not.</p>
<p>Since I'm getting the IPSEC keepalives I know the routing is good
and that's not the problem as otherwise I'd get nothing from the
client post-connection establishment at all, but I do get the
maintenance traffic.<br>
</p>
<blockquote type="cite"
cite="mid:f98706be-facf-b252-312a-58d8b41c5d30@strongswan.org">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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).
<br>
<br>
</blockquote>
<p>It's not Android per-se; I have an old phone that can tether but
is wildly out of maintenance (used to be my primary handset long
ago) thus it can't get "pushed" an OS update. It fails exactly
the same way.</p>
<p>The only other thing I can think of would be T-Mobile doing some
odd stuff with 6to4 but that should impact everything when it
comes to bringing up the VPN and it doesn't. Specifically the
IPv4 address the phone is getting from them is 192.0.0.4, which is
rather odd; it also gets a (valid) IPv6 address. A few years back
T-Mobile started handing out IPv6 addresses on tethers which
resulted in all sorts of fun with an IPv4-only IPSec gateway but
was fairly-easy to resolve by shutting off IPv6 on the Windows VPN
client.<br>
</p>
<p>This looks very much like a one-way block on UDP 4500 outbound
from tethered devices, which if so is both deliberate and rather
evil since it renders IPSec tethered connections completely
worthless. This is also new; about a month ago it was working
perfectly well.</p>
<p>I may have to resort to using something TLS-based which they
basically can't block since it looks like an HTTPS connection.<br>
</p>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
</body>
</html>