IPv6 security

[RMerlin]

Ok then. LAN clients still ipv6-pingable, but router is not. Is it right?

Router also is. It's considered a node, just like a computer or a media streamer that also has an IPv6.

I think the point the RFC was making was, if someone has enough time to waste to ping an ISP subnet (or even just a /64) in an attempt to find reachable hosts, then he better be VERY patient in his attempts to find a pingable host Keep in mind that even a simple /64 has more IPs to ping than the whole IPv4 Internet has today. That's 2^64 IPs to ping one by one...

 

[Deleted member 22229]

@ Merlin just noticed you released a new bata 372_32Bata3 Can you tell me what you have changed since bata 1 ? I looked at the release notes but im not a rocket scientist. Thanks. James !!

 

[RMerlin]

@ Merlin just noticed you released a new bata 372_32Bata3 Can you tell me what you have changed since bata 1 ? I looked at the release notes but im not a rocket scientist. Thanks. James !!

Beta 1 was just a snapshot, so I didn't keep track of changes that occurred specifically between Beta 1 and Beta 3 (which is a "real" beta release). Sorry.

On the IPv6 front, the main change was to add support for protocol numbers in firewall rules (in addition to tcp/udp/both).

 

[Deleted member 22229]

Delete problem solved it was not the Merlin firmware.

 

[neil0311]

I have the latest rev 3.0.0.4.374.32 on my RT-N666U.

I have not made any changes from default as far as the IPv6 firewall settings, so it remains enabled. I have enabled IPv6 and it's set for "Native with DHCP-PD" with "Connect to DNS Server Automatically" set to "Enable" and router advertisement is also enabled.

I noticed in the syslog that the "neighbour table overflow" errors are reappearing. I thought those were happening due to no firewall and inbound connections trying to access nodes on the LAN. Are those normal with the IPv6 firewall enabled?

 

[RogerSC]

I have the latest rev 3.0.0.4.374.32 on my RT-N666U.

I have not made any changes from default as far as the IPv6 firewall settings, so it remains enabled. I have enabled IPv6 and it's set for "Native with DHCP-PD" with "Connect to DNS Server Automatically" set to "Enable" and router advertisement is also enabled.

I noticed in the syslog that the "neighbour table overflow" errors are reappearing. I thought those were happening due to no firewall and inbound connections trying to access nodes on the LAN. Are those normal with the IPv6 firewall enabled?

Yes, they are "normal"' apparently. There are some commands that you can build a script from that enlarges the neighbor table, and is a workaround that has been doing the job for me. I'm using the init-start script in /jffs/scripts for this:

#!/bin/sh
echo 512 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
echo 1024 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
echo 2048 > /proc/sys/net/ipv6/neigh/default/gc_thresh3

This does use some memory. My guess from looking at free memory with and without this script is ~1MB. Given that I still have over 190MB of free memory, I don't think that I'll miss 1 or 2MB *smile*. And it is nice not to have the clutter in the system log, or be wondering what could be happening as the result of overrunning the end of a buffer (even though it is apparently detected) or the resources needed to generate messages that could be used in a better way *smile*.

 

[RMerlin]

Personally, I think it's due to how Comcast's network is set up. Looks like all the neighbours connected to the same POI or same node are all visible from one another while on the IPv6 network, causing everyone to see traffic coming from their neighbours, filling up everyone's neighbour table. That's at least my theory on the issue.

Most likely the only fix would be for Comcast to ensure that broadcast traffic doesn't hit neighbours on the same node.

 

[RogerSC]

Personally, I think it's due to how Comcast's network is set up. Looks like all the neighbours connected to the same POI or same node are all visible from one another while on the IPv6 network, causing everyone to see traffic coming from their neighbours, filling up everyone's neighbour table. That's at least my theory on the issue.

Most likely the only fix would be for Comcast to ensure that broadcast traffic doesn't hit neighbours on the same node.

Well, right at the moment, Comcast and Asus appear to be pointing the finger at each other *smile*. The Comcast person says that they don't see it, and that they're talking to Asus about it. And that's the last I've heard for weeks now. So the temporary workaround is looking somewhat permanent. Not holding my breath for a permanent fix...

 

[cmillar6]

Yes, they are "normal"' apparently. There are some commands that you can build a script from that enlarges the neighbor table, and is a workaround that has been doing the job for me. I'm using the init-start script in /jffs/scripts for this:

#!/bin/sh
echo 512 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
echo 1024 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
echo 2048 > /proc/sys/net/ipv6/neigh/default/gc_thresh3

This does use some memory. My guess from looking at free memory with and without this script is ~1MB. Given that I still have over 190MB of free memory, I don't think that I'll miss 1 or 2MB *smile*. And it is nice not to have the clutter in the system log, or be wondering what could be happening as the result of overrunning the end of a buffer (even though it is apparently detected) or the resources needed to generate messages that could be used in a better way *smile*.

How exactly do I get this script to start automatically? Format JFFS and then create a folder called scripts and put your code in it as a text file or something?

 

[RMerlin]

Well, right at the moment, Comcast and Asus appear to be pointing the finger at each other *smile*. The Comcast person says that they don't see it, and that they're talking to Asus about it. And that's the last I've heard for weeks now. So the temporary workaround is looking somewhat permanent. Not holding my breath for a permanent fix...

They probably don't see it because they are testing it internally, with no other customers sitting on the same node with IPv6 IPs. They would most likely need to test it from your specific node.

I don't think Asus is to be blamed there. The router sees what the router sees, and if it sees so many hundreds of different IPv6 MACs filling up its ARP cache, it's because Comcast is allowing these IPv6 MACs to reach your modem (and router) unfiltered.

Oddly, that reminds me of the days of DOCSIS 1, where everyone on a local cablemodem node was more or less one big LAN, with zero firewalling.

 

[wouterv]

Late, but never too late.
Test with the 3.0.0.4.374.32_0-sdk6 build.
Add a IPv6 Firewall rule for a Windows 7 Professional PC, using its (non temporary) IPv6 address and port 3389.
On the computer Remote Desktop must be enabled (duh).

With or without the Windows Firewall [http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php] does find port 3389 Open.
Without the Router Firewall rule the port is reported Offline

This site [http://ipv6.chappell-family.com/ipv6tcptest/] does never find port 3389 open (allways Stealth), with the Windows Firewall Off it can Ping the PC.

Now the funny thing, after I deleted the rule and disabled the Router IPv6 Firewall, [http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php] still report port 3389 as Offline.
And after I enabled the Firewall and added the rule again, port 3389 still reports Offline.
Is a Router reboot after a Firewall On/Off required??

[EDIT] After a single reboot of the router I could effectively and repeatedly toggle the IPv6 Firewall on and off and add or delete the "test" rule and immediately after the Apply and "wating time" see the proper expected test results (Open or Offline).

[EDIT2] The site [http://ipv6.chappell-family.com/ipv6tcptest/] does auto recognise the PC temporary IPv6 address (I do not see the option to specify a IPv6 address), using the temporary IPv6 address in the Router IPv6 Firewall rule gives the proper result: with the rule applied port 3389 shows Open.

[EDIT3] For completeness: I use Hurricane Electric IPv6 "Tunnel 6in4".

 

[RogerSC]

How exactly do I get this script to start automatically? Format JFFS and then create a folder called scripts and put your code in it as a text file or something?

The way that I did this was to select "enable jffs" and "format jffs after next boot" in the "Administration" -> "System" tab, and then click "Apply". At this point you reboot your router, and when it comes back up again, you should have a /jffs file system and a directory /jffs/scripts (and also a directory called /jffs/configs, both are created for you).

Then go to the /jffs/scripts directory, create a file named "init-start" with the contents mentioned in the previous post. I use "vi" for this, since I've been a UNIX/Linux user for a long time *smile*. Then when you're satisfied that the file is there with the right contents, use "chmod" to add execute permissions:

chmod a+x init-start

and you can use:

ls -l

in that directory to verify that the file has been created and has the right permissions.

At this point, run the script to be sure that it works:

./init-start

and then use "cat" to output the contents of the files that you're changing out to the screen to be sure that the script has done what it is supposed to. Now, every time you boot after this, your init-start script will be run.

Also, I'd suggest adding this line to your script:

touch /tmp/init-start.ran

Then you can look at /tmp any time and see that the script ran since you last booted. That's been useful to me with these startup scripts.

I think that's about it.

If the gc_* parameters listed in the previous posting aren't large enough to prevent the messages, then play with the numbers until the messages no longer appear *smile*.

 

[torchddv]

I've been using 3.0.0.4.372.32_beta3 for a couple of weeks now and it has been very stable and reliable.

However, I noticed one oddity: On the Network Map "internet status" window, the Lease Time is permanently "Renewing..." and the Lease Expires is permanently "Expired".

My connection is PPPoE through a radio modem, if that makes a difference.

 

[neil0311]

Personally, I think it's due to how Comcast's network is set up. Looks like all the neighbours connected to the same POI or same node are all visible from one another while on the IPv6 network, causing everyone to see traffic coming from their neighbours, filling up everyone's neighbour table. That's at least my theory on the issue.

Most likely the only fix would be for Comcast to ensure that broadcast traffic doesn't hit neighbours on the same node.

Just getting back to this after being out of town. I do have Comcast. So does this fall into the category of "annoying" but not a risk, or is there a risk associated?

If I'm understanding correctly, it's just a matter of the router seeing lots of IPv6 nodes on the wire which overflows the table, but there's no security risk as long as the IPv6 firewall is enabled.

 

[Deleted member 22229]

No I don't think there is any risk at all its just not right that's all. Also it does not affect the function of ipv6 either that's why I am not to concerned right now. I do have a ComcastSenior Network Engineer,
v6 Project looking into it on the Comcast forums but have not heard much back lately. They say they cant reproduce the issue on there end. Asus ? Comcast ? time will tell.

 

[fr33z0n3r]

Personally, I think it's due to how Comcast's network is set up. Looks like all the neighbours connected to the same POI or same node are all visible from one another while on the IPv6 network, causing everyone to see traffic coming from their neighbours, filling up everyone's neighbour table. That's at least my theory on the issue.

Most likely the only fix would be for Comcast to ensure that broadcast traffic doesn't hit neighbours on the same node.

Actually there isn't any "broadcast" traffic in ipv6. Its multicast and is technically handled differently by receivers. Which leads me to this find.

Is this a related issue/fix in this post?

http://serverfault.com/questions/36...w-on-linux-hosts-related-to-bridging-and-ipv6

I believe your problem is because of a kernel bug that was patched in net-next.

Multicast snooping gets disabled when the bridge is initialized because of a bug trying to rehash the table. IGMP snooping stops the bridge from forwarding every HBH ICMPv6 multicast query reply, which results in the neighbour table filling up with ff02:: neighbours from multicast replies which it should not see (try ip -6 neigh show nud all).

The proper workaround is to attempt to re-enable snooping like: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. The alternative is to make the neighbour table gc thresholds bigger than the number of hosts in the broadcast domain.

 

[Deleted member 22229]

Interesting keep up the effort so I can send Comcast some help with this issue so they can determine if the problem is them or Asus. That's why I believe things have come to crawl as far as a fix. The blame game. Asus is also aware of the issue but there convinced its Comcast.

 

[saintdev]

Actually there isn't any "broadcast" traffic in ipv6. Its multicast and is technically handled differently by receivers. Which leads me to this find.

Is this a related issue/fix in this post?

http://serverfault.com/questions/36...w-on-linux-hosts-related-to-bridging-and-ipv6

I believe your problem is because of a kernel bug that was patched in net-next.

Multicast snooping gets disabled when the bridge is initialized because of a bug trying to rehash the table. IGMP snooping stops the bridge from forwarding every HBH ICMPv6 multicast query reply, which results in the neighbour table filling up with ff02:: neighbours from multicast replies which it should not see (try ip -6 neigh show nud all).

The proper workaround is to attempt to re-enable snooping like: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. The alternative is to make the neighbour table gc thresholds bigger than the number of hosts in the broadcast domain.

All of this is known. The N66U's kernel is too old for the multicast snooping fix. The multicast_snooping sysctl is non-existent. So, raising the gc_thresh is the only way to work around this, but even if you raise it to absurd levels, it still overflows. Currently I have 512, 2048 and 4096 for thresh{1,2,3}, and it still overflows. I've seen others posts where people have even higher thresholds and are still getting overflows.

 

[RMerlin]

What I don't understand is, where is there so many neighbours visible from your WAN interface when using IPv6 specifically on Comcast? I would expect your modem/router to only be exposed to the ISP's router that's fronting you, no?

 

[RogerSC]

All of this is known. The N66U's kernel is too old for the multicast snooping fix. The multicast_snooping sysctl is non-existent. So, raising the gc_thresh is the only way to work around this, but even if you raise it to absurd levels, it still overflows. Currently I have 512, 2048 and 4096 for thresh{1,2,3}, and it still overflows. I've seen others posts where people have even higher thresholds and are still getting overflows.

Using 512, 1024, and 2048, which has been working for me for weeks now. I'm guessing that being in a backwater like Santa Cruz keeps the number of neighbors that I'm exposed to down some. In San Jose, who knows *smile*?

But I was also involved in a discussion with Comcast about this, and Comcast doesn't seem aesthetically attuned to fixing it.