Update
-
Yeah, again, perhaps I mispoke. I do not have any manually-added DNS entries on my system, only what comcast assigns me via DHCP on the WAN ports. No ipv6 provided (they used to be there).
I don't mind using the comcast-provided entries - I have tried many but the comcast ones tend to me my lowest-latency DNS for me.
And, if I didn't mention this before, it's my own modem so no comcast gateway in the lineup.
Thanks!
[ed: spelling and clarity]
-
Unless you put unbound into forwarding mode, those are not used.. But does seem you uncheck for pfsense to use itself for dns, the 127.0.0.1 - so pfsense wouldn't even be able to resolve any of your own stuff for say the firewall log, etc.
-
After I posted that, I noticed I had the 2 check boxes enabled (DNS Override and Disable DNS Forwarder). I disabled them and rebooted. The ipv6 address I was pulling on the WAN is gone and all the comcast DNS entries are now gone. But, unfortunately, 127.0.0.1 never showed back up. Now where did I screw up :-(
I am using DNS resolver but not DNS Forwarder - is that reversed perhaps?
Edit - I forgot to recheck localhost in the settings - now it's there (127.0.0.1). Going to test.
-
There is the forwarder dnsmasq, and then there is using the resolver (unbound) in forwarder mode..
Unbound (resolver mode default) will resolve no matter if you have anything listed in dns servers or not. But pfsense will not be able to resolve anything if you do not have something there.. 127.0.0.1 is all that is needed so pfsense can resolves stuff.. Like to grab the package list, to check for update. To resolve stuff in the firewall log, etc.
Both of those should be unchecked really
-
Thanks - both are unchecked - I had also unchecked localhost below when i set up resolver years ago with the 127.0.0.1 causing problems (and I do mean years ago). I remember it causing me problems, but can't recall what problem. I am set up as such:
-
I personally set unbound to only use my outbound (localhost) and specifically set which interface it listens on.. But all works too. but setting only localhost makes sure that the query is natted via which interface your going outbound on, be it wan, or vpn, etc.
I also set my zone type to static - this prevents anything in your local zone from being attempted to be resolved if there is no local entry.
So for example I use local.lan as my local domain, if I tired to lookup lsjlsjfldf.local.lan it would try and resolve that if set for transparent.. Which I don't want..
-
Thanks! Adjusted accordingly!
Now, I have a ipv6 address on the WAN side, it's assigned a default gateway (so V4 to V4 and V6 to V6). Unbound is running,. Have rebooted modem and the pfsense box. I can query ipv6 DNS entries just fine. The WAN side is set for DHCP for v4 and v6). I have the LAN set to track changes (prefix ID as 0). I am asking for a /64 and have checked the Request a ipv6 prefix using a ipv4 address and send a ipv6 prefix hint. From a PC, i can issue a DNS query and get returned V4 and V6 info and can nslookup a ipv6 address (it resolves) so i think that part is good. But, other than the link local address on the pc, I do not see another ipv6 address. If I hit test-ipv6.com, says I do not have a ipv6 address.
But, if I ping a ipv6 from inside pfsense Diagnostics->Ping (google.com for example), that works so from the WAN out is OK, just somthing on the LAN to WAN side. I see the default rule on the LAN side allowing ipv6 out.
edit: spelling
-
I also flirted with a /60 (prefixID of 1) and checking and unchecking the request prefixID only (no addresses) checkbox on the WAN interface screen. Didn't seem to alter the behavior (but per the logs, looks like I can ask for a /60). FYI, this is comcast.
-
@slk2k
More trying things out -Once I turned on dhcpv6 (made no changes on this screen other than that) and enabled RA (stateless), now I get IPs on the pc and can ping ipv6. Is that the correct way to do this??
Thanks!
Update - that didn't last long - I have a IPv6 address, just fails to function now (pings fail).
-
You don't need dhcpv6 at all if you don't want it.
Also to clear up something said a while back.. You do not need ipv6 dns to query for IPv6 address.. Those are just AAAA records, and have zero to do be it over ipv4 or ipv6 to query for that..
Pings fail how? You get a timeout, what - it doesn't resolve?
What are you trying to ping exactly? And via fqdn or IP, and what happens?
-
Sorry I wasn't more clear. Pings fail to an external fqdn of ipv6 or ipv6 address from a pc. (google.com now is a ipv6 only address) - nslookup returns both the A record and AAA record, so that works just fine. The pings do times out. But ipv6 from pfsense works so it's something on the lan->wan transition (or back) that's not working. Using dhcpv6 and RA's is the correct thing to do?
-
-
-
If ping to an external address fails, but is OK to a local address, then you have a routing problem.
-
I just got home from work and decided to undo everything (go back to ipv4), reboot pfsense, set up ipv6 again (using dhcpv6 and RAs on the LAN), reboot again, then reboot the PCs. Now everything works. Will see if it persists over an hour or so).
I do have a few questions I hope you can indulge me on so I get a better understanding of what certain configs mean.
-
Using DHCPv6 and RAs. As implied, that functions much like traditional ipv4. But what is the alternative? Without those settings I only had a link-local address on the LAN side with no routes.
-
When performing external ipv6 testing (using https://test-ipv6.com/), I only get a 9/10 as teh testing states that the test is unable to reach ipv6-only DNS servers. I know it's not a problem and I realize that A and AAAA records can come from any DNS server that responds, but was wondering if there is anything else I should change to adjust that.
While typing up the email, I see my V6 WAN IP is now pending instead of Online (it was online). Did I miss another setting somewhere?? At the PC layer, things still work (ping and web traffic) and from pfsense, I can ping ipv6 addresses.
Thanks!!
Shawn -
-
that the test is unable to reach ipv6-only DNS
Might be a minor issue, as I see also often (technical support page - right top corner) :
Site(s) with failed connectivity Site Failed URL ........ https: https://ipv6.test-ipv6-vm3.comcast.net/images-nc/knob_green.png?&testdomain=test-ipv6.com&testname=sites&testdomain=test-ipv6.com&testname=sites(hint : there is a 'comcast' in there)
Your hiding a local IP .... like 192.168.1.1 ;)
This IP, what is it ?
What about using gateway and it's real IPv6 ? -
I understand that the LL address is technically the local address but just being cautious. But, I am unsure why the WAN_DHCP6 address is a LL and not a real address.
The failing address I have says it's a different URL:
But was only curious as to why it was flagged in the technical details.
So far everything still works, just not sure why the gateway address is a LL address versus a real IP.
-
But, I am unsure why the WAN_DHCP6 address is a LL and not a real address.
Link local addresses are used a lot in IPv6. For example, routers are often connected to via the link local address. Given a DHCP request doesn't have to leave the local network, there's no need for a "real" address.
-
Just surprised that comcast uses a link local address when they are giving out huge subnets for ipv6.
-
I'm on Rogers and they do the same thing. The point to remember is that a device only needs to know how to reach the next hop. A link local address is fine for that. In fact, on a point to point connection, you only need the interface that connects to the next hop. No need for any address then.
Also, by using link local, you're not wasting a precious global address.
Seriously, this is one of the areas where IPv6 differs from IPv4, in that link local addresses are used extensively, including for next hop routers. Part of this is security. By using a link local address, things like router advertisements can't come from anywhere else beyond the router. Another security feature is the hop limit is set to 255, which also makes it impossible for a packet to come from beyond the local LAN.
