ipv6 disable on Pfsense

sorenstoutner

That should be done on the client.. Which is pretty much impossible even when they don't have ipv6 enabled.. They will still do query for AAAA, pretty stupid if you ask me..

I completely agree. However, it appears that there is no way to do this system-wide on modern Linux.

https://serverfault.com/questions/632665/how-to-disable-aaaa-lookups

The only way to accomplish this is to replace all instances of gethostbyname() with getaddrinfo() in the source code of every single program and then specify the ai_family is AF_INET.

Thanks for the link to the python script. it just seems like this is a lot of work for something where there should be a simple option at the client OS level, and, failing that, there should be a checkbox on the DNS Resolver page to turn it off. For example, if I don't have an IPv6 address on my client, it shouldn't make AAAA queries. And, if I have disabled IPv6 on pfSense, it should also not forward AAAA queries.

johnpoz

Preaching to the choir my brother - sing it ;)

Maybe you missed my edit ;) I hate freaking NOISE!! AAAA queries when you have no IPv6 are NOISE.. Just like freaking windows and their hunger to flood your network with SSDP, and LLMNR.. If I want that shit - let me turn it on ;)

The no-aaaa.py will stop unbound from doing the query.. But I have not looked into an edit to do it for all AAAA.. Might be simple - maybe take a look later. The simple way to just stop your client from getting an answer is with the private-address. But that prob won't stop him from asking and asking and asking.. Like freaking energizer bunnies - dude what about the 10k no answer you got, how about backing of your asking for it...

Dude now you got me started ;) hehehehe

edit: Yeah what they should work, since they got rid of 80Billion queries that were NOISE.. Now how about stopping asking for AAAA when you have no IPv6... I concur unbound shouldn't process them if it has no IPv6 address. Or a simple flag to just turn them off - the filter AAAA in bind does that I believe.

But still doesn't stop all the local noise to local NS when clients keep asking for shit they can not ever use..

Gertjan

@johnpoz said in ipv6 disable on Pfsense:

Might be simple - maybe take a look later.

I'll check this weekend. It's probably an easy fix.

https://unix.stackexchange.com/questions/444282/how-to-disable-ip6-lookups-in-unbound

@johnpoz said in ipv6 disable on Pfsense:

about stopping asking for AAAA

If a process on some LAN based client asks the local resolver, unbound, to look up a A, unbound will look up the A. Same thing for MX, or AAAA.
All this over IPv4.
It might be wise (but probably impossible) to instruct the software we use on our devices to stop asking for AAAA. After all, why asking for a AAAA if IPv6isn't enabled on the device ? or the network doesn't offer IPv6 capabilities ?
Unbound is just doing what it's asked to do, amplifying the noise.

edit : what the heck : this might be easy :

I wrote a new no-aaaa-v2.py version, by only pressing on the delete key.

This is it :

def init(id, cfg):
    return True

def deinit(id):
    return True

def inform_super(id, qstate, superqstate, qdata):
    return True

def operate(id, event, qstate, qdata):
    if event == MODULE_EVENT_NEW or event == MODULE_EVENT_PASS:
        if qstate.qinfo.qtype != RR_TYPE_AAAA:
            qstate.ext_state[id] = MODULE_WAIT_MODULE
            return True

        msg = DNSMessage(qstate.qinfo.qname_str, RR_TYPE_A, RR_CLASS_IN, PKT_QR | PKT_RA | PKT_AA)
        if not msg.set_return_msg(qstate):
            qstate.ext_state[id] = MODULE_ERROR
            return True

        qstate.return_msg.rep.security = 2
        qstate.return_rcode = RCODE_NOERROR
        qstate.ext_state[id] = MODULE_FINISHED
        log_info("no-aaaa: blocking AAAA request for %s" % qstate.qinfo.qname_str)
        return True

    if event == MODULE_EVENT_MODDONE:
        qstate.ext_state[id] = MODULE_FINISHED
        return True

    qstate.ext_state[id] = MODULE_ERROR
    return True

log_info("pythonmod: no-aaaa-v2.py script loaded")

World's smallest py module for unbound.

Copy it here : /var/unbound/no-aaaa-v2.py

Select it under the resolver settings :

And apply the new settings.
Check that your resolver logs are filled with

My network is IPv6 capable, so hundreds of logs lines per minute were shown.
New noise ^^ - to remove all these log lines, remove :

        log_info("no-aaaa: blocking AAAA request for %s" % qstate.qinfo.qname_str)

from the script.

Take note :

When you use no-aaaa-v2.py, you can't use the pfBlockerng-devel py module .
I tested this for 5 minutes or so, and fully confined that there are no bugs, as I only removed lines. I didn't add something. ;)

johnpoz

@gertjan

That seems like a great work around, since yeah its impossible to get the clients to stop asking for it.. Stop it before it goes past your local dns..

If this was done everywhere IPv6 is not in use yet, how many more billions of queries could we stop from going to public dns.. Doesn't stop queries to roots, but would stop AAAA noise to all the authoritative NSs for domainX

And would reduce your overall dns traffic out your internet, be it you resolve or forward.

My PC currently has no IPv6, not even a link-local address.. So why and the F is he asking for AAAA ;)

There is no point to this.. None.. That is what we should be able to turn off..

To stop this - it wouldn't have to be coded in every application. Just the OS dns client, hey I don't have IPv6 address.. No need to ask the NS for AAAA, so noise reduced.. Even if the application asked for it..

edit: Ok to take this to the next level with your V2 of the no-aaaa.py. How do we allow clients that actually have IPv6 to query for AAAA, but clients that do not.. Some sort of filtering of which Clients can ask, this could be done in a view maybe.. This would be good for me where I do have some clients that do have IPv6, and would want to be able to query AAAA, but then many other devices that have no IPv6 that wouldn't want their AAAA to go upstream..

You can not always be sure that NS would be talked to over IPv6, when you have a dual stack client and it has both an IPv4 and IPv6 NS listed.. A IPv6 client could ask for AAAA that it could use from its IPv4 address. Guess you could allow those clients IPv4, and all queries that come in from IPv6 addresses.

edit2: Some clients do it correctly.. Just looked at like my TV, and my Alexa show - with 100's and 100's of queries from them.. I don't see any AAAA queries.. They don't have IPv6.. So seems they are not asking for AAAA.. Which is how it should be.

My thermostat does seem to ask for some AAAA, but only for some internet/dns check its doing for www.google.com.. But it looks to be done only every 6 hours.. My harmony also with no IPv6 doesn't seem to be asking for AAAA.. Possible the devices that are not asking for AAAA have no support for IPv6, at all.. But pretty sure alexa and roku do support IPv6..

Gertjan

@johnpoz said in ipv6 disable on Pfsense:

edit: Ok to take this to the next level with your V2 of the no-aaaa.py. How do we allow clients that actually have IPv6 to query for AAAA, but clients that do not.. Some sort of filtering of which Clients can ask, this could be done in a view maybe..

You're want "v3" which should behave very much like the original no_aaaa version.
Instead of a list with domains that should only be accessed using "A" = IPv4, you want an IP list with local devices/networks for which unbound is allowed to do a AAAA requests.
I'll have a shot at it.

johnpoz

Yeah... This way for example you could list which devices be them IPv4 or IPv6 that can do AAAA queries. you would have to list IPv4 as well as their IPv6 be it global or link-local. Since you really can not be sure what source IP the client might use to talk to NS.. Unless you specifically set a device that has IPv6 to only list IPv6 address for their NS..

If your going to be using IPv6.. Easier to just live with the noise of devices that don't have it asking for AAAA.. But the ability to do such filtering if you wanted to would be pretty slick ;)

A Former User

Looking at the logs on my Pi-Hole I see my LG TV and Plex (hosted on a synology NAS) asking for AAAA records. In context both of them do it after they fail to resolve an A record that is blocked. This is intentional behavior to find a way to 'phone home'. I have ipv6 support turned off in the Plex server settings and in the TV settings.

As stated, it would be best if clients without an ipv6 globally routed address would not even ask.

johnpoz

@jwj said in ipv6 disable on Pfsense:

my LG TV

Hmmm So I looked in more detail to my TCL TV (roku based).. And even shit it asks for that is blocked.. Which is quite a bit ;)

I don't see it asking for any AAAA..

Yeah plex asks for it. And so does NAS - but no IPv6 there at all.. Just stupid.. Like asking for chopsticks to drink your beer with..

And if that chrome article about their stupid dns queries shows us anything - the mentality of oh its a just a simple small little thing, couple of bits here, couple of bits there. In the big picture multiplied by millions or billions of devices doing it.. Its not such a little thing any more..

Even locally this can be a problem - stupid windows boxes and their VAST amount of nonsense noise they put out.. Yeah its not a big deal when you have a few of them.. But when you have say 200 of them on the same L2 - it works out to be a lot of freaking noise on the wire.. That serves no purpose!!

JonathanLee

Have you also attempted to custom option in unbound.conf for DNS responses I have an ISP that only provides IPv4 I do not want to use HE tunnel.

Screenshot 2023-06-22 at 10.35.17 AM.png

Screenshot 2023-06-22 at 10.38.24 AM.png

 "*do-ip4: <yes or no>
          Enable or disable whether ip4 queries are  answered  or  issued.
          Default is yes.

   do-ip6: <yes or no>
          Enable  or  disable  whether ip6 queries are answered or issued.
          Default is yes.  If disabled, queries are not answered on  IPv6,
          and  queries  are  not sent on IPv6 to the internet nameservers.
          With this option you can disable the IPv6 transport for  sending
          DNS traffic, it does not impact the contents of the DNS traffic,
          which may have ip4 and ip6 addresses in it.

   prefer-ip4: <yes or no>
          If enabled, prefer IPv4 transport for sending DNS queries to in-
          ternet  nameservers. Default is no.  Useful if the IPv6 netblock
          the server has, the entire /64 of that is not owned by one oper-
          ator  and  the reputation of the netblock /64 is an issue, using
          IPv4 then uses the IPv4 filters that the upstream servers have.

   prefer-ip6: <yes or no>
          If enabled, prefer IPv6 transport for sending DNS queries to in-
          ternet nameservers. Default is no.

   do-udp: <yes or no>
          Enable  or  disable  whether UDP queries are answered or issued.
          Default is yes.

   do-tcp: <yes or no>
          Enable or disable whether TCP queries are  answered  or  issued.
          Default is yes*" (nlnetlabs nl).

add server: first to let me add anymore lines after. Just like when you enable logging

"Logging:
server:
log-queries: yes" (Docs Netgate).

Same needs server: first

"dns64-ignore-aaaa: <domain name>
List domain for which the AAAA records are ignored and the A record is used by DNS64 processing instead. Can be entered multiple times, list a new domain for which it applies, one per line. Applies also to names underneath the name given" (unbound docs).

So for me ipv4 prefer and other custom options. . .
server:
do-ip4: yes
prefer-ip4: yes
do-ip6: no
prefer-ip6: no
dns64-ignore-aaaa: * . *

Ref:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/dns-queries.html

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html

smolka_J

So far I have found the following to work best on my boxes to remove IPv6 as much as possible resulting in better stability of Unbound no longer crashing or hanging unresponsive at random or when forced performing IPv6 nslookups:

Unbound Custom options:

server:
do-ip4: yes
do-ip6: no
prefer-ip4: yes
prefer-ip6: no
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: ::ffff:0:0/96
private-address: fd00::/8
private-address: fe80::/10
private-address: ::/0
private-address: ::
local-zone: localhost.home.arpa transparent
local-data: "localhost.home.arpa A 127.0.0.1"
local-zone: localhost transparent
local-data: "localhost A 127.0.0.1"
local-zone: ip6.arpa redirect
local-data: "ip6.arpa A 0.0.0.0"
local-zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa redirect
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa A 0.0.0.0"
local-zone: "::/0" static
dns64-ignore-aaaa: *.*
do-not-query-address: ::
do-not-query-address: ::1
do-not-query-address: ::/0

Shellcmd's added to Shellcmd to load at boot:

ifconfig lo0 inet6 ifdisabled
ifconfig igb0 inet6 ifdisabled
ifconfig igb1 inet6 ifdisabled
ifconfig ix0 inet6 ifdisabled
ifconfig lo0 inet6 fe80::1%lo0 delete
ifconfig lo0 inet6 ::1 delete

edit /etc/inc/system.incsearch for 'localhost' around line 331 and comment out - ::1 IPv6 section of lines with /* at beginning, a * for each next line and */ at the end:

/*
* $hosts[] = array(
* 'ipaddr' => '::1',
* 'fqdn' => 'localhost.' . $syscfg['domain'],
* 'name' => 'localhost',
* 'domain' => $syscfg['domain']
* );
*/

edit /etc/hosts.allow comment out line adding a #:

#ALL : [::1] : allow

smolka_J

@smolka_J These last two are system files, these adjustments here aren't saved in config.xml files so if until there is a patch or tick box added, they would need re-applied each system upgrade but do maintain general reboots.

Gertjan

Just a reminder : instead of putting efforts in stopping (using) IPv6, what about adding a solid IPv6 access 'that will work for sure'. I've been using this setup it for years.
The resolver doing it's resolver thing (= pfSense DNS default settings, nothing added).

When the pfSense LAN doesn't have a IPv6 IP, overall IPv6 traffic will be minimal.

This way, the day we'll all assist the "global IPv4 shutdown day" your can stay on the beach.
I'm sure that the ones that will see that day are already born.

johnpoz

@Gertjan said in ipv6 disable on Pfsense:

I'm sure that the ones that will see that day are already born.

hahah - maybe ;) But since I am clearly slowing that down by telling users to turn if off they have problems with it, just ask jknott he will tell you I am single handedly preventing the global adoption of IPv6 hehehe

What is the goal here, if its just to turn off IPv6 - do that.. If pfsense has no IPv6, then clients wouldn't have IPv6. If the goal is to just prevent unbound from handing clients answers to AAAA that is a simple one line in the custom options

private-address: ::/0 # filters out all AAAA !

If you don't want unbound to use IPv6 to do its resolving, then just set this in the custom options box of unbound

do-ip6: no

Do both if you want.

Firefox, and most other browsers are stupid - even if the box they are running on don't have a gua it will still ask for AAAA, its moronic - why should the browser ask for AAAA when it has no IPv6 to talk to it on?

But on firefox you can set this in the about:config

network.dns.disableIPv6

set that to true. Now firefox won't ask for AAAA any more

Gertjan

@johnpoz
Sure. I can image that IPv6 doesn't play well for everybody. After all, there are many out there that still have to discover (... understand) IPv4.

"The day" I was talking about is the day a major company that allow you to host 'things' just don't have any dedicated IPv4 any more to 'offer' your. Or, at a huge monthly $$$$. So, you content will be using multi-homing (many 'sites' using one and the same IPv4, this is what most hosting company use today). This somewhat works, but ones you dicover that 'another site' using the same IPv4 as you does 'ugly' things the IPv4 gets listed somewhere, taking 'down' your site with it.

A typical dedicated server, or VPS, or whatever cloud wants - needs - to have its own IPv4. The day an IPv4 'just for you' becomes more expensive as the product behind is, is the day IPv4 collapses.

I ordered 16 IPv4 a decade ago, I still have them today, most of them are in use. Last January, I was asked to pay a € per month for them. I'm sure this will go up very soon.

JonathanLee

@johnpoz what about this custom dns resolver setting. . .

server:
do-ip4: yes
prefer-ip4: yes
do-ip6: no
prefer-ip6: no
dns64-ignore-aaaa: * . *
do-not-query-address: ::
do-not-query-address: ::1
do-not-query-address: ::/0

Back in my day Professor's said,
"IPv6 is just around the corner, it was researched and developed as an experimental solution in the 90s," the Professors said this in 2002, 2005, and in 2019. It's the year 2023 and my ISP still only gives me an IPv4 address. Yes, well smartphones are what runs primarily IPv6 now, so it did come. Leading to, once higher tertiary educational institutions only teach IPv6 and when IPv4 becomes twightlighted like BISYNC, Ring topology, AppleSoft, or the older 10base cables from the 90s, that's when smartphone technology will matter the most. The thing is IPv6 has started its emergence, we see the smartphones with TB local storage, they even have built in hotspots. We see the home cell based AP wifi systems that come with no RJ45 plugs. I future cast that home networks and office networks with plugs will disappear very soon, and that is when it will put IPv4 into a death spiral.

It has been occurring slowly by way of upgrades. Soon you will just plug your smartphone onto an official hub or KVM and all your virtual software and operating systems like Windows or Mac will boot up and become a desktop, your office software will connect and it will work like it does normally. This is happening, do a Google search for "Windows VM runs on Smartphones," we might not even need a connection it will just beam to the screen next to you. Look at the Cisco Meraki systems, they are helping push this too. Sure the data centers will have plugs however it will be the monster Ciena internet backbone systems with products like Veritas Cloud Access systems with huge PB storage in a single rack. Tintri was a total solid state SAN system that when developed shocked and amazed, now Nutanix has monster SSD SAN products that only run instances of VMs. Let's face it, It's here already and your ISP knows it.

The future for the public and office networks is Smartphones/tablets running on IPv6. Try to leave your smartphone at home and notice what happens, the truth is you can't function without it. What's sad is this field outdated itself, that's Moore's law for you and you can see it's at its finest hour now. I was glad Moore lived long enough to see it start to occur. Sure it will have the hotspots here and there and official work equipment, but the major consumer base will use their smartphones. I am just waiting to see what KVM or keyboard video mouse smartphone adapter/docking product comes out first. Will companies want to adopt it quickly is the question. Look at Raspberry pi it's the size of a credit card. It's the technology that blends both worlds that will be a major winner, like Cisco's Meraki AP/Cellphone based systems they had a model that was licenced to intercept cell frequencies for cyber security/firewalling use years ago for offices.

IPv6 won't outclass IPv4, the smartphone running IPv6 will.

Me I love my IPv4.

johnpoz

@JonathanLee I think you have some redundant settings..

Not sure what the point of do-ipv4 to yes, that is default, setting do-ipv6 no should be enough..

same with the prefer-ipv4, you shouldn't really need prefer-ipv6 no.

if you have do-ipv6 set to no, not sure if these matter

do-not-query-address: ::
do-not-query-address: ::1
do-not-query-address: ::/0

not sure what the point of this is

dns64-ignore-aaaa: .

If unbound is told to not do IPv6, not sure why you would want/need to set that?

JonathanLee

@Gertjan

I am afraid to use the tunnel I have to own this and admit it to you. I want IPv6 I just want it direct from my ISP.

Check out this topic was reading.

https://forums.he.net/index.php?topic=4253.0

Have you see this in the HE forum? It is stating that Google now blocks ipv6 queries from HE tunnels?

". . . Google now seems to block ipv6 queries to search from HE tunnelbroker ASN"

HE also has really bad ratings on yelp I was reading.

https://www.yelp.com/biz/hurricane-electric-fremont

HE is in need of some good reviews from pfSense people that use this service on yelp. I am sure there is a lot of happy Netgate community users that have not posted a review.

Is this service really free? I pay big bucks every month to my ISP. What do they get out of handing out free IPv6 there is got to be some catch for using it, maybe testing and development of the IPv6 network?

johnpoz

@JonathanLee said in ipv6 disable on Pfsense:

I am afraid to use the tunnel I have to own this and admit it to you

I have been using their tunnels for like 13+ years, have never had any issues with it. I am not really a big IPv6 user, normally I have it turned off on my machine.

But just enabled it, tried google via ipv6.google.com and not having any issues.. Not sure who brought up google was blocking HE?

Not having any issues from quick test..

As to yelp - yup where all the network engineers go to see who they should use as ISP for their company ;) heheheh

jdeloach

@JonathanLee said in ipv6 disable on Pfsense:

@Gertjan

https://forums.he.net/index.php?topic=4253.0

Have you see this in the HE forum? It is stating that Google now blocks ipv6 queries from HE tunnels?

". . . Google now seems to block ipv6 queries to search from HE tunnelbroker ASN"

I realize this issue has nothing to do with pfSense or it's functionality but sounds like I'm not by myself.

This now explains why I might be blocked from accessing google.com via ipv6 or ipv4. The error message
says something to the effect that I don't have proper permissions to access "google.com". They are
being very cryptive as to why I no longer have access to their site. It's mainly their search engine that
I'm blocked from. I get various error codes like this "****403. That’s an error.

Your client does not have permission to get URL / from this server. That’s all we know****." At first I thought
it was a Firefox issue since it started right after I upgraded Firefox to latest version but now I'm not
sure.

There were some other error codes last week before they pulled the plug on me.
I'll have to turn off my he.net and see if this clears up.

I do know that he.net is flagged on several spam websites as being a haven for spammers.

johnpoz

@jdeloach said in ipv6 disable on Pfsense:

several spam websites as being a haven for spammers.

They didn't even use to allow smtp over the IPv6 unless you cleared it with them.. But I just checked and I could unblock smtp with just a click.

Any "tunnel" method is a haven for lots of bad people.. Just like every single vpn service on the planet to be honest. How many vpn services get blocked for the same sort of thing.

Not my problem that bad people ruin a good thing for the rest of us..

HE is a free way for you to get IPv6 when your isp doesn't provide it - or their "providing" of it is just shit.. Which is many of the ipv6 deployments I have seen. They will give you a /48 that doesn't change, and even allow you set PTRs for the range of IPs

To be honest not sure why anyone should care if they have IPv6 or not.. Name one resource that you want to access that is only via IPv6.. Until that day comes there is little use for it for your typical home user.

I use it because it interests me, I use to host a ntp server over it - because that was really the only thing I could do to actually make use of it. Now I have it setup to pretty much just play with - my isp doesn't provide any ipv6, and have not seen them even hint at a roadmap or any sort of date when they would.

You know where IPv6 makes sense - when you have billions of devices, like mobile phones. Guess who uses IPv6 - mobile carriers ;) My phone doesn't even get a IPv4 address when its on cell - only IPv6, they use 464XLAT to get you to the IPv4s you want to get to..

I applaud you for wanting to learn about IPv6, I do believe it is the future - but at this current time, there is nothing saying you have to use it. If you don't want to use HE, and your isp doesn't provide IPv6 or its shit deployment. Your only real recourse is either change your ISP.. Or get an ISP that allows you to run your own IPv6.. You could prob get your own space.. Its not free.. But not all that hard, I got my last company their /32 from Arin, just some paperwork to fillout - have to show your going to use it, etc.. And then pay the bill.

I handled setting up all the routing objects for them, etc. They had some project they are working on for connecting cars - again something there are billions of on the planet.

While as mentioned I would hope the kid has been born already that will see IPv4 turned off and IPv6 be the only game in town - or something might actually replace IPv6 who knows.

The problem is IPv4 isn't going away, atleast not any time soon. The IP apocalypse was has gone away because all the players that Need millions and or billions of IP addresses for their devices/projects can use IPv6.. The IPv4 space now sells on the gray market to who is willing to pay for them.. We sold off in my last company a big chunk of our /16 for quite tidy sum.. Because they wanted infux of cash to make that years books look better. And really had no use for the all those IPs.. If the Registries like Arin would actually take back some of the space that companies are hoarding back.. They could most likely allocate those to isp that could actually use them..

But you have nothing to loose with trying to use a HE tunnel, use it to learn IPv6 that is for sure - I would recommend you run through their IPv6 sage program.. You get a free tshirt when you reach sage level ;) You have to setup Ipv6 glue on a domain, and run a smtp server over IPv6, etc.. I don't think it has changed much in the 12 some years ago when I did it.. I still have the tshirt btw ;) But it is a good learning tool for sure.