it doesn't seem to work

[Itay1787]

Hi, I just tried tailgate and it doesn't seem to work.

if I do a tailscale netcheck it gets the IP of my Main interface instead of the one that I set to tailgate.

What do I do?

Are there logs that I could attach?

Thanks!

[fernandoenzo]

Good morning and Merry Christmas! 🎄

First of all, I apologize for not responding last week; I was on vacation.

Regarding your mention of the tailscale netcheck command, I must admit I never use it, and I'm not sure how it relates to the use of tailgate.

However, if you could describe your specific use case in detail and the issue you're facing, that would be a good starting point. Tailgate doesn't generate logs, so just tell me what you're doing and how you're doing it, and I'll help you as best as I can.

Best regards

[Itay1787]

Good morning and Merry Christmas! 🎄

First of all, I apologize for not responding last week; I was on vacation.

Regarding your mention of the tailscale netcheck command, I must admit I never use it, and I'm not sure how it relates to the use of tailgate.

However, if you could describe your specific use case in detail and the issue you're facing, that would be a good starting point. Tailgate doesn't generate logs, so just tell me what you're doing and how you're doing it, and I'll help you as best as I can.

Best regards

Hi, thanks for the response, and happy holidays!
if you run tailscale netcheck it shows the public IP that tailscale connects with and sees.
what I trying to do is:
I have 2 NICs, one wired and one wireless I want that tailscale only and only connect via the wireless NIC and never try to connect via the wired.
so I add this (wlo1 is the wireless NIC)

[Unit]
Wants=network-pre.target tailgate-allow@wlo1.service

to /etc/systemd/system/tailscaled.service.d/override.conf via systemctl edit tailscaled.service

but when running tailscale netcheck I still see that tailscale uses the public IP of the wired NIC.
also if I look up in ss -tulpn I see that tailscale listens to 0.0.0.0 (see screenshot) I don't think that is a problem but still I thought I would mention this.

and in lsof -Pan -p 9732 -i - 9732 In the PID of my tailscale processes it clearly shows that it connects via the wired NIC because I see the local IP of the interface (see screenshot).

What I expected is when I set tailgate then even if the interface that I chose doesn't have internet tailscale won't connect and just stay disconnected
Thanks!!

[fernandoenzo]

Hello again,

As I suspected, the use of tailscale netcheck is completely irrelevant for this case. Tailgate works by creating a series of iptables rules (which I assume you have installed on your NIC) to block point-to-point (and only point-to-point) tunneled traffic through Tailscale, which means UDP traffic.

Everything else is left as is, and the captures you showed me do not indicate otherwise.

A proper test you could perform to verify that Tailscale connections to your other NIC are being made through the wlo1 interface is as follows:

From the NIC where you are running Tailgate, open a terminal and run tailscale ping -c 0 --until-direct=false nic-b (replace nic-b with the name your other NIC has in your mesh). This will initiate an indefinite ping. You'll see output similar to this:

pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 36ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 34ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 33ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 34ms
...

Now open Wireshark and start analyzing the wlo1 network interface, then add the following filter: udp.dstport == 57428 (replace 57428 with the destination port that appears in the above output). You should then see the traffic flowing between your two NICs, exclusively through your wlo1 interface.

Alternatively, instead of Wireshark, you can use tcpdump. In this case, the command to run would be: sudo tcpdump -i wlo1 udp and dst port 57428.

Best regards!

P.D. By the way, you might be interested in this other project of mine.

[Itay1787]

From the NIC where you are running Tailgate, open a terminal and run ts ping -c 0 --until-direct=false nic-b (replace nic-b with the name your other NIC has in your mesh). This will initiate an indefinite ping. You'll see output similar to this:

pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 36ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 34ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 33ms
pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 34ms
...

Now open Wireshark and start analyzing the wlo1 network interface, then add the following filter: udp.dstport == 57428 (replace 57428 with the destination port that appears in the above output). You should then see the traffic flowing between your two NICs, exclusively through your wlo1 interface.

Alternatively, instead of Wireshark, you can use tcpdump. In this case, the command to run would be: sudo tcpdump -i wlo1 udp and dst port 57428.

Best regards!

Hi, What is the command ts ping as tailscale ping?
if so the syntax is not right...
And nic-b should be the one that I want (wlo1) tailscale to connect through it? or the one that I don't want (enp1s0) to?

P.D. By the way, you might be interested in this other project of mine.

I look into it but I need something like tailscale - that I already use in other parts of my network because this device is going to a remote location and I need backup if the main access to it goes down

[Itay1787]

. Tailgate works by creating a series of iptables rules (which I assume you have installed on your NIC) to block point-to-point (and only point-to-point) tunneled traffic through Tailscale, which means UDP traffic.

I just did a quick test
I connect to tailscale on another device
but the interface on this device wlo1 was down
But I could still ping this device's tailscale IP from the other device, so the tunnel was created and made accessible from the other interface.

[fernandoenzo]

Hi, What is the command ts ping as tailscale ping?

Yes, it was. Sorry for that mistake, I have an alias on my PC alias ts=tailscale, and I just wrote it like that.

And nic-b should be the one that I want (wlo1) tailscale to connect through it? or the one that I don't want (enp1s0) to?

In my example, nic-a (although I didn't actually call it that) would be the device that has the two network interfaces and from which you run tailgate, the one where you have tailgate-allow@wlo1.service, while nic-b would be the other device you want to connect to.

Sorry for the obvious question, but you do have iptables installed, right? In that case, I recommend you run this and send me the output: sudo iptables -S tailgate from the nic-a machine.

Also, when you run the test with tailscale ping, check that it shows something like this:

pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 36ms

instead of something like this:

pong from nic-b (fd7a:115c:a1e0::3) via DERP(mad) in 83ms

It would be great if you could actually copy the output of the command.

[Itay1787]

Sorry for the obvious question, but you do have iptables installed, right? In that case, I recommend you run this and send me the output: sudo iptables -S tailgate from the nic-a machine.

Also, when you run the test with tailscale ping, check that it shows something like this:

pong from nic-b (fd7a:115c:a1e0::3) via 192.168.5.3:57428 in 36ms

instead of something like this:

pong from nic-b (fd7a:115c:a1e0::3) via DERP(mad) in 83ms

It would be great if you could actually copy the output of the command.

In the test I get "via DERP"

 tailscale ping -c 0 --until-direct=false device-b
pong from  device-b (IP of device-b in tailscale) via DERP(fra) in 297ms

iptables -S tailgate

-N tailgate
-A tailgate -o wlo1 -p udp -m udp --sport 41641 -j ACCEPT
-A tailgate -p udp -m udp --sport 41641 -j DROP

[fernandoenzo]

Okay, I understand what's happening. In summary, tailgate is functioning correctly, at least according to my concept of proper functioning. When I programmed tailgate, my goal was to prevent P2P connections from being established through certain network interfaces. These connections always use UDP and the hole punching technique with Tailscale.

However, I never considered DERP relayed traffic, as the DERP should not come into play as long as a P2P connection can be established. DERP relayed traffic occurs via TCP and HTTP:443, and there's no practical way to avoid it.

If your machine has two operational network interfaces and you block one with tailgate, Tailscale will just use the other one for the P2P connection. If your goal is to completely prevent the connection unless it's strictly through the wlo1 interface, then tailgate will only partially achieve your objective. You'd need to add specific rules to your firewall to block all DERP servers of Tailscale on your enp1s0 interface. If you're really up for this challenge (though I personally don't see much point), I suggest checking out the Tailscale Firewall Ports documentation. There you can find a link to download the full list of DERP servers, but keep in mind that this list can change frequently.

[Itay1787]

Okay, I understand what's happening. In summary, tailgate is functioning correctly, at least according to my concept of proper functioning. When I programmed tailgate, my goal was to prevent P2P connections from being established through certain network interfaces. These connections always use UDP and the hole punching technique with Tailscale.

However, I never considered DERP relayed traffic, as the DERP should not come into play as long as a P2P connection can be established. DERP relayed traffic occurs via TCP and HTTP:443, and there's no practical way to avoid it.

If your machine has two operational network interfaces and you block one with tailgate, Tailscale will just use the other one for the P2P connection. If your goal is to completely prevent the connection unless it's strictly through the wlo1 interface, then tailgate will only partially achieve your objective. You'd need to add specific rules to your firewall to block all DERP servers of Tailscale on your enp1s0 interface. If you're really up for this challenge (though I personally don't see much point), I suggest checking out the Tailscale Firewall Ports documentation. There you can find a link to download the full list of DERP servers, but keep in mind that this list can change frequently.

Ok, that makes sense. but blocking all the DERP servers really doesn't make sense... although tailscale shows that UDP is available I don't know why that is.
but I found something weird. that will explain why it doesn't go via the other interface if I unplug the wired from the device and leave only the wifi tailscale don't reconnect. Do you have any idea why that is?
I make sure that there is an internet connection on the wifi interface (ping -I the_wifi_interface google.com)
but it seems that tailscale refuses to work on that interface

[fernandoenzo]

Sorry, but I don't really understand your last message. Can you explain step by step what you're doing, what happens, and what you expect to happen? That might help me get a better idea.

Happy new year! 🎇🎆

[Itay1787]

Sorry, but I don't really understand your last message. Can you explain step by step what you're doing, what happens, and what you expect to happen? That might help me get a better idea.

Happy new year! 🎇🎆

I checked to see if tailscale will switch to wlo1, which is the wifi interface if I disconnect the network cable. And it seems not.
And I don't understand why. And that's probably the reason why it doesn't work properly with tailgate.
because even though its only network interface is the wlo1, it doesn't use it.
I checked to make sure there is a network in the interface using - ping -I wlo1 google.com
So if you have an idea/idea why tailscale won't work with the second network interface - wlo1

I would love to hear.
I expect that if I disconnect the network in the wired connection (enp1s0) then it will switch to using wifi (wlo1)

[fernandoenzo]

I understand your situation, though it seems quite peculiar to me, and I don’t believe tailgate has anything to do with it. The iptables rules it creates are very straightforward.

What stands out to me is that, when you disconnect the network cable, the connection doesn't automatically switch to the wlo1 interface. I also find it odd that the connection is constantly going through DERP instead of a P2P connection.

So, if I understand correctly, when you have the command tailscale ping -c 0 --until-direct=false nic-b running and then you disconnect the network cable, the ping simply stops working? Does it freeze up and give timeouts?

If that's the case, I suggest a simple test. When this happens, after disconnecting the cable, run: systemctl restart tailscaled.service. This might force the service to realize its only option is to operate through wlo1.

Regardless of the outcome of that test, I would recommend you try doing the same thing (running a ping and then disconnecting the network cable) without involving tailgate. See if the same issue persists. I suspect it will continue and that tailgate isn't the cause here.