You are not logged in.
I've got a VM in my LAN that I'm intending to dedicate to running a VPN. It's not on 192.168.0.1 ("_router"), it's some other IP inside the LAN ("_vpn"). My intention is to use DHCP to tell other hosts in the LAN ("_client") to use _vpn's IP as a default route. Both _vpn and _client are running Arch.
Surfing from _vpn itself works just fine. If I visit browserleaks.com, my browser shows my requests, DNS, and everything else originating from the VPN provider's gateway as one might expect.
I can successfully surf browserleaks.com (or some other "_website") from _client via a proxy (Squid) running on _vpn. But if I do not configure my browser to use Squid, surfing fails entirely.
_vpn is running systemd-resolved with DNSStubListenerExtra=0.0.0.0 in /etc/systemd/resolved.conf so that _client can query it. I did have to add some iptables rules to _vpn's config myself so that hostnames in my LAN could be resolved. Other than that, _vpn's iptables only has a few filter rules which are configured entirely by the VPN client and untouched by me.
If I sniff tun0's traffic on _vpn, I see that tun0's IP is on src addr and dst addr, appropriately. iptables shows a nat rule as expected and there are no mangle rules. If I sniff enp1s0 on _vpn, I see _client's private address in the same spots.
Finally, if I sniff enp1s0 on _client, I see a complete conversation happening: DNS is queried and a response is received, then the HTTPS conversation starts: SYN, SYN/ACK, ACK, PSH, ACK, PSH, ACK, ... the whole nine yards.
IP _client.44226 > _vpn.53: 26783+ [1au] AAAA? browserleaks.com. (45)
IP _vpn.53 > _client.44226: 26783 0/0/1 (45)
IP _client.33596 > _website.443: Flags [S], seq 3961226037, win 64240, options [mss 1460,sackOK,TS val 1360997897 ecr 0,nop,wscale 7], length 0
IP _website.443 > _client.33596: Flags [S.], seq 3974106505, ack 3961226038, win 65160, options [mss 1460,sackOK,TS val 609080146 ecr 1360997897,nop,wscale 8], length 0
IP _client.33596 > _website.443: Flags [.], ack 1, win 502, options [nop,nop,TS val 1360998044 ecr 609080146], length 0
IP _client.33596 > _website.443: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1360998044 ecr 609080146], length 517
IP _website.443 > _client.33596: Flags [.], ack 518, win 253, options [nop,nop,TS val 609080294 ecr 1360998044], length 0Unfortunately, at this point, elinks stays on "SSL negotiation" and won't progress any further.
If I quit out of elinks, I see this pattern (FIN/ACK, FIN/ACK, ACK, ACK, FIN/ACK, ACK, FIN/ACK, RST), almost every time (sometimes the RST happens sooner):
IP _client.33574 > _website.443: Flags [F.], seq 518, ack 1, win 502, options [nop,nop,TS val 1350713943 ecr 598789874], length 0
IP _client.37004 > _website.80: Flags [F.], seq 180, ack 359, win 501, options [nop,nop,TS val 1350713943 ecr 598789582], length 0
IP _website.443 > _client.33574: Flags [.], ack 519, win 253, options [nop,nop,TS val 598796002 ecr 1350713943], length 0
IP _website.80 > _client.37004: Flags [.], ack 181, win 254, options [nop,nop,TS val 598796002 ecr 1350713943], length 0
IP _website.80 > _client.37004: Flags [F.], seq 359, ack 181, win 254, options [nop,nop,TS val 598796032 ecr 1350713943], length 0
IP _client.37004 > _website.80: Flags [.], ack 360, win 501, options [nop,nop,TS val 1350714162 ecr 598796032], length 0
IP _website.443 > _client.33574: Flags [F.], seq 4233, ack 519, win 253, options [nop,nop,TS val 598796035 ecr 1350713943], length 0
IP _client.33574 > _website.443: Flags [R], seq 185786005, win 0, length 0Even if I surf specifically to https://_website, I still see a RST being sent by the client:
IP _client.33586 > _website.443: Flags [F.], seq 518, ack 1, win 502, options [nop,nop,TS val 1353343514 ecr 601423086], length 0
IP _website.443 > _client.33586: Flags [.], ack 519, win 253, options [nop,nop,TS val 601425634 ecr 1353343514], length 0
IP _website.443 > _client.33586: Flags [F.], seq 4232, ack 519, win 253, options [nop,nop,TS val 601425663 ecr 1353343514], length 0
IP _client.33586 > _website.443: Flags [R], seq 761562196, win 0, length 0The TCP close looks okayish but the RST has me scratching my head, as if it may be holding the key (or at least a clue) to unlocking this puzzle. Or maybe it's just in response to the ACK in the FIN/ACK being sent by _webserver, which if I'm not mistaken should just be a FIN? And where's the final ACK from _client to _webserver?
In any case, if I take the next step up the network stack, I see this:
% openssl s_client -msg -connect browserleaks.com:443
CONNECTED(00000003)
>>> ??? [length 0005]
00 01 02 03 04
>>> TLS 1.3, Handshake [length 0139], ClientHello
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
.
.
.(I have obfuscated the exact hexdump.) The conversation ends immediately after the ClientHello is sent. No ServerHello is ever received by _client.
Now the really interesting bit. If I run nc -l 9999 on a "_remote" machine and then run nc _remote 9999 on _client, messages are passed back and forth just fine, albeit wtihout TLS. So clearly my connection to this VPN (which I might add is a very big name in VPNs), for whatever reason, is preventing ServerHello messages from getting through to _client. However, it looks like _website may at least be sending a TCP ACK in response to ClientHello.
Any ideas why TLS could be failing to negotiate? I think the only logical answer to this is that what _website is receiving has ceased to be a ClientHello or has otherwise been modified before reaching its destination but I'm not sure where to go from here.
Last edited by hexadecagram (2022-05-16 05:41:04)
Offline
Solved, well, actually what I would call a workaround for now.
This is all thanks to the protocol that the VPN client is using. Once I switched from their proprietary protocol to OpenVPN over UDP, TLS was once again usable.
I'm suddenly reminded of the days before NAT-T.
Last edited by hexadecagram (2022-05-16 05:41:44)
Offline