Invalid tickets from listen-tcp?

[thomas-fred]

Hello, thanks for this interesting sounding tool.

Alas I appear to be too dumb for the pipe. I have a local development webserver running on port 80. If I run: dumbpipe listen-tcp --host localhost:80 I get a ticket. So far so good.

https://ticket.iroh.computer/ suggests this ticket, along with all the others I've created, is invalid.

I cannot connect on another device using dumbpipe connect-tcp --addr 0.0.0.0:80 <key>, I get the following error:
error: invalid value '...' for '<TICKET>': wrong prefix, expected node

v0.28.0, Ubuntu 24.04, installed via cargo.

[thomas-fred]

Here's the debug log generated with: RUST_LOG=DEBUG dumbpipe listen-tcp --host localhost:80 > listen-tcp.log

[eminence]

I think you might have to share the ticket to help debug this

[matheus23]

I can't reproduce this 🤔

When I run dumbpipe listen-tcp --host localhost:80 I get output like this:

using secret key 31f69f3ed694eb7a88450decc07bc1bed0d28cc3c9009329160e47c832fd7372
Forwarding incoming requests to 'localhost:80'.
To connect, use e.g.:
dumbpipe connect-tcp nodeaa4mgh3i4bai24yq3t7altzu7rxp7daox[...]

(I truncated the ticket as it contains my public IP addresses. Showing you the secret is fine since it's regenerated for each run.)

When I then take the ticket (the part that starts with "node": nodeaa4mgh3i4bai24yq3t7altzu7rxp7daox[...]) and copy it into https://ticket.iroh.computer/ it works fine.

Are you accidentally copying a bigger part of the output? Perhaps you're also copying the dumbpipe connect-tcp part?

[thomas-fred]

Ohhh, I don't get the subsequent lines, just the first:

fred@pwlldu:~$ dumbpipe listen-tcp --host localhost:80
using secret key 57cb0917a2055ad0173b132c9113020dbe4ab883f986c32f9defe4f43840c12d

I've been pasting the only thing I had into the https://ticket.iroh.computer/ page, but now I see that's not the 'ticket'.

How come my invocation of listen-tcp isn't returning a ticket (the part starting with 'node')?

[matheus23]

Indeed that's very weird. Can you try running with RUST_LOG=iroh=debug to see iroh's debug logs? Maybe they indicate what's stalling.
It seems like the iroh endpoint never gets fully initialized.

[thomas-fred]

Here you go

[eminence]

I wonder if there's a problem getting your node IP addresses (which I think is necessary in order to generate a ticket)

[matheus23]

Looking at the logs, it looks like you don't have connectivity to the any of our relays, so likely no internet connection at all (at least you can't establish basic HTTP1.1 connections).

Is that the case for you @thomas-fred?

FWIW, dumbpipe should handle this better. E.g. it's still useful to be able to forward sockets via dumbpipe in your LAN with e2e encryption.
The listen-tcp command handler can and should detect this and print info about not having global, only local connectivity.

[thomas-fred]

I definitely have a network connection to the public internet -- I'm posting this message on the same computer and network connection that I'm trying to run dumbpipe from. I am on an institutional (university) network, behind a NAT etc.

[matheus23]

That's interesting :)

From the logs it looks like your local DNS resolver resolves all relay addresses as 25.26.27.28, but e.g. euc1-1.relay.n0.iroh-canary.iroh.link. resolves as 91.99.196.197 for me.

I'm not sure what your DNS resolver is doing? Perhaps it's intercepting all DNS and routing traffic via a local proxy that aggressively filters?

If you open https://euc1-1.relay.n0.iroh-canary.iroh.link do you see the "Iroh Relay" welcome message?

(It's kind of annoying that we don't see the underlying error for the HTTPS probe. We need to merge a version of n0-computer/n0-snafu#4 ...)

[thomas-fred]

Ok, I so I've just tried on my old Macbook at home, with and without our institutional VPN. With the VPN I get the same behaviour as before, no ticket. Without the VPN it works fine. So I guess that backs up your theory that it's a problem specific to our network -- DNS resolution by the sounds of it.

If you open https://euc1-1.relay.n0.iroh-canary.iroh.link/ do you see the "Iroh Relay" welcome message?

With the VPN: I can't visit this site in Firefox, Safari or curl. I get a warning about the site requiring HSTS but the certificate chain not being valid. Curl specifically says there's a self signed certificate in the chain.

Without the VPN: It works:

Fred@kearvaig:~$ curl https://euc1-1.relay.n0.iroh-canary.iroh.link/ 
<html><body>
<h1>Iroh Relay</h1>
<p>
  This is an <a href="https://iroh.computer/">Iroh</a> Relay server.
</p>

This seems weird. Are the certificates a red herring here? I don't see why they'd be different whether my traffic was being routed through the institutional network.

From the logs it looks like your local DNS resolver resolves all relay addresses as 25.26.27.28

It looks like 25.26.27.28 is to do with the UK National Cyber Security Centre (NCSC). They have a service called Protective DNS which fails to resolve domains they regard as suspicious. So our departmental IT, or some other part of the University of Oxford network is implementing PDNS.

What's funny is that when I couldn't get dumbpipe to work to share my dev server, I ended up using a Cloudflare tunnel -- this wasn't outlawed by Protective DNS; it worked fine. Guess who implements PDNS for NSCS? Cloudflare!

[matheus23]

This seems weird. Are the certificates a red herring here? I don't see why they'd be different whether my traffic was being routed through the institutional network.

It's not uncommon for corporate networks to intercept responses and replace the certificates with their own, so they can essentially MITM the traffic.
Usually that also requires installing additional root certificates so that e.g. your browsers or curl accept these forged certificates.

---

From their wording, it seems like PDNS is mostly an allow-list. And we're not on it? 🙃 It's possible we can do something better by integrating better with the system's root CA store. We'd need to investigate that a bit more.