Poor performance with 2.4.1
-
Do you also use in "General DNS Resolver Options" Network Interfaces :: "All" and Outgoing Network Interfaces :: "All" ?
I have WAN selected for outgoing and everything but WAN for the LAN side.
-
@haleakalas:
@JKnott : What is your RTT and RTTsd values under WAN Gateway? Have you seen any significant change from version 234 to 241?
If you have a spare disk with your 234 backup copy and you can swap between 234 and 241 you can quickly get to the bottom of the speed issue.I have never checked RTT etc., so I don't know what they were before. However, as I mentioned in another note, pfSense is flat out failing to resolve external addresses, but appears to be OK for local.
-
I have WAN selected for outgoing and everything but WAN for the LAN side.
Just select All and All and try again. It sounds like you are not actually listening on the address you are specifying.
-
The service status shows DNS Resolver stopped and I can't start it.
The log has several lines of "Oct 30 16:18:37 unbound 95941:0 error: can't bind socket: Can't assign requested address for fe80::214:d1ff:fe2b:edea". That's the link local address for my WAN port.
-
I have WAN selected for outgoing and everything but WAN for the LAN side.
Just select All and All and try again. It sounds like you are not actually listening on the address you are specifying.
That seems to have it working. Why would this change between versions?
-
I have WAN selected for outgoing and everything but WAN for the LAN side.
Finally I found the Resolver corresponding settings which work perfect, fast and no errors in Log.
For me I have set with GUI:
Network Interfaces: LAN, OPT1, OPT2, Localhost
Outgoing Network Interfaces: LocalhostIn unbound.conf that is correctly found as:
Interface IP(s) to bind to
interface: 192.168.1.1
interface: 2001::####:1::1
interface: 10.8.4.1
interface: 192.168.22.1
interface: 2001::####:3::1
interface: 127.0.0.1
interface: ::1Outgoing interfaces to be used
outgoing-interface: 127.0.0.1
outgoing-interface: ::1Besides this, the "All & All" works too, but you probably don't want listening on WAN ;)
My setup in 2.4.1 (upgraded from 2.4.0) about DNS:
- No Forwarding with Resolver
- Nothing set or checked for DNS in [System > General Setup]
- No other DNS config for DHCP(6) servers || RA
-
^^^^
I'll give those a try. DNS through pfSense has now failed completely. -
Didn't work. I still have complete DNS failure with pfSense. I cannot resolve either Internet or local host names. Something is clearly messed up here. Is there any way to revert back to 2.4.0?
-
For a test. Disable resolver and enable forwarder. See what happens.
-
For a test. Disable resolver and enable forwarder. See what happens.
That appears to work, though I no longer have the local hosts available through it.
-
Yeah - I'm having the same troubles on both a pfsense vm and opnsense vm. In vmware with a private IP at wan.
-
If there isn't a fix for the resolver soon, I'll have to copy all my local devices into the forwarder.
-
I think its a resolver specific issue and it will be fixed. til then, I like your fix.
-
No idea what you guys are doing. Resolver works fine in 2.4.1.
-
No idea what you guys are doing. Resolver works fine in 2.4.1.
I updated to 2.4.1. I guess I shouldn't have done that.
-
Resolver works fine.
-
Resolver works fine.
I just tried again and resolver does not work. Forwarder does. I have been using resolver almost since I started using pfSense 1.5 years ago but it now fails.
-
In my case, I think its something in the network at this one place giving unbound trouble. I haven't seen this anywhere else. Since in my case, its just for testing I didn't worry about it much. However in this 1 location both opnsense and pfsense had resolver issues, so I turned it off.
Went with dnsmasq on opnsense and forwarder on pfsense and suddenly it all worked. I think its something strange going on with the machine hosting the VMs in my case because this only happened in one place.
The only things odd about this install is its in vmware and the IP on the WAN is private. Like I said… For testing only, so no public on this one. Other than that, its vanilla as can be.
-
No problems with resolver here..
Prob timeouts with its ULA address.. Because your RA failed and its using your "backup" plan of ULA addresses..
How about some info on how its failing.. So you do a query for www.domainx.com and it doesn't walk down from roots? You looked in the cache of unbound for how it would look up this domain, what it has in its cache, etc. You sniffed on wan and don't see this, but there is nothing in the logs?
example
unbound-control -c /var/unbound/unbound.conf lookup forum.pfsense.org The following name servers are used for lookup of forum.pfsense.org. ;rrset 1279 2 0 7 3 pfsense.org. 1279 IN NS ns2.netgate.com. pfsense.org. 1279 IN NS ns1.netgate.com. ;rrset 1279 1 0 8 0 ns1.netgate.com. 1279 IN A 192.207.126.6 ;rrset 84078 1 0 1 0 ns1.netgate.com. 170478 IN AAAA 2610:160:11:3::6 ;rrset 1279 1 0 8 0 ns2.netgate.com. 1279 IN A 162.208.119.38 ;rrset 84078 1 0 1 0 ns2.netgate.com. 170478 IN AAAA 2610:1c1:3::108 Delegation with 2 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 2610:1c1:3::108 not in infra cache. 162.208.119.38 rto 328 msec, ttl 840, ping 4 var 81 rtt 328, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2610:160:11:3::6 rto 376 msec, ttl 840, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 192.207.126.6 rto 347 msec, ttl 840, ping 7 var 85 rtt 347, tA 0, tAAAA 0, tother 0, EDNS 0 probed. [2.4.1-RELEASE][root@pfsense.local.lan]/root:Is there anything in the log for unbound? Did you up the verbosity of what it logs, etc..
Resolver does not work… Like telling your mechanic - car is broke..
-
For me, I wasn't all that worried because I was more interested in stepping through the menues and comparing menues, options, features of two firewall distros than anything. I need to move several older machines to something else when the AES-NI requirement kicks in.
I wonder what unbound would do if you turned off DNSSEC/hardening? I'm going to try because I suspect for me it could be an ISP issue.
