Questions about tunnel - unreliable ipv6 operation, lots of incoming icmp

[bimmerdriver]

I got ipv6 working last night (http://www.tunnelbroker.net/forums/index.php?topic=2813.0). It has been unreliable, however, and I'm not sure why. According to the router, the tunnel is operational and carrying traffic in both directions. There are ipv6 leases and the pc thinks it has both ipv4 and ipv6 connectivity. However, I can't reliably access ipv6 websites and both http://test-ipv6.com/ and http://ipv6-test.com/ are intermittently passing and failing. Any suggestions on what to look at?

Also, since I got the tunnel up, there have been a lot of incoming icmp "attacks" on the ipv6 gateway address. By "a lot", I mean thousands. Is this normal? I'm wondering if I should create a different tunnel.

[broquea]

Define icmp "attacks"? The system will ping your client ipv6 address a handful of times to check latency and put up on the "lowest latency users on $pop" page. Also did the tunnel get turned up on your edge device or something behind NAT? Could be a conntrack issue if its on a device behind NAT, needing you to use something like an ongoing ping or fetching ntp updates over ipv6 as a keepalive.

[bimmerdriver]

Define icmp "attacks"? The system will ping your client ipv6 address a handful of times to check latency and put up on the "lowest latency users on $pop" page. Also did the tunnel get turned up on your edge device or something behind NAT? Could be a conntrack issue if its on a device behind NAT, needing you to use something like an ongoing ping or fetching ntp updates over ipv6 as a keepalive.

I am using the word "attack" only because the router (sophos utm) is using that terminology. Here are a couple of screen captures to show what I mean. The two bursts of "attacks" correspond to when I had ipv6 connectivity. It was down all day. The router is connected directly to a modem, not another router, so it has its own ipv4 address. When you say the system will ping the client a handful of times, define a handful.

[broquea]

handful = Like 5 times every 24hrs
Perhaps a pcap on the tunnel interface and verify its icmpv6 traffic coming at you?

[bimmerdriver]

Please take a look at my other thread http://www.tunnelbroker.net/forums/index.php?topic=2813.0. I think I have incorrectly set it up. Not sure why it works at all, or am I just confused?

[kasperd]

I am using the word "attack" only because the router (sophos utm) is using that terminology.

Are they using such a misleading terminology on purpose?

Here are a couple of screen captures to show what I mean.

ICMP type 1 and 2 are indeed unassigned. But that has nothing to do with IPv6 whatsoever since IPv6 use ICMPv6 rather than ICMP. Additionally unassigned types don't sound like attacks at all, since they are just going to be ignored by the recipient. And why the distinction between unassigned type and unassigned type + undefined code? When the type is unassigned there isn't any registry of valid codes for that type.

It may be that the "firewall" is incorrectly using the ICMP type registry for ICMPv6 packets. They are two different protocols, and the type numbers have different meaning. In ICMPv6 type 1 and 2 are some of the most commonly used types. In particular type 2 is required for correct PMTU discovery. Without type 2 being forwarded, you'll experience TCP connections to some servers stall as soon as you start pushing enough traffic to fill up a TCP payload.
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml#icmpv6-parameters-1

[bimmerdriver]

I am using the word "attack" only because the router (sophos utm) is using that terminology.

Are they using such a misleading terminology on purpose?

Here are a couple of screen captures to show what I mean.

ICMP type 1 and 2 are indeed unassigned. But that has nothing to do with IPv6 whatsoever since IPv6 use ICMPv6 rather than ICMP. Additionally unassigned types don't sound like attacks at all, since they are just going to be ignored by the recipient. And why the distinction between unassigned type and unassigned type + undefined code? When the type is unassigned there isn't any registry of valid codes for that type.

It may be that the "firewall" is incorrectly using the ICMP type registry for ICMPv6 packets. They are two different protocols, and the type numbers have different meaning. In ICMPv6 type 1 and 2 are some of the most commonly used types. In particular type 2 is required for correct PMTU discovery. Without type 2 being forwarded, you'll experience TCP connections to some servers stall as soon as you start pushing enough traffic to fill up a TCP payload.
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml#icmpv6-parameters-1

Thanks for the reply. I'm sure there is a reason for them using the word "attack", but I will give them the benefit of the doubt that they are not trying to mislead. I think the distinction between ICMP and ICMPV6 is a distraction because that is the name of the firewall rule, not an actual logged message. It could be that the author of the rule was generalizing the name of the rule.

[kasperd]

Thanks for the reply. I'm sure there is a reason for them using the word "attack", but I will give them the benefit of the doubt that they are not trying to mislead.

Wasn't this software from a vendor of security solutions, who could benefit from customers thinking they are under attack?

I think the distinction between ICMP and ICMPV6 is a distraction because that is the name of the firewall rule, not an actual logged message. It could be that the author of the rule was generalizing the name of the rule.

Where does the "unassigned type" message come from? Evidence suggests these are normal ICMPv6 packets, which should never have been blocked in the first place. They may very well have been looked up against the wrong registry. Why else would it have listed them as unassigned? Can you get a dump of the packets in question, so we can see what they look like?

[bimmerdriver]

Thanks for the reply. I'm sure there is a reason for them using the word "attack", but I will give them the benefit of the doubt that they are not trying to mislead.

Wasn't this software from a vendor of security solutions, who could benefit from customers thinking they are under attack?

I think the distinction between ICMP and ICMPV6 is a distraction because that is the name of the firewall rule, not an actual logged message. It could be that the author of the rule was generalizing the name of the rule.

Where does the "unassigned type" message come from? Evidence suggests these are normal ICMPv6 packets, which should never have been blocked in the first place. They may very well have been looked up against the wrong registry. Why else would it have listed them as unassigned? Can you get a dump of the packets in question, so we can see what they look like?

I found a post about this on the astaro forum. It looks like this problem is being caused by an incorrect firewall rule.