IPv6 routing

IPv6 routing

[Carlos Parada (EST)]

Hi,

I'm trying to set up an IPv6 network in Linux kernel 2.4.0-test10. In this
network I'm using just 3 boxs and I would use static routes.
 _____        _____          _____
|   A   |____|    B   | ____|   C   |     
|_____|       |_____|        |_____|

The problem is that I cannot access from A to C machines and vice-versa. But
the routing problem is a bit strange because, A can access to the two
interfaces of B, even to B interface in the same network as C. Also C can
access to both B interfaces and cannot access to machine A.
i.e. the machines seems that can access to other networks (the routing
mechanisms seems work fine), but B cannot be able to forward the packet. Is
this correct ?

Anybody know if I have a missconfiguration or I'm doing somethings wrong ?


Regards.

**********
Carlos da Fonseca Parada
PT Inovação, S.A.
Multimédia e Serviços IP

*   R. Engº José Ferreira Pinto Basto - 3810 Aveiro - Portugal
* Ext: 1317, 1318

Re: IPv6 routing

[Gregory Maxwell]

On Fri, Apr 20, 2001 at 06:37:05PM +0100, Carlos Parada (EST) wrote:
> Hi,
> 
> I'm trying to set up an IPv6 network in Linux kernel 2.4.0-test10. In this
> network I'm using just 3 boxs and I would use static routes.
>  _____        _____          _____
> |   A   |____|    B   | ____|   C   |     
> |_____|       |_____|        |_____|
> 
> The problem is that I cannot access from A to C machines and vice-versa. But
> the routing problem is a bit strange because, A can access to the two
> interfaces of B, even to B interface in the same network as C. Also C can

echo -n 1 > /proc/sys/net/ipv6/conf/all/forwarding

IPv6 routing

[Jonathan Tripathy]

Hi Everyone,

I'm using HE's IP6 Tunnel broker service. I'm trying to use a Ubuntu box 
as a router. I've set up the tunnel (which connects to HE's server via 
IPv4).

Everything does work when I don't have any iptables rules. However, I 
don't wish to leave the box open.

For some reason, forwarding of packets (from HE WAN to the other side of 
my router) only works when I have my ip6tables INPUT chain to ACCEPT. 
Even when putting in a state RELATED,ESTABLISHED in there doesn't work.

Does anyone have any ideas why this is the case? I have a funny feeling 
it has something to do with NDP and ip6tables not marking something as 
"related".

Thanks

Re: IPv6 routing

[Jonathan Tripathy]

On 30/08/10 11:26, Jonathan Tripathy wrote:
> Hi Everyone,
>
> I'm using HE's IP6 Tunnel broker service. I'm trying to use a Ubuntu 
> box as a router. I've set up the tunnel (which connects to HE's server 
> via IPv4).
>
> Everything does work when I don't have any iptables rules. However, I 
> don't wish to leave the box open.
>
> For some reason, forwarding of packets (from HE WAN to the other side 
> of my router) only works when I have my ip6tables INPUT chain to 
> ACCEPT. Even when putting in a state RELATED,ESTABLISHED in there 
> doesn't work.
>
> Does anyone have any ideas why this is the case? I have a funny 
> feeling it has something to do with NDP and ip6tables not marking 
> something as "related".
>
> Thanks
>
Ok so I added

ip6tables -I INPUT -d ff02::1:ff00:1 -j ACCEPT

to my INPUT chain. The above address being the "solicited node multicast 
address" of my router, which other hosts on the LAN will send stuff to 
get it's IP (Bit like ARP for IPv4).

However, when I run a tcpdump, I am now getting this:

06:29:37.241590 IP6 2001:470:1f09:dc5::1 > ff02::1:ff00:2: ICMP6, 
neighbor solicitation, who has 2001:470:1f09:dc5::2, length 32
06:29:37.241800 IP6 2001:470:1f09:dc5::2 > 2001:470:1f09:dc5::1: ICMP6, 
neighbor advertisement, tgt is 2001:470:1f09:dc5::2, length 32

It seems like netfilter isn't marking the advertisements as "related" to 
the solicitation request. I think that this is becuase the request was 
sent to ff02::1:ff00:2, but the reply came from 2001:470:1f09:dc5::2.

Any ideas what I should do?

Thanks

Re: IPv6 routing

[Jan Engelhardt]

On Monday 2010-08-30 12:37, Jonathan Tripathy wrote:
>
> 06:29:37.241590 IP6 2001:470:1f09:dc5::1 > ff02::1:ff00:2: ICMP6, neighbor
> solicitation, who has 2001:470:1f09:dc5::2, length 32
> 06:29:37.241800 IP6 2001:470:1f09:dc5::2 > 2001:470:1f09:dc5::1: ICMP6,
> neighbor advertisement, tgt is 2001:470:1f09:dc5::2, length 32
>
> It seems like netfilter isn't marking the advertisements as "related" to the
> solicitation request. I think that this is becuase the request was sent to
> ff02::1:ff00:2, but the reply came from 2001:470:1f09:dc5::2.

advertisements need not strictly be a reply to a solicit.

Re: IPv6 routing

[Jonathan Tripathy]

you believe you have received

this email in error.


On 30/08/10 11:43, Jan Engelhardt wrote:
> On Monday 2010-08-30 12:37, Jonathan Tripathy wrote:
>    
>> 06:29:37.241590 IP6 2001:470:1f09:dc5::1>  ff02::1:ff00:2: ICMP6, neighbor
>> solicitation, who has 2001:470:1f09:dc5::2, length 32
>> 06:29:37.241800 IP6 2001:470:1f09:dc5::2>  2001:470:1f09:dc5::1: ICMP6,
>> neighbor advertisement, tgt is 2001:470:1f09:dc5::2, length 32
>>
>> It seems like netfilter isn't marking the advertisements as "related" to the
>> solicitation request. I think that this is becuase the request was sent to
>> ff02::1:ff00:2, but the reply came from 2001:470:1f09:dc5::2.
>>      
> advertisements need not strictly be a reply to a solicit.
>    

So how would I go about adding rules then that allows this?

Re: IPv6 routing

[Jonathan Tripathy]

>
> On 30/08/10 11:43, Jan Engelhardt wrote:
>> On Monday 2010-08-30 12:37, Jonathan Tripathy wrote:
>>> 06:29:37.241590 IP6 2001:470:1f09:dc5::1>  ff02::1:ff00:2: ICMP6, 
>>> neighbor
>>> solicitation, who has 2001:470:1f09:dc5::2, length 32
>>> 06:29:37.241800 IP6 2001:470:1f09:dc5::2>  2001:470:1f09:dc5::1: ICMP6,
>>> neighbor advertisement, tgt is 2001:470:1f09:dc5::2, length 32
>>>
>>> It seems like netfilter isn't marking the advertisements as 
>>> "related" to the
>>> solicitation request. I think that this is becuase the request was 
>>> sent to
>>> ff02::1:ff00:2, but the reply came from 2001:470:1f09:dc5::2.
>> advertisements need not strictly be a reply to a solicit.
>
> So how would I go about adding rules then that allows this?
>
Ok everyone, I think I found the answer. Just allow -p icmpv6

Does that sound safe enough?

On a side note: netfilter currently has arptables to stop arp cache 
poisoning. Is there any similar thing for NDP poisoning? I can prevent 
the actual flow of non-icmpv6 IP traffic to a host by using ip6tables on 
my bridge device (which sits in the middle of all hosts), however this 
won't stop DOS attacks..

Cheers

Re: IPv6 routing

[Thomas Jacob]

On Mon, 2010-08-30 at 12:10 +0100, Jonathan Tripathy wrote:
> On a side note: netfilter currently has arptables to stop arp cache 
> poisoning. Is there any similar thing for NDP poisoning? I can prevent 
> the actual flow of non-icmpv6 IP traffic to a host by using ip6tables on 
> my bridge device (which sits in the middle of all hosts), however this 
> won't stop DOS attacks..

Neighbour discovery is using link local multicast addresses, so
you only need to be worried about being flooded from your LAN,
same as with arp. If you are worried about it, then I think
ip6tables doesn't do much for you at the moment, I am afraid. IPv6
support is a long way from being up to IPv4 standards in Linux
(and elsewhere). Please let the list know if you find a solution ;)

BTW, I wouldn't accept all icmpv6 packets if you're security
conscious, you really only need the following for basic
IPv6 connectivity:

(Taken from Ubuntu's ufw package)

(linked to INPUT chain)

target     prot opt source               destination         
ACCEPT     ipv6-icmp    anywhere             anywhere
ipv6-icmp neighbour-solicitation 
ACCEPT     ipv6-icmp    anywhere             anywhere
ipv6-icmp neighbour-advertisement 
ACCEPT     ipv6-icmp    anywhere             anywhere
ipv6-icmp router-solicitation 
ACCEPT     ipv6-icmp    anywhere             anywhere
ipv6-icmp router-advertisement 

(and maybe not even the last two, if you are using
static routing).



> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IPv6 routing

[Jonathan Tripathy]

On 30/08/10 13:24, Thomas Jacob wrote:
> On Mon, 2010-08-30 at 12:10 +0100, Jonathan Tripathy wrote:
>    
>> On a side note: netfilter currently has arptables to stop arp cache
>> poisoning. Is there any similar thing for NDP poisoning? I can prevent
>> the actual flow of non-icmpv6 IP traffic to a host by using ip6tables on
>> my bridge device (which sits in the middle of all hosts), however this
>> won't stop DOS attacks..
>>      
> Neighbour discovery is using link local multicast addresses, so
> you only need to be worried about being flooded from your LAN,
> same as with arp. If you are worried about it, then I think
> ip6tables doesn't do much for you at the moment, I am afraid. IPv6
> support is a long way from being up to IPv4 standards in Linux
> (and elsewhere). Please let the list know if you find a solution ;)
>
> BTW, I wouldn't accept all icmpv6 packets if you're security
> conscious, you really only need the following for basic
> IPv6 connectivity:
>
> (Taken from Ubuntu's ufw package)
>
> (linked to INPUT chain)
>
> target     prot opt source               destination
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp neighbour-solicitation
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp neighbour-advertisement
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp router-solicitation
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp router-advertisement
>
> (and maybe not even the last two, if you are using
> static routing).
Hi Thomas,

Thanks for the excellent explanation.

Yes I am worried about by "LAN" being flooded, as my "LAN" actually 
hosts public (read: "untrusted") VPS for customers.

But ah well. I'm sure netfilter will have ndptables some day. We're only 
testing IPv6 at the minute anyway. And we've got iptables which will 
prevent any non-icmp traffic from working, as well as ebtables to 
prevent MAC spoofing.

That's good to know about the "fine-tuning" of the rules for icmpv6 - 
the is exactly what I was looking for!

Cheers

Re: IPv6 routing

[Jozsef Kadlecsik]

On Mon, 30 Aug 2010, Jonathan Tripathy wrote:

> On 30/08/10 13:24, Thomas Jacob wrote:
> > On Mon, 2010-08-30 at 12:10 +0100, Jonathan Tripathy wrote:
> >    
> > > On a side note: netfilter currently has arptables to stop arp cache
> > > poisoning. Is there any similar thing for NDP poisoning? I can prevent
> > > the actual flow of non-icmpv6 IP traffic to a host by using ip6tables on
> > > my bridge device (which sits in the middle of all hosts), however this
> > > won't stop DOS attacks..
> > >      
> > Neighbour discovery is using link local multicast addresses, so
> > you only need to be worried about being flooded from your LAN,
> > same as with arp. If you are worried about it, then I think
> > ip6tables doesn't do much for you at the moment, I am afraid. IPv6
> > support is a long way from being up to IPv4 standards in Linux
> > (and elsewhere). Please let the list know if you find a solution ;)
> > 
> > BTW, I wouldn't accept all icmpv6 packets if you're security
> > conscious, you really only need the following for basic
> > IPv6 connectivity:
> > 
> > (Taken from Ubuntu's ufw package)
> > 
> > (linked to INPUT chain)
> > 
> > target     prot opt source               destination
> > ACCEPT     ipv6-icmp    anywhere             anywhere
> > ipv6-icmp neighbour-solicitation
> > ACCEPT     ipv6-icmp    anywhere             anywhere
> > ipv6-icmp neighbour-advertisement
> > ACCEPT     ipv6-icmp    anywhere             anywhere
> > ipv6-icmp router-solicitation
> > ACCEPT     ipv6-icmp    anywhere             anywhere
> > ipv6-icmp router-advertisement
> > 
> > (and maybe not even the last two, if you are using
> > static routing).
> 
> Thanks for the excellent explanation.
> 
> Yes I am worried about by "LAN" being flooded, as my "LAN" actually hosts
> public (read: "untrusted") VPS for customers.
> 
> But ah well. I'm sure netfilter will have ndptables some day. We're only
> testing IPv6 at the minute anyway. And we've got iptables which will prevent
> any non-icmp traffic from working, as well as ebtables to prevent MAC
> spoofing.
> 
> That's good to know about the "fine-tuning" of the rules for icmpv6 - the is
> exactly what I was looking for!

Please check out RFC 4890: Recommendations for Filtering ICMPv6 Messages 
in Firewalls, which discusses ICMPv6 filtering in details. It even comes 
with an example shell script for netfilter/ip6tables in the appendix.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: IPv6 routing

[Thomas Jacob]

On Mon, 2010-08-30 at 14:42 +0200, Jozsef Kadlecsik wrote:

> Please check out RFC 4890: Recommendations for Filtering ICMPv6 Messages 
> in Firewalls, which discusses ICMPv6 filtering in details. It even comes 
> with an example shell script for netfilter/ip6tables in the appendix.


Are you sure that this is still accurate for current kernels? 

For instance, I would have assumed that things like
destination-unreachable or packet-too-big  are handled
by the stateful inspection code (i.e. are matched by
--state RELATED, ESTABLISHED) same as for IPv4?

Re: IPv6 routing

[Jozsef Kadlecsik]

On Mon, 30 Aug 2010, Thomas Jacob wrote:

> On Mon, 2010-08-30 at 14:42 +0200, Jozsef Kadlecsik wrote:
> 
> > Please check out RFC 4890: Recommendations for Filtering ICMPv6 Messages 
> > in Firewalls, which discusses ICMPv6 filtering in details. It even comes 
> > with an example shell script for netfilter/ip6tables in the appendix.
> 
> Are you sure that this is still accurate for current kernels? 
> 
> For instance, I would have assumed that things like
> destination-unreachable or packet-too-big  are handled
> by the stateful inspection code (i.e. are matched by
> --state RELATED, ESTABLISHED) same as for IPv4?

The sample script in the RFC tries to handle both cases: kernel with and 
without IPv6 connection tracking (STATE_ENABLED shell variable).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: IPv6 routing

[Thomas Jacob]

On Mon, 2010-08-30 at 15:18 +0200, Jozsef Kadlecsik wrote:

> The sample script in the RFC tries to handle both cases: kernel with and 
> without IPv6 connection tracking (STATE_ENABLED shell variable).

I noticed that, but even the stateful part explicitly references the
actual icmpv6 type.

AFAIK, in IPv4 netfilter you would not need to do that as the ancillary
ICMP traffic caused by existing conntrack entries is matched by
ESTABLISHED, RELATED automatically.

Is this not the case for IPv6?

The code snippet in question:

if [ "$STATE_ENABLED" -eq "1" ]
   then
     # Allow incoming destination unreachable messages
     # only for existing sessions
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -m state -p icmpv6 \
            -d $inner_prefix \
            --state ESTABLISHED,RELATED --icmpv6-type \
            destination-unreachable -j ACCEPT
     done
else
     # Allow incoming destination unreachable messages
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
            --icmpv6-type destination-unreachable -j ACCEPT
     done
fi

Re: IPv6 routing

[Thomas Jacob]

On Mon, 2010-08-30 at 13:33 +0100, Jonathan Tripathy wrote:
> But ah well. I'm sure netfilter will have ndptables some day. We're only 
> testing IPv6 at the minute anyway. 

Well, it will probably be an ip6tables module, since in IPv6
the link layer resolution protocol is actually built on top
of IPv6 icmp, rather than being an independent layer 3 protocol
as ARP is.

> And we've got iptables which will 
> prevent any non-icmp traffic from working, as well as ebtables to 
> prevent MAC spoofing.

Out of curiosity, what exactly are you trying to filter with your
bridge? Is the bridge running on the VPS host, and each
virtual machine has it's own virtual network interface?

Re: IPv6 routing

[Jonathan Tripathy]

On 30/08/10 13:47, Thomas Jacob wrote:
> On Mon, 2010-08-30 at 13:33 +0100, Jonathan Tripathy wrote:
>    
>> But ah well. I'm sure netfilter will have ndptables some day. We're only
>> testing IPv6 at the minute anyway.
>>      
> Well, it will probably be an ip6tables module, since in IPv6
> the link layer resolution protocol is actually built on top
> of IPv6 icmp, rather than being an independent layer 3 protocol
> as ARP is.
>    
Ah yes, that sounds more likely
>> And we've got iptables which will
>> prevent any non-icmp traffic from working, as well as ebtables to
>> prevent MAC spoofing.
>>      
> Out of curiosity, what exactly are you trying to filter with your
> bridge? Is the bridge running on the VPS host, and each
> virtual machine has it's own virtual network interface?
>
>    
That's correct. I'm making use of physdev a lot

Re: IPv6 routing

[Pascal Hambourg]

Hello,

Thomas Jacob a écrit :
> 
> (linked to INPUT chain)
> 
> target     prot opt source               destination         
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp neighbour-solicitation 
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp neighbour-advertisement 
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp router-solicitation 
> ACCEPT     ipv6-icmp    anywhere             anywhere
> ipv6-icmp router-advertisement 
> 
> (and maybe not even the last two, if you are using
> static routing).

A router accepts router solicitation and ignores router advertisement. A
host accepts router advertisement and ignores router solicitation.

Re: IPv6 routing

[Jan Engelhardt]

On Monday 2010-08-30 12:45, Jonathan Tripathy wrote:

> you believe you have received
> this email in error.

My beliefs are not up to discussion here :-)



> On 30/08/10 11:43, Jan Engelhardt wrote:
>> On Monday 2010-08-30 12:37, Jonathan Tripathy wrote:
>>   
>>> 06:29:37.241590 IP6 2001:470:1f09:dc5::1>  ff02::1:ff00:2: ICMP6, neighbor
>>> solicitation, who has 2001:470:1f09:dc5::2, length 32
>>> 06:29:37.241800 IP6 2001:470:1f09:dc5::2>  2001:470:1f09:dc5::1: ICMP6,
>>> neighbor advertisement, tgt is 2001:470:1f09:dc5::2, length 32
>>>
>>> It seems like netfilter isn't marking the advertisements as "related" to the
>>> solicitation request. I think that this is becuase the request was sent to
>>> ff02::1:ff00:2, but the reply came from 2001:470:1f09:dc5::2.
>>>     
>> advertisements need not strictly be a reply to a solicit.
>>   
>
> So how would I go about adding rules then that allows this?
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: IPv6 routing

[Jonathan Tripathy]

On 30/08/10 13:07, Jan Engelhardt wrote:
> On Monday 2010-08-30 12:45, Jonathan Tripathy wrote:
>
>    
>> you believe you have received
>> this email in error.
>>      
> My beliefs are not up to discussion here :-)
Sorry about that, that was what was left of the default email footer