WARP is having trouble to fetch settings on linux

Zero Trust WARP
1

Hello,
My ISP is blocking DoH requests. So, the only solution I have found to redirect DNS requests inside the tunnel is to make a pretty big domain fallback list. It works on android. But I have an IPC error on Linux.

$ warp-cli connect
2022-12-24T00:57:48.878635Z ERROR warp_net::ipc: Received too big ipc message length=115506
Error fetching settings: channel closed

I don’t suppose this is intended behavior. WARP version 2022.10.116. Arch Linux 6.0.12-zen1-1-zen.

2

Have you tried some other mode via the CLI such as:

warp-cli set-mode warp

one can see the choices via warp-cli set-mode --help … possible values: warp, doh, warp+doh, dot, warp+dot, proxy

Current settings may be seen via warp-cli settings

…

Edit - I just had a thought. How is your ISP blocking DoH? How can it even know one is using it? Are they blocking port 443, 53 or 5353 or something? Perhaps check this by setting one of your browsers to use DoH via (Lets pretend Firefox) Hamburger → Settings → scroll down to Network Settings → Settings → Enable DNS over HTTPS then select Cloudflare from there (they are a default).

If THAT works then your ISP isnt blocking DoH.

As a Linux user one could do a WGET or a probe to test. But we arent at that stage yet!

(I included that info for searches later. Apologies if I mansplained everything)

…

Edit edit - ah bugger it. This is FUN!

curl -vv --doh-url https://cloudflare-dns.com/dns-query https://www.example.com/

See what spews forth. Are you blocked? the -vv adds an absolute ton of verbosity! If ye does the query without the v’s its a bit more sane…

This has pretty much everything I was going to write, in the lowest comment, How can I overcome my ISP's DNS redirection when DoH is blocked? - Information Security Stack Exchange

3

Well, I can use WARP without Cloudflare for Teams (although I have to change an endpoint). But that’s not my point. I’m just pointing out that WARP client have issues with fetching settings with a large local domain fallback list. As for testing Cloudflare’s DoH. It works just fine. The problem is with the WARP’s resolver: 162.159.36.1. I’m not entirely sure what the problem is. It pings. Nmap says the ports are open. It seems there is some kind of problem with SSL connection.

$ wget https://162.159.36.1
--2022-12-25 20:22:45--  https://162.159.36.1/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Connecting to 162.159.36.1:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

Maybe it’s DPI.
Anyway, thank you for the info.

4

May I ask some dumb questions?

– What happens if you curl -v https://1.1.1.1 and curl -v https://162.159.36.1
– and openssl s_client -servername 162.159.36.1 -connect 162.159.36.1:443
– Do you see all the negotiation cruft at the top?/
– Do you have a firewall rule that might be mischievous?
– Anything in your hosts file?
– I see the error of the GnuTLS… I vvaagguueellyy remember there being a problem with SSL and an older version… update?
– Can there be a problem with you local cert store? (I dont know that much about this, yet!)

5 
$ curl -v https://1.1.1.1
*   Trying 1.1.1.1:443...
* Connected to 1.1.1.1 (1.1.1.1) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com
*  start date: Sep 13 00:00:00 2022 GMT
*  expire date: Sep 13 23:59:59 2023 GMT
*  subjectAltName: host "1.1.1.1" matched cert's IP address!
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: 1.1.1.1]
* h2h3 [user-agent: curl/7.86.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x561941d2de60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: 1.1.1.1
> user-agent: curl/7.86.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
...

curl -v https://162.159.36.1
*   Trying 162.159.36.1:443...
* Connected to 162.159.36.1 (162.159.36.1) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to 162.159.36.1:443 
* Closing connection 0
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to 162.159.36.1:443 

$ openssl s_client -servername 162.159.36.1 -connect 162.159.36.1:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Through WARP tunnel:

$ curl -v https://162.159.36.1
*   Trying 162.159.36.1:443...
* Connected to 162.159.36.1 (162.159.36.1) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com
*  start date: Sep 13 00:00:00 2022 GMT
*  expire date: Sep 13 23:59:59 2023 GMT
*  subjectAltName: host "162.159.36.1" matched cert's IP address!
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: 162.159.36.1]
* h2h3 [user-agent: curl/7.86.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x558d39bb9e60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: 162.159.36.1
> user-agent: curl/7.86.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
...

I don’t believe the issue is with a firewall. I have default rules on my router. Besides, WARP with DoH stopped working only a few days ago.
I don’t think the issue is with the host file, old packets or the cert store either. The host file is default. I regularly update my Arch. Almost everything should be up-to-date (gnutls 3.7.8-4). And most important, I have the same issue from other devices (android, windows).