0

The problem:

Losing IPv6 connectivity to a remote IP after certain time period without establishing a connection to the remote IP.

My setup:

I'm running a server with ip6tables firewall that filters incoming ICMPv6 packets. I have setup this firewall according to RFC 4890 for local configuration traffic. The following ICMPv6 are permitted on INPUT chain for eth0 interface:

type 1 (destination unreachable)
type 2 (packet too big)
type 3 (time exceeded)
type 4 (parameter problem)
type 128 limit 100/sec limit-burst 500 (Echo)
type 129 (Echo reply)
type 133 (Router Solicitation)
type 134 (Router Advertisement)
type 135 (Neighbor Solicitation)
type 136 (Neighbor Advertisement)
type 141 (Inverse Neighbor Discovery Solicitation)
type 142 (Inverse Neighbor Discovery Advertisement)
type 148 (Certificate Path Solicitation)
type 149 (Certificate Path Advertisement
type 151 (Multicast Router Advertisement)
type 152 (Multicast Router Solicitation)
type 153 (Multicast Router Termination)

Every other type is dropped. All ICMPv6 packets are permitted on the OUTPUT chain for eth0 interface.

What have i tried:

After the ip6tables rules are enabled, all IPv6 traffic runs smoothly. However after approx. 1 day without connecting to a remote IP address it suddenly becomes unreachable.

Running tcpdump on the remote location shows that ICMPv6 echo from firewalled server successfully arrives and reply is sent. However the echo reply doesn't arrive back.

If the firewall policy is relaxed to allow all ICMPv6 packets through, connection is established and then the original firewall is restarted - it all continues to work.

My question:

How do I prevent the connection loss?

I guess that I must be dropping some type of ICMPv6 packet important in establishing connection.

Community
  • 1
Marek Rost
  • 263
  • 3
  • 11

1 Answers1

0

I have missed a rule imported from IPv4 firewall, it was sitting higher in the INPUT chain and blocked all multicast packets:

-t filter -A INPUT -m pkttype --pkt-type multicast

After removing this rule, connectivity was restored.

I have discovered this by carefully reviewing ICMPv6 traffic on the firewalled server. The server was receiving Neighbor Solicitation packets but wasn't sending out Neighbor Advertisement in reply.

I still find this strange since the multicast dropping rule was sitting on INPUT chain, thus it shouldn't prevent the Advertisement packet. Instead I think I shouldn't even receive the Solicitation request...

Sorry for the noise.

Marek Rost
  • 263
  • 3
  • 11