|
tunnel working, but subnet routing not working.
![[us]](/s/countries/us.gif) Shadow Hawkins on Thursday, 16 October 2014 18:06:20
I have a debian system which is running AICCU 2007.01.15-console-linux by Jeroen Massar. The machine is behind an old WRT-54G router providing NAT. The tunnel works fine, and I can ping6 google.com from the machine running aiccu. I can also access a webserver running on the machine using its ipv6 address.
I got a Routed /64 Subnet from SixXS, which is enabled. I am running radvd version: 1.9.1.
Here is my /etc/radvd.conf:
interface br0
{
AdvSendAdvert on;
prefix 2001:4830:1600:850a::/64
{
};
};
The interface is br0, because that's the interface my box connects to the router through.
Here is the interface info:
bminton:~# ifconfig
br0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:225124 errors:0 dropped:0 overruns:0 frame:0
TX packets:243644 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:41343463 (39.4 MiB) TX bytes:151989214 (144.9 MiB)
dummy0 Link encap:Ethernet HWaddr 9a:ed:e8:e5:13:23
inet addr:75.75.183.132 Bcast:75.75.183.255 Mask:255.255.255.0
inet6 addr: fe80::98ed:e8ff:fee5:1323/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:18252 (17.8 KiB)
dummy0:0 Link encap:Ethernet HWaddr 9a:ed:e8:e5:13:23
inet addr:192.168.1.226 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
eth0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:225412 errors:0 dropped:0 overruns:0 frame:0
TX packets:280077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44658777 (42.5 MiB) TX bytes:153860692 (146.7 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:119263 errors:0 dropped:0 overruns:0 frame:0
TX packets:119263 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:40852453 (38.9 MiB) TX bytes:40852453 (38.9 MiB)
sixxs Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::4830:1600:50a:2/64 Scope:Link
inet6 addr: 2001:4830:1600:50a::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:344 errors:0 dropped:0 overruns:0 frame:0
TX packets:497 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:49300 (48.1 KiB) TX bytes:518951 (506.7 KiB)
Forwarding is turned on:
bminton:~# sysctl net.ipv6.conf.default.forwarding
net.ipv6.conf.default.forwarding = 1
bminton:~# sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 1
bminton:~# cat /proc/sys/net/ipv6/conf/default/forwarding
1
bminton:~# cat /proc/sys/net/ipv6/conf/all/forwarding
1
ip6tables and iptables are allowing forwarded traffic:
bminton:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22
Chain FORWARD (policy ACCEPT)
target prot opt source destination
dtc-xen-fw all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain dtc-xen-fw (1 references)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 50/sec burst 5
DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 100/sec burst 5
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02
Chain dtc-xen-in (0 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 reject-with icmp-port-unreachable
tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 300 hit_count: 10 name: DEFAULT side: source mask: 255.255.255.255 reject-with icmp-port-unreachable
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 5/sec burst 5
DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 10/sec burst 5
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 5/sec burst 5
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
bminton:~# ip6tables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
DROP all ::/0 ::/0 rt type:0 segsleft:0
ACCEPT icmp ::/0 ::/0
ACCEPT tcp ::/0 ::/0 tcp dpt:443
ACCEPT tcp ::/0 ::/0 tcp dpt:80
ACCEPT tcp ::/0 ::/0 tcp dpt:53
ACCEPT udp ::/0 ::/0 udp dpt:53
ACCEPT tcp ::/0 ::/0 tcp dpt:123
ACCEPT udp ::/0 ::/0 udp dpt:123
ACCEPT tcp ::/0 ::/0 tcp dpt:11371
ACCEPT tcp ::/0 ::/0 tcp dpt:11370
ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED
ACCEPT icmpv6 ::/0 ::/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all ::/0 ::/0 rt type:0 segsleft:0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all ::/0 ::/0 rt type:0 segsleft:0
ACCEPT icmpv6 ::/0 ::/0
On the client (a Raspberry Pi running Raspbian), I have:
root@raspberrypi:~# cat /proc/sys/net/ipv6/conf/eth0/accept_ra
1
root@raspberrypi:~# sysctl net.ipv6.conf.eth0.accept_ra
net.ipv6.conf.eth0.accept_ra = 1
root@raspberrypi:~# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:8a:75:e8
inet addr:192.168.1.165 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2001:4830:1600:850a:ba27:ebff:fe8a:75e8/64 Scope:Global
inet6 addr: fe80::ba27:ebff:fe8a:75e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1541 errors:0 dropped:0 overruns:0 frame:0
TX packets:1041 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:132437 (129.3 KiB) TX bytes:131304 (128.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
However, I can't get external ipv6 connectivity:
root@raspberrypi:~# ping6 -c 3 ipv6.google.com
PING ipv6.google.com(iad23s06-in-x03.1e100.net) 56 data bytes
--- ipv6.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2006ms
There are no firewall rules on the client:
root@raspberrypi:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@raspberrypi:~# ip6tables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Monitoring with tcpdump shows (on the gateway):
bminton:~# tcpdump -i any -vv ip6
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:01:56.289412 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1
14:01:56.289412 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1
14:01:56.289458 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1
14:01:56.316669 IP6 (hlim 58, next-header ICMPv6 (58) payload length: 64) iad23s06-in-x03.1e100.net > 2001:4830:1600:850a:ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, echo reply, seq 1
14:01:56.316718 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 64) iad23s06-in-x03.1e100.net > 2001:4830:1600:850a:ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, echo reply, seq 1
And on the client:
root@raspberrypi:~# tcpdump -i any -vv ip6
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:02:50.856317 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s08-in-x06.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1
14:02:55.861732 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ba27:ebff:fe8a:75e8 > fe80::a800:4ff:fe00:a04: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::a800:4ff:fe00:a04
source link-address option (1), length 8 (1): b8:27:eb:8a:75:e8
0x0000: b827 eb8a 75e8
14:02:55.862340 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::a800:4ff:fe00:a04 > fe80::ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::a800:4ff:fe00:a04, Flags [router, solicited]
14:03:00.871273 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::a800:4ff:fe00:a04 > fe80::ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::ba27:ebff:fe8a:75e8
source link-address option (1), length 8 (1): aa:00:04:00:0a:04
0x0000: aa00 0400 0a04
14:03:00.871651 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::ba27:ebff:fe8a:75e8 > fe80::a800:4ff:fe00:a04: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::ba27:ebff:fe8a:75e8, Flags [solicited]
After browsing the forum, I found a similar question where the user was using the tunnel instead of the routed subnet, but that doesn't seem to be the case.
tunnel working, but subnet routing not working.
Shadow Hawkins on Thursday, 16 October 2014 21:05:19
after reading another message in the forum, I solved the problem:
bminton:~# ip -6 address add 2001:4830:1600:850a::/64 dev br0
bminton:~# ifconfig br0
br0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
inet6 addr: 2001:4830:1600:850a::/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:302062 errors:0 dropped:0 overruns:0 frame:0
TX packets:335559 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:50713247 (48.3 MiB) TX bytes:238616807 (227.5 MiB)
and on the client:
pi@raspberrypi ~/src/hockeypuck $ ping6 -c 1 google.com
PING google.com(iad23s08-in-x01.1e100.net) 56 data bytes
64 bytes from iad23s08-in-x01.1e100.net: icmp_seq=1 ttl=57 time=26.6 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.655/26.655/26.655/0.000 ms
tunnel working, but subnet routing not working.
ip -6 address add 2001:4830:1600:850a::/64 dev br0
That is never correct.
What you are doing there is adding a subnet anycast address
For any host in that /64 it will be the local host where packets for that prefix are being routed to.
You likely want to change that address into 2001:4830:1600:850a::1.
tunnel working, but subnet routing not working.
Shadow Hawkins on Saturday, 18 October 2014 04:35:52
Jeroen Massar wrote:
> ip -6 address add 2001:4830:1600:850a::/64 dev br0
That is never correct.
What you are doing there is adding a subnet anycast address
For any host in that /64 it will be the local host where packets for that prefix are being routed to.
You likely want to change that address into 2001:4830:1600:850a::1.
It didn't look like an anycast to me... all the final bits are zero, not one. Am I missing something?
tunnel working, but subnet routing not working.
It didn't look like an anycast to me... all the final bits are zero, not one. Am I missing something?
The link pointing to the wikipedia article describing that the lowest address in a subnet is the subnet anycast address? :)
tunnel working, but subnet routing not working.
Shadow Hawkins on Saturday, 18 October 2014 16:27:02
From the RFC:
The motivation for reserving the highest addresses from each subnet
rather than the lowest addresses, is to avoid conflicting with some
existing official and unofficial uses of the low-numbered addresses
in a subnet. For example, these low-numbered addresses are often
used for the ends of a point-to-point link, for tunnel endpoints, for
manually configured unicast addresses when a hardware token is not
available for the network interface, and even for manually con[qoufigured
static addresses for the routers on a link.
from the Wikipedia article:
The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the "subnet-router" anycast address.[1] Applications may use this address when talking to any one of the available routers, as packets sent to this address are delivered to just one router. so that's probably what you were thinking. I believe I tried it with the ::1 but I may not have.
tunnel working, but subnet routing not working.
Oops wrong RFC, that one is about special addresses in the subnet which are taken from the highest portion.
This is the correct definition RFC2373
2.6.1 Required Anycast Address
The Subnet-Router anycast address is predefined. Its format is as
follows:
| n bits | 128-n bits |
+------------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+------------------------------------------------+----------------+
The "subnet prefix" in an anycast address is the prefix which
identifies a specific link. This anycast address is syntactically
the same as a unicast address for an interface on the link with the
interface identifier set to zero.
Packets sent to the Subnet-Router anycast address will be delivered
to one router on the subnet. All routers are required to support the
Subnet-Router anycast addresses for the subnets which they have
interfaces.
The subnet-router anycast address is intended to be used for
applications where a node needs to communicate with one of a set of
routers on a remote subnet. For example when a mobile host needs to
communicate with one of the mobile agents on its "home" subnet.
|
![[ch]](/s/countries/ch.gif)
on Thursday, 16 October 2014 21:18:33
Posting is only allowed when you are