Forum - Upgraded Kernel Now Tunnel Fails After Some Time :: SixXS

Upgraded Kernel Now Tunnel Fails After Some Time

Shadow Hawkins on Wednesday, 02 April 2014 21:07:44

Hi, I recently upgraded my server from a 2.6.35 kernel to a 3.2.0.4 kernel as part of an upgrade from Debian Squeeze (6) to Debian Wheezy (7). The tunnel is statically defined like this: auto sixxs iface sixxs inet6 v4tunnel address 2001:4978:f:3::2 netmask 64 endpoint 216.14.98.22 ttl 64 up /sbin/ip link set mtu 1280 dev sixxs up /sbin/ip route add default via 2001:4978:f:3::1 dev sixxs up /sbin/ip -6 a a 2001:4978:f:8003::1/64 dev eth0 I'm currently not able to ping the remote endpoint or any other address, ping6 tells me that the network is unreachable. These are the current routes: ip -6 route 2001:4978:f:3::/64 via :: dev sixxs proto kernel metric 256 2001:4978:f:8003::/64 dev eth0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 fe80::/64 via :: dev sixxs proto kernel metric 256 default via 2001:4978:f:3::1 dev sixxs metric 1024 If I take the interface down and try to bring it back up I get this: ifup sixxs add tunnel sit0 failed: No buffer space available Failed to bring up sixxs. I saw that the sixxs tunnel was still listed in "ip tun" so if I delete it from there and try again: ifup sixxs RTNETLINK answers: Cannot allocate memory Failed to bring up sixxs. Now I've also got this in my syslog: Apr 2 21:03:44 sanantonio kernel: [766423.702331] IPv6: Maximum number of routes reached, consider increasing route/max_size. So when I first saw this problem, I had /proc/sys/net/ipv6/route/max_size at 4096. I increased that to 40960 and I was able to operate my tunnel again for a period of time. I'm sure I can increase that number again and have it work for a while longer, but that's not a long term solution. Has anyone else come across this issue before? I'm not sure where to look for these routes to see what could be clogging things up.

Upgraded Kernel Now Tunnel Fails After Some Time

Jeroen Massar SixXS Staff

on Wednesday, 02 April 2014 21:14:55

Why don't you define this as:

iface eth0 inet6 static address 2001:4978:f:8003::1 netmask 64 auto sixxs iface sixxs inet6 v4tunnel address 2001:4978:f:3::2 netmask 64 endpoint 216.14.98.22 ttl 64 mtu 1280 2001:4978:f:3::1

Note that that does not make a real effective difference in configuration, it is just cleaner to use interfaces(5) properly

ip -6 route

Try using:

ip -6 ro show table all

and/or check /proc/net/ipv6_route Also, you will want to check your address tables and firewall amongst other things (see Problems Checklist on the contact page for other things to check). Also definitely check if you do not have some application either trying to scan outbound or inbound (tcpdump is your friend). It is odd that you get this after doing a (full?) upgrade to Debian 7 though, as those kernels have been properly tested for a while.

Upgraded Kernel Now Tunnel Fails After Some Time

Shadow Hawkins on Saturday, 05 April 2014 14:09:29

Jeroen Massar wrote:

Why don't you define this as:

iface eth0 inet6 static address 2001:4978:f:8003::1 netmask 64 auto sixxs iface sixxs inet6 v4tunnel address 2001:4978:f:3::2 netmask 64 endpoint 216.14.98.22 ttl 64 mtu 1280 gateway 2001:4978:f:3::1

Note that that does not make a real effective difference in configuration, it is just cleaner to use interfaces(5) properly

I set it up that way a long time ago (I've had tunnels with SixXS for about 8 years), not sure entirely why, but I've changed it to match your suggestion above, thanks.

> ip -6 route Try using:

ip -6 ro show table all

and/or check /proc/net/ipv6_route

Sorry, I forgot to post those. Neither is very long which is why I was confused. I expected that with a value of 4096 in the size that I'd see 4096 routes listed, but perhaps I've misunderstood how that size is used.

ip -6 route show table all 2001:4978:f:3::1 dev sixxs metric 1024 2001:4978:f:3::/64 via :: dev sixxs proto kernel metric 256 2001:4978:f:8003::/64 dev eth0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 fe80::/64 via :: dev sixxs proto kernel metric 256 default via 2001:4978:f:3::1 dev sixxs metric 1024 unreachable default dev lo table unspec proto kernel metric 4294967295 error -101 local ::1 via :: dev lo table local proto none metric 0 local 2001:4978:f:3::2 via :: dev lo table local proto none metric 0 local 2001:4978:f:8003::1 via :: dev lo table local proto none metric 0 local fe80::4287:341a via :: dev lo table local proto none metric 0 local fe80::4287:3442 via :: dev lo table local proto none metric 0 local fe80::4287:3cfe via :: dev lo table local proto none metric 0 local fe80::45ae:f2b6 via :: dev lo table local proto none metric 0 local fe80::230:48ff:febc:75b6 via :: dev lo table local proto none metric 0 ff00::/8 dev eth0 table local metric 256 ff00::/8 dev sixxs table local metric 256 unreachable default dev lo table unspec proto kernel metric 4294967295 error -101

cat /proc/net/ipv6_route 20010500009400010000000000000034 80 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000000 00000000 00000001 01000003 sixxs 20010502461200000000000000000001 80 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000000 00000000 00000001 01000003 sixxs 20011948021000020000000000000004 80 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000000 00000000 00000001 01000003 sixxs 20014978000f00030000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000400 00000000 00000001 00000001 sixxs 20014978000f00030000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00200001 sixxs 20014978000f80030000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0 261000a1101400000000000000000001 80 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000000 00000000 00000001 01000003 sixxs 2a0204186a0400370235005000560002 80 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000000 00000002 00000008 01000003 sixxs fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0 fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00200001 sixxs 00000000000000000000000000000000 00 00000000000000000000000000000000 00 20014978000f00030000000000000001 00000400 00000000 00000000 00000003 sixxs 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 000005c4 00200200 lo 00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000016 80200001 lo 20014978000f00030000000000000002 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000517 80200001 lo 20014978000f80030000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000266 80200001 lo fe80000000000000000000004287341a 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo fe800000000000000000000042873442 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo fe800000000000000000000042873cfe 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo fe800000000000000000000045aef2b6 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo fe80000000000000023048fffebc75b6 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0 ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 sixxs 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 000005c4 00200200 lo

Also, you will want to check your address tables and firewall amongst other things (see Problems Checklist on the contact page for other things to check). Also definitely check if you do not have some application either trying to scan outbound or inbound (tcpdump is your friend). It is odd that you get this after doing a (full?) upgrade to Debian 7 though, as those kernels have been properly tested for a while.

Yeah, nothing else has changed. It was a full upgrade to Debian 7. All of my machines now run Debian 7 with most running the 3.2.0.4 kernel. Many of them have native IPv6, this is currently the only server with a tunnel. I'm going to keep an eye on it and keep looking for more information.

Upgraded Kernel Now Tunnel Fails After Some Time

Jeroen Massar SixXS Staff

on Saturday, 05 April 2014 14:24:59

I expected that with a value of 4096 in the size that I'd see 4096 routes listed, but perhaps I've misunderstood how that size is used.

The count also includes any 'host routes'. Thus if you have a lot of connections, these count too.

local fe80::4287:341a via :: dev lo table local proto none metric 0

local fe80::4287:3442 via :: dev lo table local proto none metric 0

local fe80::4287:3cfe via :: dev lo table local proto none metric 0

local fe80::45ae:f2b6 via :: dev lo table local proto none metric 0

Seems you have multiple public ip addresses (66.135.52.26, 66.135.52.66, 66.135.60.254, 69.174.242.182), you should then at least configure the 'local' option of the tunnel interface too. Providing the rest of the details listed on the contact page under the "Reporting Problems / Checklist" section will be useful.

Upgraded Kernel Now Tunnel Fails After Some Time

Shadow Hawkins on Sunday, 06 April 2014 15:18:45

Jeroen Massar wrote:

Seems you have multiple public ip addresses (66.135.52.26, 66.135.52.66, 66.135.60.254, 69.174.242.182), you should then at least configure the 'local' option of the tunnel interface too.

Okay, I'll try that next time it fails. I just moved the v6 IP from eth0 over to the sixxs interface so that now there are no IPv6 routes pointing out eth0.

Providing the rest of the details listed on the contact page under the "Reporting Problems / Checklist" section will be useful.

I'm not sure what I've left out at this point, so here's everything: 1. My IPv6 tunnel fails after approximately 22 hours due to route table overflow 2. My tunnel is live and enabled 3. Not using AICCU 4. Not using AICCU 5. My handle is BWS42-RIPE and this concerns tunnel T13100 6. Doing this in the forum, so my email address isn't applicable 7. This is on a dedicated server with a 100mbit connection hosted by Peer1 in San Antonio, the server performs NAT for VPN clients (no IPv6 connectivity for them). 8. The server is running Debian 7 (Wheezy) x64, Linux sanantonio.wonderproxy.com 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux 9. Interface (slightly modified from above)

auto lo iface lo inet loopback up route add -net 127.0.0.0 netmask 255.0.0.0 dev lo down route add -net 127.0.0.0 netmask 255.0.0.0 dev lo auto eth0 iface eth0 inet static address 66.135.60.254 netmask 255.255.255.128 gateway 66.135.60.129 up /sbin/ip a a 69.174.242.182 dev eth0 up /sbin/ip a a 66.135.52.26 dev eth0 up /sbin/ip a a 66.135.52.66 dev eth0 auto sixxs iface sixxs inet6 v4tunnel address 2001:4978:f:3::2 netmask 64 endpoint 216.14.98.22 ttl 64 mtu 1280 gateway 2001:4978:f:3::1 up /sbin/ip -6 a a 2001:4978:f:8003::1/64 dev sixxs

IPv6 routing table (slightly modified from above)

2001:4978:f:3::1 dev sixxs metric 1024 2001:4978:f:3::/64 via :: dev sixxs proto kernel metric 256 2001:4978:f:8003::/64 via :: dev sixxs proto kernel metric 256 fe80::/64 via :: dev sixxs proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 default via 2001:4978:f:3::1 dev sixxs metric 1024

iptables rules

Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-squid tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80:112,8080:8112,10000:12500 fail2ban-apache tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443 fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 32784 ironwall all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT) target prot opt source destination DROP all -- 10.42.96.128/25 10.42.96.128/25 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-apache (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-squid (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain ironwall (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:500 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1701 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 ACCEPT udp -- 10.42.96.128/25 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:53 ACCEPT all -- 10.42.96.128/25 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 10.42.96.128/25 0.0.0.0/0 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:32784 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:25 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:587 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:993 ACCEPT tcp -- 10.42.96.128/25 0.0.0.0/0 tcp dpt:995 DROP all -- 10.42.96.128/25 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:32784 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995 ACCEPT udp -- 69.90.78.100 0.0.0.0/0 udp dpt:2161 ACCEPT tcp -- 69.90.78.100 0.0.0.0/0 tcp dpt:5666 ACCEPT udp -- 198.58.96.25 0.0.0.0/0 udp dpt:2161 ACCEPT tcp -- 198.58.96.25 0.0.0.0/0 tcp dpt:5666 ACCEPT udp -- 37.235.50.56 0.0.0.0/0 udp dpt:2161 ACCEPT tcp -- 37.235.50.56 0.0.0.0/0 tcp dpt:5666 ACCEPT tcp -- 50.19.198.47 0.0.0.0/0 tcp dpt:47017 ACCEPT tcp -- 50.16.59.94 0.0.0.0/0 tcp dpt:47017 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 ACCEPT 41 -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 64.15.79.240 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 64.34.27.86 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 64.34.27.88 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 64.34.27.90 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 64.34.27.91 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 64.34.177.215 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 66.135.60.254 0.0.0.0/0 tcp dpt:27017 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:82 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:83 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8081 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8082 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8083 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10080 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10081 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10082 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10083 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10001 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10002 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10003 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10200 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10500 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10501 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10502 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10503 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10700 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11000 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11001 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11002 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11003 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11200 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11500 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11501 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11502 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11503 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:11700 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12000 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12001 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12002 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12003 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12200 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12500 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12501 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12502 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12503 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12700 DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 10.42.96.0/24 0.0.0.0/0

10. No other firewalls or anti-virus software 11. IPv4 Traceroute

traceroute -n 216.14.98.22 traceroute to 216.14.98.22 (216.14.98.22), 30 hops max, 60 byte packets 1 * * * 2 216.187.124.65 43.896 ms 43.892 ms 43.884 ms 3 216.187.124.38 8.888 ms 8.885 ms 8.879 ms 4 * * * 5 63.218.5.38 32.822 ms 32.802 ms 32.798 ms 6 216.14.98.22 33.780 ms 33.944 ms 33.923 ms

IPv6 Traceroute

traceroute6 2001:4978:f:3::1 traceroute to 2001:4978:f:3::1 (2001:4978:f:3::1), 30 hops max, 80 byte packets 1 gw-4.chi-02.us.sixxs.net (2001:4978:f:3::1) 34.853 ms 34.839 ms 34.820 ms

12. Not a heartbeat tunnel 13. I don't think a network capture is relevant at this point as the traffic never leaves the server, but I'll do one if needed. 14. The PoP is listed as up.

Upgraded Kernel Now Tunnel Fails After Some Time

Jeroen Massar SixXS Staff

on Sunday, 06 April 2014 20:55:00

1. My IPv6 tunnel fails after approximately 22 hours due to route table overflow

That is a rather weird issue indeed.I vaguely recall this happening in other places (that is people mentioning it), but don't recall if they actually resolved it some way or another. I would not be surprised that it is caused by your unusual configuration and firewall rules though. Note also that there is such a thing as an IPv6 firewall.

auto lo iface lo inet loopback up route add -net 127.0.0.0 netmask 255.0.0.0 dev lo down route add -net 127.0.0.0 netmask 255.0.0.0 dev lo

Why are you adding 127.0.0.0/8 that way? Note that per default such a route gets installed as the address is 127.0.0.1/8.

$ ip addr show lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever $ ip ro get 127.0.0.1 local 127.0.0.1 dev lo src 127.0.0.1 cache <local> ipid 0xd26c $ ip ro get 127.1.2.3 local 127.1.2.3 dev lo src 127.0.0.1 cache <local>

auto eth0 iface eth0 inet static address 66.135.60.254 netmask 255.255.255.128 gateway 66.135.60.129 up /sbin/ip a a 69.174.242.182 dev eth0 up /sbin/ip a a 66.135.52.26 dev eth0 up /sbin/ip a a 66.135.52.66 dev eth0

As you add other IPv4 addresses, you need to specify a "local" address for the tunnel interface, by adding

iface sixxs ... .... endpoint a.b.c.d local f.g.h.i ...

up /sbin/ip -6 a a 2001:4978:f:8003::1/64 dev sixxs

That /64 really does not belong on the tunnel interface; that will cause packets destined for that /64 (everything not configured on your side) to be routed back to the PoP. The PoP will drop those, but you already caused a 2x amplification there. As for your firewall rules, it is a much better idea to just whitelist addresses, instead of letting botnets probe your network; they will get in after the millionth attempt from a different host. I don't think that the rules you setup are useful; for instance because of state tracking and forwarded NAT if your host itself or the NATted hosts contact a remote resource, that resource can do almost anything and avoid all your rules...

ACCEPT all -- 10.42.96.128/25 0.0.0.0/0 state RELATED,ESTABLISHED .. ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Every single packet coming IN (INPUT rule) to your host will be accepted. Interestingly you do not track Masqueraded (FORWARD) packets. You seem to have multiport extension, but then have long port-specific rules. You seem to also have connection tracker tables up and running, see the FAQ item about that for why that is a bad bad idea and how to solve it.

Upgraded Kernel Now Tunnel Fails After Some Time

Shadow Hawkins on Monday, 07 April 2014 18:28:52

Jeroen Massar wrote:

> 1. My IPv6 tunnel fails after approximately 22 hours due to route table overflow That is a rather weird issue indeed.I vaguely recall this happening in other places (that is people mentioning it), but don't recall if they actually resolved it some way or another. I would not be surprised that it is caused by your unusual configuration and firewall rules though. Note also that there is such a thing as an IPv6 firewall.

I'm struggling to find other people solving this without just bumping the route size up. I'm aware that ip6tables exists, I just haven't invested time in it yet.

auto lo iface lo inet loopback up route add -net 127.0.0.0 netmask 255.0.0.0 dev lo down route add -net 127.0.0.0 netmask 255.0.0.0 dev lo

Why are you adding 127.0.0.0/8 that way? Note that per default such a route gets installed as the address is 127.0.0.1/8.

Because that's what our host has in their default setup for some reason. I just hadn't removed it (I have now).

As you add other IPv4 addresses, you need to specify a "local" address for the tunnel interface, by adding

iface sixxs ... .... endpoint a.b.c.d local f.g.h.i ...

Okay, I've done this.

Didn't make a difference, so I've moved it back to eth0.

I don't think that the rules you setup are useful; for instance because of state tracking and forwarded NAT if your host itself or the NATted hosts contact a remote resource, that resource can do almost anything and avoid all your rules...

ACCEPT all -- 10.42.96.128/25 0.0.0.0/0 state RELATED,ESTABLISHED .. ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

That's not how I understand RELATED to work. The connection attempt must be "related" to the original connection like an active FTP data connection.

Every single packet coming IN (INPUT rule) to your host will be accepted. Interestingly you do not track Masqueraded (FORWARD) packets.

Every single packet that is not matched is dropped by a rule that the end of the ironwall chain.

You seem to have multiport extension, but then have long port-specific rules.

If you're referring to the number of rules I have, it's because they're built by a script. It could definitely be better, but I haven't seen a need to do anything about it.

You seem to also have connection tracker tables up and running, see the FAQ item about that for why that is a bad bad idea and how to solve it.

If you're referring to "My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker", then that is not this issue. I explicitly accept protocol 41, and there is constant traffic over the tunnel. Well until it misbehaves.

Upgraded Kernel Now Tunnel Fails After Some Time

Jeroen Massar SixXS Staff

on Tuesday, 08 April 2014 11:14:28

>That /64 really does not belong on the tunnel interface; that will cause packets destined for that /64

> (everything not configured on your side) to be routed back to the PoP. The PoP will drop those, but you

> already caused a 2x amplification there.

Didn't make a difference, so I've moved it back to eth0.

While it does not "make a difference", it makes a HUGE difference in the fact that you are not sending packets back when that should not happen.

I explicitly accept protocol 41,

The fun part is, that that does not matter, the connection tracking causes it to be dropped, not your firewall rules. Also, it is a bad idea to generally accept protocol-41 packets, but that is another question. Clicking a "firewall" together is never a good idea...

Upgraded Kernel Now Tunnel Fails After Some Time

Shadow Hawkins on Monday, 07 April 2014 18:44:57

So specifically, I am running what I believe is 3.2.54-2. I'm wondering if the patch in 3.2.55 would fix this issue: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.55 ipv6: don't count addrconf generated routes against gc limit

Upgraded Kernel Now Tunnel Fails After Some Time

Jeroen Massar SixXS Staff

on Tuesday, 08 April 2014 11:11:40

William Roberts wrote:

You can test that by disabling addrconf on your interfaces. But 'gc' is garbage collector, and those routes should not go away.

Please note Posting is only allowed when you are logged in.