• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

[solved] Help locking it down

Started by jeffsadowski, February 02, 2011, 01:12:00 PM

Previous topic - Next topic

jeffsadowski

All quoted items come from my Hurricane Electric Tunnel Details page.

relevant lines in /etc/network/interfaces

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
endpoint <"Server IPv4 address">
address <"Client IPv6 address">
netmask  64
up ip -6 route add default dev he-ipv6
down ip -6 route del default dev he-ipv6


relevant lines of ifconfig eth1

inet6 addr:<First Address of "Routed /64">/64


relevant lines of /etc/sysctl.conf

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.eth1.forwarding = 1
net.ipv6.conf.he-ipv6.forwarding = 1
net.ipv6.conf.all.forwarding = 1


I think I can take some lines out of that to secure it up a bit and I will try commenting them out one by one rebooting and try my connection out to make sure everything works but I'd like if someone could offer a little help here if possible. because it requires testing with rebooting server first and then the client and then ipv6 test. Which is a long and tedious process (the double rebooting bit to make sure configurations took).

relevant lines of /etc/radvd

interface eth1
{
  AdvSendAdvert on;
  AdvHomeAgentFlag off;
  MinRtrAdvInterval 30;
  MaxRtrAdvInterval 100;
  prefix <"Routed /64">
  {
       AdvOnLink on;
       AdvAutonomous on;
  };
};


everything seems to be working as it should. But now I want to lock it down but not break it.

my iptables look as follows for ipv4

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  <internal ip scope/internal ip netmask bits>       0.0.0.0/0
ACCEPT     all  --  127.0.0.1            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


applying the ipv6 equiv seems to break radvd
ie when ip6tables looks like so

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all      <"Routed /64">  ::/0
ACCEPT     all      ::1/128              ::/0
ACCEPT     all      ::/0                 ::/0                state RELATED,ESTABLISHED
DROP       all      ::/128               ::/0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


so I need to slack off my ip6tables a bit. I'd like recommendations.
Maybe opening up ipv6 on the eth1 interface and leaving the rest locked down?
How do others have their ip6tables to lock it down?

antillie

The router solicitation and advertisement process which radvd manages requires inbound ICMPv6 to function correctly.

Basically when a host on the LAN boots up it sends out an ICMPv6 multicast packet called a router solicitation asking three questions.

Client: Hello! Who is a router? Should I use stateless auto config or DHCPv6 to acquire an address? Should I use DHCPv6 to acquire name servers and other DHCP options?

Upon receiving this packet radvd responds with an ICMPv6 router advertisement.

Router: Hi there! I am a router, you should use the following preference weight for the entry in your routing table that points to me. You (should || should not) use stateless auto config to acquire an address. You (should || should not) use DHCPv6 to acquire name servers and other DHCP options. Here is the prefix for this LAN for use in stateless auto config.

Since ICMP is stateless I would wager that the RS's sent from your clients are being dropped by iptables and radvd is not receiving them and thus not answering them. Now radvd does send out RA's automatically at regular intervals but that still won't make things work.

This is because in order to actually reach your router your clients must be able to resolve its layer 3 IPv6 address to a MAC address. This process is handled by IPv6 neighbor discovery, which also runs on ICMPv6 using multicast packets. Without going into too much detail, your iptables rules are also blocking these packets and thus preventing the IPv6 functional equivalent of ARP from working. So no L3 -> L2 address resolution, no communication on the LAN.

ICMPv6 also handles path MTU discovery and a host of other things necessary for proper inter-network transit.

So, in short, you need to allow ICMPv6 packets to enter your router (and your clients) for the network to work properly. An IPv6 LAN simply cannot function with ICMPv6 filtered in the way that we are used to filtering it in IPv4. I have seen recommendations to rate limit ICMPv6 but that leaves you open to a pretty trivial DOS attack method so I'm not sure how good of an idea that really is.

jeffsadowski