ipv6 disable on Pfsense

JKnott

@bimmerdriver said in ipv6 disable on Pfsense:

FWIW, Telus has no issues at all with pfSense.

Rogers also works fine with pfSense. The issue is with the CMTS I'm connected to. The people who are responsible for fixing this don't seem to want to as I have my own firewall/router, despite the fact that it also fails in gateway mode, affects a neighbour and even when the senior tech came with his own modem and it also failed. Despite all that and much more, including getting the Office of the President involved, they won't fix it. I even identified the system that failed for them and the senior tech proved it again, when he went to the head end and tested there. Yet they still cancelled the ticket, without making any attempt to fix the problem. Someone is due for some serious disciplinary action.

Derelict

@JKnott Start sending your payments to whatever amounts to your public utilities commission. At least that's how it works here.

Though cable/internet is a little nebulous as to exactly where they fall legislatively and it seems to change depending on wind direction here.

JKnott

@bimmerdriver said in ipv6 disable on Pfsense:

Microsoft, as much as everyone likes to bash them, has embraced IPv6 since the Windows 7

Actually, XP SP3 almost fully supported it. There was some minor thing that didn't work, but it didn't have much effect overall. I know it worked fine for me. My first Android phone, a Google Nexus 1 also supported IPv6 and my current Pixel 2 even has IPv6 tethering, with a full /64 prefix.

sorenstoutner

The option to disable AAAA DNS requests would be nice due to the amount of junk AAAA traffic that is generated otherwise. For example, I have an Icinga service running on a Debian system that looks up clients by DNS name. It issues AAAA lookups for the main domain (which fail because no AAAA record exists) and then appends the default search domain (which also fails). These generate multiple info: query response was NXDOMAIN ANSWER and info: query response was THROWAWAY log entries. Neither my ISP nor the ISPs at many of the locations being monitored provide IPv6. I could save the DNS servers the wasted bandwidth and my log files the wasted entries if I could just turn off AAAA record resolution.

Along those lines, it is considerate not to hammer DNS providers with queries for things that don't exist.

https://www.theregister.com/2021/02/04/chromium_dns_traffic_drop/

johnpoz

@sorenstoutner said in ipv6 disable on Pfsense:

I could just turn off AAAA record resolution.

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..

You can stop unbound fro resolving them - but where you should be able to turn it off is the client.

https://forum.netgate.com/topic/151745/bind-filter-aaaa

I thought there was even a newer thread - but that is the first one that came up searching..

There is a no-aaaa.py you can load right in the gui for specific domains, maybe the script could be edited for any AAAA, and I know pfblocker is doing something with AAAA as of recent updates.

If you run bind you can run the no AAAA

edit: Took me a minute to remember it.. But you can use this in the options box in unbound
server:
private-address: ::/0

unbound still will try to resolve AAAA, but client will not get an answer. So not really the best solution.. Best solution is to get your client to stop asking for AAAA when they can not use them ;) Which if you know of way - happy to hear about it.. Not a fan of that at all - its just noise..

People think - oh its just a simple query, what could it hurt... Well your link to the chrome nonsense they finally fixed is perfect example of what it can hurt..

Related to noise - I am hoping I finally got my phone from constantly asking for stupid lb._dns-sd._udp.blahblah queries.. 100's of them, multiple different iterations.. Was like 2000 some queries a day... I knew it was some app on my phone - but sure which one.. Turned off all the background refresh on everything that I don't specific want.. And they stopped ;)

2000 in 24, not big deal.. But it would forward those to unbound.. I never looked but unbound prob trying to resolve them.. Just stupid noise - no need for it... If you want to look for something - sure ask, but if you don't get the answer you want.. Don't keep asking every 30 freaking seconds ;)

sorenstoutner

@johnpoz

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 ;)

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.