portmaster
portmaster copied to clipboard
Tailscale works on Fedora 35
I tested tailscale.com. Basic VPN functionally worked but I had to dig into it a bit to make use of it.
I had to:
- allow incomming and outgoing connections to tailscaled
- to use MagicDNS add it to portmaster as
dns://100.100.100.100?search=YOUR.MAIL.PREFIX.beta.tailscale.net&search-only. this allows you to resolvepi.northys.example.com.beta.tailscale.net. ~~3) allow incomming UDP connections to "Network noise" app because tailscale automatically reroutes traffic if it discovers that 2 devices can talk to each other directly over LAN for example. this is actually not good because it allows incomming UDP for "everything" else.~~
What didn't work:
Currently it is not possible to resolve hostnames without northys.example.com.beta.tailscale.net suffix but I hope it is just matter of some additional DNS settings in portmaster. E.g. you can't resolve pi instead of pi.northys.example.com.beta.tailscale.net.
~~MagicDNS which should be listening on 100.100.100.100 but I haven't succeeded adding it to portmaster because there is certainly some kind of magic behind it - it doesn't even listen on 100.100.100.100:53 but it somehow works on devices without portmaster. You can't even dig it on devices without portmaster... MagicDNS is a good name for it :D~~
Hey @northys, thanks for testing this!
I have wanted to try out tailscale for some time now, but haven't yet got around to.
ad 1) As expected. ad 2) This is interesting. If the Portmaster does not detect the tailscaled process, this would mean that the source IP/Port could not be matched to a socket from tailscaled - does tailscale change the IPs/Ports of these packets? Maybe there is a pattern int the used ports that you could use to allow these connections. That this would allow "everything else" is not true per se, as matching listening sockets pretty much works 100% of the time, as these sockets are long-lived.
I've looked into the MagicDNS thing [1,2], but as you said, there is no obvious IP address to point queries to. Since Portmaster v0.8.6, it can configure nameservers that are only used for specific domains.
Maybe we can configure the tailscale resolver with something like this:
dns://<tailscale-magic-dns-ip>?search=beta.tailscale.net&search-only
Parameters used:
- search: specify prioritized domains/TLDs for this resolver (delimited by ,)
- search-only: use this resolver for domains in the search parameter only (no value)
You could try using 100.0.0.1 [3] - just a wild guess. Maybe that works.
EDIT: With all the reading I forgot that you already mentioned 100.100.100.100. Hm. Maybe try to configure that in the Portmaster.
Pinging @bradfitz to help us out here - if you are up to it.
[1] https://tailscale.com/kb/1054/dns/ [2] https://tailscale.com/kb/1081/magicdns/ [3] https://tailscale.com/kb/1015/100.x-addresses/
With all the reading I forgot that you already mentioned
100.100.100.100. Hm. Maybe try to configure that in the Portmaster.
I think that it just needs that search parameter because when you let tailscale configure that automatically it sets search in resolv.conf. I gave up because it did not respond to telnet 100.100.100.100 53 so I thought there is more magic behind it (e.g. tailscaled handling it "magically")
Sadly I can't test it because I've uninstalled it already because I needed to route my traffic through my server (tailscale is capable of it) but I had firewall enabled there and I didn't realize it. The traffic had to go though their relay nodes which had bandwidth of 1Mbps and my home backup server collapsed when first rsync started.
I will try it again on xmas or similar occasion :santa:
I'm missing a lot of context. What's the question?
Hey @bradfitz, thanks a lot for chiming in here.
Context: Portmaster (this repo) is an application firewall. It looks at every connection and matches it to a process. It then applies various rules to the connections to either allow or block them. We are trying to figure out how to run Portmaster and Tailscale together in harmony.
Question 1: Does Tailscale do any raw packet mangling? Ie. using a local IP and Port without opening a socket. (There are incoming UDP connections that could not be attributed to the tailscale process.)
Question 2:
Portmaster employs and enforces Secure DNS (via DoT). It redirects DNS queries to itself to prevent leaking.
For integration with other software, users can configure resolvers with scopes. We'd like to know where to point all the *.beta.tailscale.net (or *.ts.net?) queries to.
For integration with other software, users can configure resolvers with scopes. We'd like to know where to point all the
*.beta.tailscale.net(or*.ts.net?) queries to.
this works dns://100.100.100.100?search=username.beta.tailscale.net&search-only
but I'm unable to use shortnames like when tailscale configures resolving itself. e.g. ssh laptop instead of ssh laptop.username.beta.tailscale.net. this is something i would love to get working.
Does Tailscale do any raw packet mangling? Ie. using a local IP and Port without opening a socket. (There are incoming UDP connections that could not be attributed to the tailscale process.)
I guess I don't understand what you mean by raw packet mangling. Tailscale does a lot of low-level network stuff. It includes its own network stack so sometimes we handle things in wireguard+gvisor without even giving it to the operating system.
Which "incoming UDP connections" are you talking about? the port 53 MagicDNS 100.100.100.100 stuff? Indeed, that we handle in-process. We never bind to that. It's effectively a localhost operation, but it's specifically not a host address.
Question 2: Portmaster employs and enforces Secure DNS (via DoT). It redirects DNS queries to itself to prevent leaking. For integration with other software, users can configure resolvers with scopes. We'd like to know where to point all the *.beta.tailscale.net (or *.ts.net?) queries to.
Well,
$ tailscale status --json | jq -r .CurrentTailnet.MagicDNSSuffix
tailscale.com.beta.tailscale.net
$ tailscale status --json | jq -r .MagicDNSSuffix. # the old way
tailscale.com.beta.tailscale.net
But Tailscale lets you configure your network DNS settings as well, setting up different DNS resolvers for different suffixes, and we apply it across your whole network. And we already transparently upgrade most stuff that's DoH-able to DoH for you.
I imagine you'll be breaking much of Tailscale's DNS support by intercepting it, but maybe that's fine for the users choosing to use both Tailscale and Portmaster. It'd probably be a fair amount of integration on both of our sides to make them integrate well. Likely not worth it.
Indeed, that we handle in-process. We never bind to that. It's effectively a localhost operation, but it's specifically not a host address.
Thanks for clarifying.
Which "incoming UDP connections" are you talking about?
I'm sorry. The statement about UDP connections mentioned in my original post is not true. I badly checked the IP (ends by .3 instead of .2) of mentioned UDP connection. It's incomming by different server in my LAN.
There is no need to change incomming rules of Network noise app to allow tailscaled connect through LAN.
@dhaavi I have edited my original post. I've also added information about how to set DNS based on your suggestion.
@dhaavi do you have any idea how to configure portmaster to resolve short hostnames within tailscale network?
this is how tailscale configures resolv.conf on my raspberry where it works
root@pi-1 ~ # cat /etc/resolv.conf
# Generated by resolvconf
search northys.example.com.beta.tailscale.net
nameserver 100.100.100.100
using this configuration I can ping pi-1 and northys-fedora like this
root@pi-1 ~ # ping northys-fedora
PING northys-fedora.northys.example.com.beta.tailscale.net (100.99.88.77) 56(84) bytes of data.
64 bytes from northys-fedora.northys.example.com.beta.tailscale.net (100.99.88.77): icmp_seq=1 ttl=64 time=4.58 ms
64 bytes from northys-fedora.northys.example.com.beta.tailscale.net (100.99.88.77): icmp_seq=2 ttl=64 time=73.9 ms
64 bytes from northys-fedora.northys.example.com.beta.tailscale.net (100.99.88.77): icmp_seq=3 ttl=64 time=96.8 ms
^C
--- northys-fedora.northys.example.com.beta.tailscale.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.584/58.448/96.837/39.219 ms
root@pi-1 ~ # ping pi-1
PING pi-1.northys.example.com.beta.tailscale.net (100.99.88.66) 56(84) bytes of data.
64 bytes from pi-1.northys.example.com.beta.tailscale.net (100.99.88.66): icmp_seq=1 ttl=64 time=0.179 ms
64 bytes from pi-1.northys.example.com.beta.tailscale.net (100.99.88.66): icmp_seq=2 ttl=64 time=0.169 ms
^C
--- pi-1.northys.example.com.beta.tailscale.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.169/0.174/0.179/0.005 ms
but on my laptop which runs portmaster I have to ping full hostname like this
northys at northys-fedora in ~
» ping pi-1.northys.example.com.beta.tailscale.net
PING pi-1.northys.example.com.beta.tailscale.net (100.99.88.66) 56(84) bytes of data.
64 bytes from 100.99.88.66 (100.99.88.66): icmp_seq=1 ttl=64 time=4.01 ms
64 bytes from 100.99.88.66 (100.99.88.66): icmp_seq=2 ttl=64 time=5.30 ms
^C
--- pi-1.northys.example.com.beta.tailscale.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 4.006/4.655/5.304/0.649 ms
short hostname won't resolve
northys at northys-fedora in ~
» ping pi-1
ping: pi-1: Name or service not known
Thanks @bradfitz and @northys for your input.
I've looked into it and everything seems to work as intended now. Steps taken:
- Add a global resolver in Tailscale dashboard:
192.0.2.1.- (This is a documentation IP that will never resolve anything)
- Enable Tailscale's Magic DNS in the Tailscale dashboard.
- Find the Magic DNS domain name in the Tailscale dashboard.
- It takes the form of
username.provider.beta.tailscale.net.
- It takes the form of
- Configure this domain name in the Portmaster as an additional DNS Server:
- Adapt to your Magic DNS domain name:
dns://100.100.100.100?search=username.provider.beta.tailscale.net&search-only&name=Tailscale Magic DNS
- Adapt to your Magic DNS domain name:
- Add Incoming Rule to the Tailscape app within Portmaster:
Allow *
That is all! Note that not all utilities expand the short names of other devices to the full Magic DNS domain name. Eg. works with ping, but not with dig.
Not tested:
- Services
- Access Control
- Exit Nodes (routing all traffic through another device)
I guess I don't understand what you mean by raw packet mangling. Tailscale does a lot of low-level network stuff. It includes its own network stack so sometimes we handle things in wireguard+gvisor without even giving it to the operating system.
Yup. That is what I meant.
MagicDNS 100.100.100.100 stuff? Indeed, that we handle in-process. We never bind to that.
I see. Thanks for the info.
$ tailscale status --json | jq -r .CurrentTailnet.MagicDNSSuffix tailscale.com.beta.tailscale.net
Very helpful. Thanks!
But Tailscale lets you configure your network DNS settings as well, setting up different DNS resolvers for different suffixes, and we apply it across your whole network. And we already transparently upgrade most stuff that's DoH-able to DoH for you.
Very nice. Did not know that and haven't seen it mentioned during the installation or configuration process.
I imagine you'll be breaking much of Tailscale's DNS support by intercepting it, but maybe that's fine for the users choosing to use both Tailscale and Portmaster. It'd probably be a fair amount of integration on both of our sides to make them integrate well. Likely not worth it.
I think stuff like the Exit Nodes might require more work, but the core Tailscale stuff seems to work pretty well!
As mentioned above, I just used 192.0.2.1 as a global nameserver, which works great.
Would me more intuitive to use something like 127.0.0.1, but the UI did not like that. (Error'ed without explanation.)
Also, that might be confusing for regular Tailscale users. Maybe allow it, but add a warning to it?
I think stuff like the Exit Nodes might require more work, but the core Tailscale stuff seems to work pretty well!
Yup, today I've switched to tailscale completely and disabled my wireguard network everywhere. We'll see whether i stick to using it.
I tried to enable exit node (which works from my raspberry and intel nuc without portmaster) on my laptop and I couldn't ping anything. Sadly I don't have enough knowledge to debug it myself so I won't bother you with it now unless I learn more about tcpdump and iptables.
Hey :) is there any way for arch? Magic DNS with the above settings works perfectly fine on fedora, Debian. But not with arch. As soon I start tailscale I can't get any DNS resolution.
pinging hostnames without FQDN resolved by using systemd-resolved exclusively. this sets search correctly and allow everything to work as expected.
see https://tailscale.com/kb/1235/resolv-conf/
systemd-resolved stub resolv.conf symlink in /etc
northys at northys-beast in ~
» ll /etc/resolv.conf
lrwxrwxrwx 1 root root 39 úno 12 20:27 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
stub resolv contains search
northys at northys-beast in ~
» cat /etc/resolv.conf | grep search
# configured search domains.
search tail7365c.ts.net
closing as it looks like everything seems to work now.
i am using portmaster with tailscale on arch, DNS and subnets work fine but if i connect to an exit node everything stops working.
no DNS unable to ping external IPs there is no traffic i tried with both tailscale and my own headscale server but there is no difference.
do you know what could be the cause of this?