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

[Karl Denninger]

On 10/18/2022 10:00, Tobias Brunner wrote:
> Hi Karl,
>
>>>
>>> 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).
>
Yep.  Took me a while to find it but it definitely works.

>> 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)?
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.
>> 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 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.

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.

>> 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).
>
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.

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.

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.

I may have to resort to using something TLS-based which they basically 
can't block since it looks like an HTTPS connection.

-- 
Karl Denninger
karl at denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20221018/67a1db68/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4864 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20221018/67a1db68/attachment-0001.bin>