Tailscale with pfsense exit node, no DNS
-
You do not assign a tailscale interface. For NAT, i do have an outbound NAT as so.
That is the Tailscale IP i received when i added my pfsense as an exit node. Because you do not assign an IP, the Interface wont be listed in the outbound NAT rule for the NAT address but that's ok you just add the pfsense TS address.
-
@michmoor I tried to add it and same result, no dns when useing exit node! I can ping all ip's and I can acess all ip's by direct ip... but no dns resolved...
Is that the only rule? you don't need to add rules to the intercace? And in outbound didn't you add rules with the tailscale IP to other interfaces?
Are you using dns unbound?
Thank you
-
@Soloam I dont need rules on the interface because traffic isn't directed to pfsense itself.
I only needed an outbound NAT if i am trying to reach other devices in my tailnet coming from my LAN behind my firewall. Thats the reason for the Outbound NAT. I don't fully know your topology so that "may" be required or not in your case.When i select my pfsense as an exit node all that is happening is that DNS resolution gets done by the tailscale DNS server which in my case is 100.100.100.100. After that , traffic is simply forwarded to pfsense and out to the Internet. Traffic leaving your pfsense to the internet will be sourced as coming from the WAN address itself hence no reason for any additional NAT rules.
Are you using split DNS? In other words, are you trying to access internal domains to your LAN? Or is internal and external domains not resolving? With internal domains, you would use tailscale split DNS feature and that should point to your pfsense if your pfsense is doing DNS for you internally.
Lastly, is pfsense offering itself to be an exit node?
-
@michmoor yes my pfsense is advertised as exit node and I use spli dns to my local network... Dns resolution does not work with public and private dns... One thing that I noticed with a tcpdump is that no request arrive to my pfsese 100.100.100.100 on port 53 when I'm on exit onde on another node!
I found somthing interresting!
On my vm taht i use as a exit node... when I turn on exit node on my phone, I see this connections appear on pfsense:
When I do the same with pfsense I don't see any connection!
-
@Soloam This is why i said earlier this seems more of a headscale than pfsense.
Trying to understand your pcap but who is 100.100.100.100? Is that your controller?
Just looking at the 2nd row in the states snippet, traffic from 192.168.2.159 gets SNAT to 100.64.0.1 which makes sense for traffic leaving your pfsense and towards your tailnet. The destination is 100.100.100.100:853 but SYN_SENT:CLOSED indicates that the client is not responding to those TCP SYN messages (3way handshake). Thats a question for you. Why isn't that IP responding if that is your DNS server? If your DNS server is your pfsense as you stated then why isn't it responding.
Something seems off but don't know where.UDP on port 53 seems to work according to the states.
Forgetting headscale for a moment.
If your client is on your tailnet, it should send DNS to pfsense which is the tailnet DNS controller in your set up? -
@michmoor said in Tailscale with pfsense exit node, no DNS:
eems to work according to the sta
100.100.100.100 is the dns server used by tailscale, it's the dns responsible for all the responses inside a tailscale network...
-
I'm starting to belive that this might be related to the fact that I updated the tailscale client on pfsense! The package version is outdated and was not compatible with headscale that required a minimum version of 1.80.2, the one installed was 1.79. I'll wait for the package to be updated before investing more time into this!
Thank you for the help
-
@Soloam can you downgrade the pfsense package? If so that would rule out some things
-
@michmoor not using headscale, the main reason for me to upgrade the tailscale client was to be able to connect to headscale!
-
I experienced the same problem (couldn't resolve names) using pfsense as exit node after I upgraded tailscale client on pfsense connecting to headscale. To troubleshoot:
- I turned off and on advertise-exit-node on pfsense.
- on headscale, I disable / enable the route
It worked for a few hours and then stopped working.
I also experienced routing problem from hosts behind pfsense to other hosts meshed through tailscale. I downgraded headscale and tailscale client on pfsense. It has been working fine since this morning.
-
@Defiling2063 What version did you downgraded headscale to make it work with default tailscale client?
-
0.23.0.
I may be able to run an later version but that was the version I upgraded from before thing went south. I reverted the upgrade.
p/s wish I saw this thread before I upgraded headscale and tailscale client on pfsense. That would have saved me a week of pulling hair. Cheers.
-
I believe I am experiencing the same issue. I recently set up a fresh tailnet and added pfsense as an exit node. The exit node works except when Tailscale DNS is enabled on the client, in which case DNS breaks. This problem doesn't occur when other exit nodes are used.
Package Versions:
headscale 0.25.1
pfSense-pkg-Tailscale 0.1.4
tailscale (freebsd pkg on pfsense) 1.80.3 -
Linking relevant threads on the Tailscale GitHub and Lawrence Systems forum which describe related issues (it looks like @Soloam has participated in all of these).
If anyone having a similar problem bumps into this, please take a minute to document your experience so that we can collect more information and try to solve this. Thanks
-
@jacobhall said in Tailscale with pfsense exit node, no DNS:
Linking relevant threads on the Tailscale GitHub and Lawrence Systems forum which describe related issues (it looks like @Soloam has participated in all of these).
If anyone having a similar problem bumps into this, please take a minute to document your experience so that we can collect more information and try to solve this. Thanks
This problem, from what I can tell, only happens on people using headscale, because we have to change the tailscale client version on pfsense...With Tailscale services the tailscale client on the pfsense package works and it seams to be imune to this problem
-
Not sure if related, but there are some TestFlight builds which include DNS fixes.
-
@elvisimprsntr I'd be willing to try it out. When my client uses pfSense as an exit node, it can ping 100.100.100.100, but DNS queries to the same IP address time out. This makes me think there is an issue with the pfSense/FreeBSD implementation specifically.
-
I don't seem to have a problem with DNS when using pfSense or NAS docker container as an exit node, but I am not using headscale.
PFSENSE
- 2.7.2 CE
- Tailscale package 1.4.0
- Tailscale 1.80.3_1
- Advertise sub-net routes and exit node enabled
- Accept DNS from control server enabled
NAS
- TrueNAS SCALE 24.10.2
- Tailscale docker app 1.2.14
- Tailscale 1.80.3
- Advertise sub-net routes and exit node enabled
- Accept DNS from control server enabled
ADMIN CONSOLE
- Nameservers: Magic DNS
- Global nameservers, Local DNS settings: pfSense LAN IP
- Search domains: tailnet, pfSense domain
- Advertise sub-net routes and exit node enabled for both pfSense and NAS
CLIENT
- iOS 18.4 RC
- Tailscale 1.81.193 via TestFlight
-
1.82.0 is released with some MagicDNS fixes.
I manually updated my NAS docker container.
tailscale update rebootGive it a few days for a FreeBSD package to be available.
-
@elvisimprsntr I'll give it another try once that version makes it to Google Play, but at first glance this appears to be an unrelated bugfix. I have been experiencing this issue using a v1.82.0 client on Linux, which should include the patch you mention. My pfSense box is currently running 1.80.3, so maybe it's worth testing 1.80.3_1 in case that makes a difference.
I agree with @Soloam above that this is likely an issue only experienced by headscale users. Regardless, I think it's the pfSense package that requires fixing as my other exit nodes running Linux have not had any issues. I don't have the time right now to delve into the Tailscale, FreeBSD, and pfSense codebases at the moment, but I hope to support this bugfix however I can.
I am hopeful someone on this forum can help contextualize this issue in terms of pfSense's DNS system and point us (me) in the right direction for contributing a fix.
