Just like other linux OS’s you can add these lines to /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
sudo sysctl -p
And that does nothing to disable IPV6, because you have to disable IPV6 at kernel boot time.
Here is what works, in ipfire, to turn off IPV6 with kernel load option.
edit /etc/default/grub
Add this line:
GRUB_CMDLINE_LINUX_DEFAULT=“ipv6.disable=1”
change this line:
GRUB_CMDLINE_LINUX=“rd.auto panic=10 console=tty1”
to this:
GRUB_CMDLINE_LINUX=“rd.auto panic=10 console=tty1 ipv6.disable=1”
once the file is saved, apply changes to boot loader with command:
grub-mkconfig -o /boot/grub/grub.cfg
Then reboot, log back in and test to see if it worked..
ls -al /proc/sys/net/ipv6/
ls: cannot access ‘/proc/sys/net/ipv6/’: No such file or directory
ls -al /proc/net/if_inet6/
ls: cannot access ‘/proc/net/if_inet6/’: No such file or directory
Admittedly you always need to look at the connected devices to see if they use IPV6 or not, many modern devices do by default - but has ipv4 as well, and if IPFire does not use it the only address range that will be practically usable is of course IPV4.
Encapsulation is, generally speaking, putting one thing inside another. So, when talking about IPv6 and IPv6, you can embed an IPv6 packet inside IPv4. The other end will receive the IPv4 packet, remove the encapsulation and see the IPv6 packet.
Similar stuff goes on in IPsec where IPv4 packets are embedded in ESP packets, and, going further, if you’re using NAT, the ESP is then embedded in a UDP packet.
You don’t need to as they are already added to that file.
Incorrect.
The IPFire initscript for sysctl checks if sysctl.conf is present, and applies all the defined settings, so it will also be applied at reboot.
Anyway folks, I apologize for such a late reply, and I probably should have better explained my self in the The first post.
I’ve already run into, and solved, the same issue on another linux OS that uses lilo bootloader, not grub. I also had to disable IPv6 with the bootloader in elilo.conf with append=“ipv6.disable=1”
It depends on what you mean by “disabled”. Starting on line 30 of /etc/sysctl.conf you’ll see:
30 # Disable IPv6 by default.
31 net.ipv6.conf.all.disable_ipv6 = 1
32 net.ipv6.conf.default.disable_ipv6 = 1
33
34 # However, enable some IPv6 hardening sysctl's in case this system is run customly _with_ IPv6.
35 net.ipv6.conf.all.accept_redirects = 0
36 net.ipv6.conf.default.accept_redirects = 0
This means that the kernel is being explicitly told not to use IPv6. No IPv6 addresses being used, no routing, nothing.
Apache is however configured to be able to use IPv6 only if enabled by the kernel.
Yes you’re correct that you will see these tcp6 sockets and proc files because the kernel does load the IPv6 module at boot. It just doesn’t use it.
To stop the kernel from loading the module at all you will need to edit grub as you have. Though it’s probably not worth it. Little to no gain.
This is yet another classic chicken-and-egg problem - the User installs an add-on on their own and then wonders why something is enabled in this specific Configuration that isn’t even present in the default IPFire Configuration ^^
By the way, in my opinion, a Webserver like the aforementioned Apache - which is ideally also accessible via WAN - has absolutely no business being on a Firewall like IPFire
get an dedicated Device - connect it on the Orange Interface and then let it serve from there what you want… that’s exactly what the Orange Interface from IPFire is designed for!
I don’t think this to be another chicken-and-egg problem, but a misguidance by the chicken, i.e. by ipfire.
Because I find not only tcp6 … LISTENs at :81, :444 and :1013, but an ESTABLISHED at :444, too, on both of my ipfire appliances (one is x86, the other ARM). And I have only hostapd and mc addons installed.
30 # Disable IPv6 by default.
31 net.ipv6.conf.all.disable_ipv6 = 1
32 net.ipv6.conf.default.disable_ipv6 = 1
33
34 # However, enable some IPv6 hardening sysctl’s in case this system is run customly with IPv6.
35 net.ipv6.conf.all.accept_redirects = 0
36 net.ipv6.conf.default.accept_redirects = 0
These methods are more for a temporary/partial disable of IPV6.
The only way to disable the IPV6 stack completely, is with the bootloader.
I disable IPV6 in ipfire, and my workstations..
In my workstations I run statefull firewalls with ipv4 and iptables. The advantage for me to disable all IPV6, is so I don’t have IPV6 leaks in my firewall rules, and I don’t have to worry about both ip6table and iptable rules… other than the 3 conditional ip6table rules to drop all ipv6 traffic.
Let’s go through this again to clear up any misunderstandings. I think we’re all seeing the same thing, just interpreting it slightly differently.
Yes, that’s a tcp6 connection in netstat but look at the addresses: they’re both IPv4 (192.168.2.2 and 192.168.2.8).
This happens because Apache (which serves the IPFire web UI on port 444) creates an IPv6 wildcard socket (:::444). On Linux, this kind of socket is dual-stack and can accept both IPv6 and IPv4 connections. But even though the socket is IPv6-compatible, the actual traffic here is just IPv4 from your LAN PC to the web UI because IPv6 is disabled at the kernel level.
Just to show what a default IPFire install looks like, here’s what I see:
This is the IPv6-compatible socket listening using the :::444 wildcard.
But there are no IPv6 connections active:
# ip -6 addr show
→ returns nothing (no IPv6 addresses)
The two sysctl lines in /etc/sysctl.conf are the way IPFire disables IPv6. They stop IPv6 addresses and routing on all interfaces (red0, green0, blue0, orange0, wg0, etc.). The IPv6-compatible sockets are still there, but only IPv4 traffic will ever use them.
The bootloader method (ipv6.disable=1) is cleaner if you want the whole IPv6 module gone, but as I mentioned, it gives little to no gain.
do you know, how I could keep kernel from loading IPV6 stack on ARM appliances using uboot (udev file structure), too? At least my Nanopi R4S bases on uboot, although grub is still there, but obviously not used.
You are my god damn fu.. hero !! Thank you very much for this great information!
I don’t know exactly when it was (long time ago), but I mean it was even here at ipfire, where I read it that a pure IPv4 firewall would be useless if ipv6 is active before and behind it.
Over the years it has been said again and again here in forum, nothing can happen, locks were installed and ipv6 is disabled. Because I do a lot with VPN and Proxies, I have always noticed inconsistencies, for example, how does the VPN device get its Ipv6 DNS address if there is nothing in the config about it?
Well, since today I don’t have to worry anymore, because now even with activated IPV6 protocol in the VPN device no longer IPV6 is assigned. Exactly now I know nothing can happen!
sorry, but you are not quite right. To be more concrete: As long as you consider >10W power consumption for your ipfire appliance, you are right fully. But if you want to save power, any unnecessary CPU action gets to be interesting.
E.g. unnecessary packet checking, unnecessary logging, and the unnecessary handling of the IPV6 stack.
Maybe it seems a bit small-minded, but there are actually some people, who like to pay 10€ or $ per month for watching and controlling a couple of homes externally rather than the 100+ of the bigger players in this market.
I haven’t done this myself, so take this copy/paste advice from an arch linux post with caution. verify!
To disable IPv6 in U-Boot, you can add the parameter “ipv6.disable=1” to the bootargs variable in the U-Boot command shell. This will ensure that IPv6 is disabled when the system boots.
In most/all of the listening sockets, you can force them to listen on IPv4 sockets.
-example for apache
change in listen.conf
listen 81
listen 444
to
listen 0.0.0.0:81
listen 0.0.0.0:444
