Domain overrides not working (was working until I noticed just now)
-
@kevindd992002 Then change Site1 also and look if your assumption was correct?
-
@bob-dig change Site 1 to what? Are you suggesting changing the whole local domain of site 1?
-
Also, the packet captures on both sites 2 and 3 do not show the packets being forwarded to the destination dns server when the domain override is home.arpa. So technically you can ignore site 1.
-
This post is deleted! -
@kevindd992002 Have you added the other subnets to the Access List in site 1?
"By default, IPv4 and IPv6 networks residing on internal interfaces of this firewall are permitted. Additional networks must be allowed manually." -
@steveits yes, I did. Also, the wireguard service does this automatically for you. And like I said, it works when I forward to the site1 dns resolver for another domain, do ACLs are not the problem.
-
@kevindd992002 Hmm, home.arpa is a special domain (https://www.iana.org/domains/arpa) so maybe that is confusing things? I wonder if myhome.home.arpa or something like that would behave differently.
-
@steveits said in Domain overrides not working (was working until I noticed just now):
@kevindd992002 Hmm, home.arpa is a special domain (https://www.iana.org/domains/arpa) so maybe that is confusing things? I wonder if myhome.home.arpa or something like that would behave differently.
Exactly. home.arpa is what people should be using in their home environment. That is its purpose. And I'm 100% sure this was working not too long ago so something changed with unbound in maybe 2.5.2 and above.
-
@jimp I replied to the bug I filed here:
https://redmine.pfsense.org/issues/13065?tab=history
-
Any other ideas here?
When I try to do a DNS Lookup on the firewall of sites 2 and 3, I don't even see the home.arpa domain being listed under Status -> DNS Resolver. This is another indication that the query is somehow being dropped if it's for the home.arpa domain.
-
@kevindd992002 said in Domain overrides not working (was working until I noticed just now):
I don't even see the home.arpa domain being listed under Status -> DNS Resolver
Well then you don't have your domain override setup... Once you setup a domain overrride it would be there all the time, ask unbound how it would lookup home.arpa.
Actually do a query and it would be listed..
Once you do a lookup - it would be listed in the dns resolver status.
And then if I ask unbound again - it would be listed in cache.
Be it that IP even answers for that domain or not, etc.. - mine sure doesn't - I don't even have 192.168.9.42 device..
-
As I mentioned on the Redmine entry there is nothing special about home.arpa in pfSense other than it being the default domain name under System > General Setup. When it is that domain, it has special settings in unbound automatically but if you have changed that then it wouldn't treat it any differently.
You'll need to post a lot more of your setup here. It could be any number of things. Missing routes in the routing table for the firewall itself to reach places both ways. Missing ACLs in Unbound to allow queries from the other sites. Something wrong in your unbound config or domain override. There are lots of moving parts to get this working between sites and it's even harder with WireGuard since more of it is manually managed than with other methods.
- Check the routing table on each node and ensure it has routes over the appropriate WireGuard interfaces for the appropriate destinations
- Check the WireGuard interface firewall rules to ensure the traffic will pass between the hosts (remember to cover both the LAN(s) and the WireGuard interface addresses)
- Check if you can ping the remote firewall LAN addresses with a source of Localhost and the LAN since that's how you setup Unbound, e.g.
ping -S 127.0.0.1 <other fw LAN IP address>andping -S <this LAN IP address> <other fw LAN IP address> - Check Services > DNS Resolver, Access Lists tab and ensure there are entries there for the other firewall LANs and the WireGuard interface subnets. Some of those may be automatically added, check
/var/unbound/access_lists.confto confirm - When you ping or send traffic across, check the contents of the state table to ensure the states are on the correct interfaces with the expected addresses
- Your outbound NAT rules are over-matching, they will NAT traffic out an interface with its own address, which can break some things. You have it set to port 53 but even so it's better to make sure you aren't doing it unnecessarily. Make a specific rule for localhost as a source that will NAT all outbound, not just port 53. You shouldn't need to NAT traffic from the LAN that should be handled by routing, no need for NAT.
- Compare the contents of
/var/unbound/host_entries.confand/var/unbound/domainoverrides.confand look for instances of the domains in question and ensure they match up as expected.
If all else fails, from all of the firewalls involved post the entire contents of
/var/unbound/unbound.conf,/var/unbound/domainoverrides.conf,/var/unbound/host_entries.conf,/var/unbound/access_lists.conf, the output ofifconfig -aandnetstat -rnalong with the contents of/tmp/rules.debug(at least for the wireguard interfaces and localhost). You can redact private info as long as it's done consistently so that people can identify the same address in different places (e.g. 192.168.10.x -> xxx.xxx.xx.x, 192.168.20.x -> xxx.xxx.yy.x, and so on). -
@johnpoz said in Domain overrides not working (was working until I noticed just now):
@kevindd992002 said in Domain overrides not working (was working until I noticed just now):
I don't even see the home.arpa domain being listed under Status -> DNS Resolver
Well then you don't have your domain override setup... Once you setup a domain overrride it would be there all the time, ask unbound how it would lookup home.arpa.
Actually do a query and it would be listed..
Once you do a lookup - it would be listed in the dns resolver status.
And then if I ask unbound again - it would be listed in cache.
Be it that IP even answers for that domain or not, etc.. - mine sure doesn't - I don't even have 192.168.9.42 device..
I do have it though:
[2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: unbound-control -c /var/unbou nd/unbound.conf lookup home.arpa The following name servers are used for lookup of home.arpa. forwarding request: Delegation with 0 names, of which 0 can be examined to query further addresses. It provides 1 IP addresses. 192.168.10.1 not in infra cache.But I still don't see anything in System -> DNS Resolver for either
192.168.10.1orhome.arpa. When I do a second lookup, it's not being put into cache too:[2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: unbound-control -c /var/unbound/unbound.conf lookup home.arpa The following name servers are used for lookup of home.arpa. forwarding request: Delegation with 0 names, of which 0 can be examined to query further addresses. It provides 1 IP addresses. 192.168.10.1 not in infra cache. -
@kevindd992002 seems your not actually doing a query to unbound then... If it did it would answer, or atleast show it in the cache that it talked to your NS your pointing it too.
Lets see your actual dns query to something in home.arpa.
Here I setup dns query logging, and replies in the custom option box
server:
log-queries: yes
log-replies: yesThen I did a query for for something in home.arpa
$ dig @192.168.9.253 something.home.arpa ; <<>> DiG 9.16.27 <<>> @192.168.9.253 something.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2609 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;something.home.arpa. IN A ;; Query time: 0 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Tue Apr 19 00:28:56 Central Daylight Time 2022 ;; MSG SIZE rcvd: 48
If your not seeing it actually put into the cache, then it never saw a query for it, and never had to cache it..
-
@jimp said in Domain overrides not working (was working until I noticed just now):
As I mentioned on the Redmine entry there is nothing special about home.arpa in pfSense other than it being the default domain name under System > General Setup. When it is that domain, it has special settings in unbound automatically but if you have changed that then it wouldn't treat it any differently.
You'll need to post a lot more of your setup here. It could be any number of things. Missing routes in the routing table for the firewall itself to reach places both ways. Missing ACLs in Unbound to allow queries from the other sites. Something wrong in your unbound config or domain override. There are lots of moving parts to get this working between sites and it's even harder with WireGuard since more of it is manually managed than with other methods.
- Check the routing table on each node and ensure it has routes over the appropriate WireGuard interfaces for the appropriate destinations
- Check the WireGuard interface firewall rules to ensure the traffic will pass between the hosts (remember to cover both the LAN(s) and the WireGuard interface addresses)
- Check if you can ping the remote firewall LAN addresses with a source of Localhost and the LAN since that's how you setup Unbound, e.g.
ping -S 127.0.0.1 <other fw LAN IP address>andping -S <this LAN IP address> <other fw LAN IP address> - Check Services > DNS Resolver, Access Lists tab and ensure there are entries there for the other firewall LANs and the WireGuard interface subnets. Some of those may be automatically added, check
/var/unbound/access_lists.confto confirm - When you ping or send traffic across, check the contents of the state table to ensure the states are on the correct interfaces with the expected addresses
- Your outbound NAT rules are over-matching, they will NAT traffic out an interface with its own address, which can break some things. You have it set to port 53 but even so it's better to make sure you aren't doing it unnecessarily. Make a specific rule for localhost as a source that will NAT all outbound, not just port 53. You shouldn't need to NAT traffic from the LAN that should be handled by routing, no need for NAT.
- Compare the contents of
/var/unbound/host_entries.confand/var/unbound/domainoverrides.confand look for instances of the domains in question and ensure they match up as expected.
If all else fails, from all of the firewalls involved post the entire contents of
/var/unbound/unbound.conf,/var/unbound/domainoverrides.conf,/var/unbound/host_entries.conf,/var/unbound/access_lists.conf, the output ofifconfig -aandnetstat -rnalong with the contents of/tmp/rules.debug(at least for the wireguard interfaces and localhost). You can redact private info as long as it's done consistently so that people can identify the same address in different places (e.g. 192.168.10.x -> xxx.xxx.xx.x, 192.168.20.x -> xxx.xxx.yy.x, and so on).Let me put as much information as I can. Let's forget site 3 for now and focus on sites 1 (main) and 2 (remote site). Also, I have to say that the site 1 also has a domain override for condo.arpa and it's working fine. The one that's not working is the site 2 domain override for home.arpa. Both sites have very similar configs.
- Routing tables are fine. I have the static routes set on both sides:
Site1:
Site 2:
- WG interface FW rules are also fine:
Site 1:
Site 2:
NOTE: I have 0.0.0.0/0 there because it is needed when I'm routing local traffic to the Internet via the remote site (or vice versa).
- Ping
From site 1:
[2.6.0-RELEASE][root@pfSense.home.arpa]/root: ping -S 127.0.0.1 192.168.20.1 PING 192.168.20.1 (192.168.20.1) from 127.0.0.1: 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=6.967 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=4.985 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=5.029 ms 64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=4.638 ms [2.6.0-RELEASE][root@pfSense.home.arpa]/root: ping -S 192.168.10.1 192.168.20.1 PING 192.168.20.1 (192.168.20.1) from 192.168.10.1: 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=6.866 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=4.910 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=4.991 ms 64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=4.873 msFrom site 2:
[2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: ping -S 127.0.0.1 192.168.10.1 PING 192.168.10.1 (192.168.10.1) from 127.0.0.1: 56 data bytes 64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=5.569 ms 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=4.970 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=4.767 ms 64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=4.899 ms [2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: ping -S 192.168.20.1 192.168.10.1 PING 192.168.10.1 (192.168.10.1) from 192.168.20.1: 56 data bytes 64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=5.584 ms 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=7.065 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=6.707 ms 64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=4.988 ms- ACL's are fine -> see attached files
NOTE: 10.0.3.0/29 and 10.0.3.0/30 are redundant, I know, but I had to put in a manual entry because there seems to be a bug in WireGuard for DNS Resolver ACL's (which I already reported here)
- States look ok and are on the correct interfaces with the expected addresses when pinging from LAN. Here's an example when pinging from localhost:
Site 1:
Site 2:
- I didn't know there was such a thing as over-matching. I thought it's always better to be more specific in NAT or FW rules. What is the disadvantage of over matching? I changed the outbound NAT rules as per your suggestion but want to understand more about why I needed to do this:
Site 1:
Site 2:
- Contents of
/var/unbound/host_entries.confand/var/unbound/domainoverrides.conf-> see attached files
Site 1:
/var/unbound/host_entries.conf-> no instances of condo.arpa which is expected (because the domain override should take care of this)
/var/unbound/domainoverrides.conf-> condo.arpa domain override is thereSite 2:
/var/unbound/host_entries.conf-> no instances of home.arpa which is expected (because the domain override should take care of this)
/var/unbound/domainoverrides.conf-> home.arpa domain override is thereSo with all these information, I guess I'm already at the "if all else fails" stage. Here are the contents of the files you mentioned for both sites 1 and 2:
-
@johnpoz said in Domain overrides not working (was working until I noticed just now):
@kevindd992002 seems your not actually doing a query to unbound then... If it did it would answer, or atleast show it in the cache that it talked to your NS your pointing it too.
Lets see your actual dns query to something in home.arpa.
Here I setup dns query logging, and replies in the custom option box
server:
log-queries: yes
log-replies: yesThen I did a query for for something in home.arpa
$ dig @192.168.9.253 something.home.arpa ; <<>> DiG 9.16.27 <<>> @192.168.9.253 something.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2609 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;something.home.arpa. IN A ;; Query time: 0 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Tue Apr 19 00:28:56 Central Daylight Time 2022 ;; MSG SIZE rcvd: 48If your not seeing it actually put into the cache, then it never saw a query for it, and never had to cache it..
Yes, that's exactly what's happening. From what I can see, the query is not even being generated on the unbound side.
Ok, so I added those custom options and did a query from the site2 pfsense shell as you did:
[2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: dig @127.0.0.1 pfsense.home.arpa ; <<>> DiG 9.16.26 <<>> @127.0.0.1 pfsense.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53992 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pfsense.home.arpa. IN A ;; AUTHORITY SECTION: home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Apr 19 13:38:52 PST 2022 ;; MSG SIZE rcvd: 105 [2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: dig @192.168.20.1 pfsense.home.arpa ; <<>> DiG 9.16.26 <<>> @192.168.20.1 pfsense.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23318 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pfsense.home.arpa. IN A ;; AUTHORITY SECTION: home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 ;; Query time: 1 msec ;; SERVER: 192.168.20.1#53(192.168.20.1) ;; WHEN: Tue Apr 19 13:39:36 PST 2022 ;; MSG SIZE rcvd: 105
See how I'm getting NXDOMAIN replies. It seems as if it doesn't see the domain override setting even if it's there. If I query directly against the remote NS server (192.168.10.1), no issues:
[2.7.0-DEVELOPMENT][root@pfSense.condo.arpa]/root: dig @192.168.10.1 pfsense.home.arpa ; <<>> DiG 9.16.26 <<>> @192.168.10.1 pfsense.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46639 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pfsense.home.arpa. IN A ;; ANSWER SECTION: pfsense.home.arpa. 3600 IN A 192.168.10.1 ;; Query time: 37 msec ;; SERVER: 192.168.10.1#53(192.168.10.1) ;; WHEN: Tue Apr 19 13:41:08 PST 2022 ;; MSG SIZE rcvd: 62 -
@kevindd992002 your site one says its domain is home.arpa
local-zone: "home.arpa." transparent
-
@johnpoz said in Domain overrides not working (was working until I noticed just now):
@kevindd992002 your site one says its domain is home.arpa
local-zone: "home.arpa." transparent
Correct.
Site 1 = home.arpa
Site 2 = condo.arpaThe domain override for home.arpa is in Site 2 and that's where the problem is. Was I missing something?
-
@kevindd992002 said in Domain overrides not working (was working until I noticed just now):
- Routing tables are fine. I have the static routes set on both sides:
Site1:
Site 2:
That route shows
0for its usage, it isn't being hit. The traffic isn't using the route, so where is it going? Do you have some other config that is conflicting, like an IPsec tunnel going to192.168.10.0/24perhaps?- WG interface FW rules are also fine:
Those are "Allowed IPs" entries, not firewall rules. Though if you have
0.0.0.0/0in those then all other entries are redundant and can be removed.- Ping
That looks good at least, though again it's odd if that route shows 0 usage and yet you're getting traffic to the other side. Maybe that screenshot was from after the counters were reset somehow.
- ACL's are fine -> see attached files
Yes, those look OK.
- States look ok and are on the correct interfaces with the expected addresses when pinging from LAN. Here's an example when pinging from localhost:
Looks OK with that ping but what about when you attempt a DNS query? What about when you ping from the LAN address?
- I didn't know there was such a thing as over-matching. I thought it's always better to be more specific in NAT or FW rules.
You want to be as specific as possible, if you're over-matching, it's not specific enough.
What is the disadvantage of over matching? I changed the outbound NAT rules as per your suggestion but want to understand more about why I needed to do this:
That isn't following my suggestion, the problem is "This Firewall" is a macro which includes every IP address on the firewall. This includes the address of the WG interface itself as well as the LAN interface address. If you source a packet from the WG interface it will get NAT applied to itself unnecessarily and it can break things. You don't want to NAT from the WG interface itself or from the LAN, the routing will handle those. You only want to NAT from "Localhost" (
127.0.0.1) which is different from "This Firewall".Next up is to check the states and do packet captures on each interface along the way (e.g. WG on both sides, or other interfaces if you don't see it) and make sure the DNS query is going where you think it's going in both directions. You can also increase the logging level in the DNS Resolver advanced options which might give some more clues.
Something else I noticed in your rules.debug is that on the site1 location you have a DNS redirect NAT rule setup which also has NAT reflection enabled which is probably not what you want. Especially with a destination of
anywhich is a very bad idea. Again it's over-matching and likely grabbing traffic you don't want, like this traffic for instance.rdr on igb1 inet proto { tcp udp } from ! $DirectDNS to any port 53 -> $DNS # Reflection redirect rdr on { igb2 tun_wg0 openvpn WireGuard } inet proto { tcp udp } from ! $DirectDNS to 192.168.20.0/24 port 53 -> $DNS rdr on igb0 inet proto { tcp udp } from any to site2-externalIP port 62958 -> $epsilonNote that by having reflection enabled it's also grabbing inbound DNS on WireGuard and sending it to whatever is in your
DNSalias table which isn't listed in rules.debug.Your redirect rule should probably (a) have reflection disabled, and (b) be configured closer to the example in the docs, specifically the destination: https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
Port forwards with a destination of
anyare almost never a good idea. -
@jimp said in Domain overrides not working (was working until I noticed just now):
@kevindd992002 said in Domain overrides not working (was working until I noticed just now):
- Routing tables are fine. I have the static routes set on both sides:
Site1:
Site 2:
That route shows
0for its usage, it isn't being hit. The traffic isn't using the route, so where is it going? Do you have some other config that is conflicting, like an IPsec tunnel going to192.168.10.0/24perhaps?Yeah, the initial screenshot was just from when the counters were reset. Here's an updated screenshot:
I don't have any other tunnels setup for this subnet, so there is no conflict.
- WG interface FW rules are also fine:
Those are "Allowed IPs" entries, not firewall rules. Though if you have
0.0.0.0/0in those then all other entries are redundant and can be removed.Oops, sorry about that. The Allowed IP's act as both ACLs (for incoming traffic) and allowed "routes" (for outbound traffic) so I thought they were the "rules" you were looking for. And yes, you're right,
0.0.0.0/0encompasses all so I technically no longer need the other entries there. Here are the actual FW rules:Site 1:
Site 2:
There are no rules in the "WireGuard" tab for both sites so
reply-to's will work.- Ping
That looks good at least, though again it's odd if that route shows 0 usage and yet you're getting traffic to the other side. Maybe that screenshot was from after the counters were reset somehow.
Is the
Usescounter counting number of states established?- States look ok and are on the correct interfaces with the expected addresses when pinging from LAN. Here's an example when pinging from localhost:
Looks OK with that ping but what about when you attempt a DNS query? What about when you ping from the LAN address?
When I attempt a DNS query,
A. From site 1 firewall, querying condo.arpa:
B. From site 2 firewall, querying home.arpa -> NO RESULTS
When pinging from LAN address:
A. Site 1:
B. Site 2:
- I didn't know there was such a thing as over-matching. I thought it's always better to be more specific in NAT or FW rules.
You want to be as specific as possible, if you're over-matching, it's not specific enough.
What is the disadvantage of over matching? I changed the outbound NAT rules as per your suggestion but want to understand more about why I needed to do this:
That isn't following my suggestion, the problem is "This Firewall" is a macro which includes every IP address on the firewall. This includes the address of the WG interface itself as well as the LAN interface address. If you source a packet from the WG interface it will get NAT applied to itself unnecessarily and it can break things. You don't want to NAT from the WG interface itself or from the LAN, the routing will handle those. You only want to NAT from "Localhost" (
127.0.0.1) which is different from "This Firewall".I see what you mean. I corrected those now.
Site 1:
Site 2:
Next up is to check the states and do packet captures on each interface along the way (e.g. WG on both sides, or other interfaces if you don't see it) and make sure the DNS query is going where you think it's going in both directions. You can also increase the logging level in the DNS Resolver advanced options which might give some more clues.
I've shown the states above when I do a DNS query. When Site 1 is querying for condo.arpa, the domain override works so states are showing. This is not true when Site 2 is querying for home.arpa.
Site 1:
A. Capture on localhost when querying pfsense.condo.arpa:12:24:30.640552 IP 127.0.0.1.9999 > 127.0.0.1.53: UDP, length 36 12:24:30.641060 IP 127.0.0.1.53 > 127.0.0.1.9999: UDP, length 52 12:24:31.028241 IP 127.0.0.1.35889 > 127.0.0.1.53: UDP, length 36 12:24:31.028720 IP 127.0.0.1.53 > 127.0.0.1.35889: UDP, length 52 12:24:31.029375 IP 127.0.0.1.54054 > 127.0.0.1.53: UDP, length 36 12:24:31.029667 IP 127.0.0.1.53 > 127.0.0.1.54054: UDP, length 52 12:24:31.030131 IP 127.0.0.1.18428 > 127.0.0.1.53: UDP, length 36 12:24:31.030304 IP 127.0.0.1.53 > 127.0.0.1.18428: UDP, length 36 12:24:31.030537 IP 127.0.0.1.47366 > 127.0.0.1.53: UDP, length 46 12:24:31.030809 IP 127.0.0.1.53 > 127.0.0.1.47366: UDP, length 123 12:24:31.031119 IP 127.0.0.1.18099 > 127.0.0.1.53: UDP, length 36 12:24:31.031261 IP 127.0.0.1.53 > 127.0.0.1.18099: UDP, length 36 12:24:31.031436 IP 127.0.0.1.37977 > 127.0.0.1.53: UDP, length 46 12:24:31.031619 IP 127.0.0.1.53 > 127.0.0.1.37977: UDP, length 123B. Capture on WG interface when querying pfsense.condo.arpa:
12:26:26.188805 IP 10.0.3.1.43481 > 192.168.20.1.53: UDP, length 47 12:26:26.189563 IP 10.0.3.1.24105 > 192.168.20.1.53: UDP, length 47 12:26:26.194062 IP 192.168.20.1.53 > 10.0.3.1.43481: UDP, length 47 12:26:26.194097 IP 192.168.20.1.53 > 10.0.3.1.24105: UDP, length 47Site 2:
A. Capture on localhost when querying pfsense.home.arpa:12:27:35.525603 IP 127.0.0.1.16565 > 127.0.0.1.53: UDP, length 35 12:27:35.526020 IP 127.0.0.1.53 > 127.0.0.1.16565: UDP, length 94 12:27:39.027161 IP 127.0.0.1.56750 > 127.0.0.1.53: UDP, length 35 12:27:39.027517 IP 127.0.0.1.53 > 127.0.0.1.56750: UDP, length 94 12:27:39.027732 IP 127.0.0.1.42970 > 127.0.0.1.53: UDP, length 46 12:27:39.027965 IP 127.0.0.1.53 > 127.0.0.1.42970: UDP, length 122 12:27:39.028494 IP 127.0.0.1.17799 > 127.0.0.1.53: UDP, length 35 12:27:39.028648 IP 127.0.0.1.53 > 127.0.0.1.17799: UDP, length 94 12:27:39.028783 IP 127.0.0.1.59727 > 127.0.0.1.53: UDP, length 46 12:27:39.028931 IP 127.0.0.1.53 > 127.0.0.1.59727: UDP, length 122 12:27:39.029293 IP 127.0.0.1.61116 > 127.0.0.1.53: UDP, length 35 12:27:39.029532 IP 127.0.0.1.53 > 127.0.0.1.61116: UDP, length 94 12:27:39.029707 IP 127.0.0.1.41930 > 127.0.0.1.53: UDP, length 46 12:27:39.030151 IP 127.0.0.1.53 > 127.0.0.1.41930: UDP, length 122 12:27:39.030708 IP 127.0.0.1.17114 > 127.0.0.1.53: UDP, length 35 12:27:39.030890 IP 127.0.0.1.53 > 127.0.0.1.17114: UDP, length 94 12:27:39.031112 IP 127.0.0.1.9021 > 127.0.0.1.53: UDP, length 46 12:27:39.031393 IP 127.0.0.1.53 > 127.0.0.1.9021: UDP, length 122B. Capture on WG interface when querying pfsense.home.arpa -> NO RESULTS
Something else I noticed in your rules.debug is that on the site1 location you have a DNS redirect NAT rule setup which also has NAT reflection enabled which is probably not what you want. Especially with a destination of
anywhich is a very bad idea. Again it's over-matching and likely grabbing traffic you don't want, like this traffic for instance.rdr on igb1 inet proto { tcp udp } from ! $DirectDNS to any port 53 -> $DNS # Reflection redirect rdr on { igb2 tun_wg0 openvpn WireGuard } inet proto { tcp udp } from ! $DirectDNS to 192.168.20.0/24 port 53 -> $DNS rdr on igb0 inet proto { tcp udp } from any to site2-externalIP port 62958 -> $epsilonNote that by having reflection enabled it's also grabbing inbound DNS on WireGuard and sending it to whatever is in your
DNSalias table which isn't listed in rules.debug.Your redirect rule should probably (a) have reflection disabled, and (b) be configured closer to the example in the docs, specifically the destination: https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
Port forwards with a destination of
anyare almost never a good idea.Ok, I corrected those as well:
Site 1:
Site 2:
The DNS alias is my standalone DNS (AdGuard Home).
Good catch on the NAT reflection part. Although, I have the sources from the other side of the tunnel (AdGuard Home and WG interface) added to the
DirectDNSalias so they get excluded from being redirected when NAT reflection was still enabled. Since I have NAT reflection disabled on the rules now, I can cleanup and remove those extraneous entries in the alias.
