SixXS::Sunset 2017-06-06

proto-41 tunnel "drops" connection
[at] Shadow Hawkins on Wednesday, 05 November 2008 19:26:36
[ admin-edit: s/6to4/proto-41/ as a 6to4 tunnel is a proto-41 tunnel with 2002:aabb:ccdd::/48 addresses, and that is something that has nothing to do with SixXS, see wikipedia for the details/differences ] Hi, According to my logfile, my SixxS tunnel was up and running for 37 (!!) weeks without problems. For a few days, I'm getting "Tunnel downtime" mails although I did not change anything that has something to do with IPv6. I've setup the tunnel correctly with this script:
LOCALIP=93.83.102.170 POPIP=193.109.122.244 LOCTUN=2001:7b8:2ff:196::2 REMTUN=2001:7b8:2ff:196::1 START=50 ip tunnel add sixxs mode sit local $LOCALIP remote $POPIP ip link set sixxs up ip link set mtu 1280 dev sixxs ip tunnel change sixxs ttl 64 ip -6 addr add $LOCTUN/64 dev sixxs ip -6 ro add default via $REMTUN dev sixxs
Well, the tunnel itself works for a period of time but then suddenly it "drops" the connection. This can take a few minutes or a few hours. But everything stays configured as it should in this case: The routes, the interfaces, everything is up. Therefore I tried debugging with tcpdump. When I
tcpdump -i eth0.1 'proto 41'
(the externel interface) I receive ping packets but ONLY for example the ICMP request but NOT the responses. When I
tcpdump -i sixxs
there is no traffic any more! It seems that suddenly during operation the packet is not forwarded from the external interface to the sixxs interface (tunnel interface). Very, very strange :-( What could be the problem? How could I debug? I have to idea now what to do :-( I have also tried temporarily ACCEPTing the INPUT, OUTPUT and FORWARD chains in iptables; same result. And now the very strange thing: The tunnel becomes up again when I * ping out into the internet with IPv6 from my private subnet behind (!) * restart my script above * restart the computer It would be great if anybody could help me! Niki
proto-41 tunnel "drops" connection
[ch] Jeroen Massar SixXS Staff on Wednesday, 05 November 2008 19:42:51
See: My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker What you describe is exactly that... strange that you only run into that now.
proto-41 tunnel "drops" connection
[at] Shadow Hawkins on Thursday, 06 November 2008 18:26:21
Thank you very much for pointing me to this! I read this FAQ entry some time ago but I did not remember any more. The problem is exactly what is described: The tunnel runs on a NAT machine, the tunnel is down UNTIL traffic is genereted from inside and stays up for a while. And now I also know why it happened now: In the subnet is a Server connected to the tunnel. A few days ago I've setup another tunnel but on another VLAN on the server. Autoconfig was enabled. What happened? Both subnets published their configuration to the server and the server had now two default routes. But it took now the defaultroute throguh the other subnet. The server is always on and continously sends IPv6 pings to the internet. Therefore, the tunnel never "broke down". Now, these ping go through the other tunnel. There is no continous traffic through the first tunnel any more, causing the NAT tracker to break down the tunnel. But: First, I do not understand the issue. Yes, the machine runs NAT but the tunnel is on the machine itself which has a static IP. And normally, only forwarded packets whould be NATed. So these IP-41 packets on the NAT-Router shouldn't be NATed (or tracked). Second, the solution does not work for me :-( The tunnel runs on a WRT54GL with OpenWRT. The default MASQUERADE rule produced by OpenWRT is:
# iptables -L -t nat -v [...] Chain POSTROUTING (policy ACCEPT 1282 packets, 67383 bytes) pkts bytes target prot opt in out source destination 2476 131K postrouting_rule all -- any any anywhere anywhere 1190 64662 MASQUERADE all -- any eth0.1 anywhere anywhere 4 326 SNAT all -- any br-lan 192.168.200.0/24 nobaq.intra.nobaq.net to:93.83.102.170 0 0 SNAT all -- any br-lan 192.168.200.0/24 ns0.intra.nobaq.net to:93.83.102.171 [...]
which is generated by
iptables -t nat -A POSTROUTING -o eth0.1 -j MASQUERADE
Now, I placed the following line into /etc/firewall.user:
iptables -t nat -R POSTROUTING 2 --proto ! 41 -o eth0.1 -j MASQUERADE
causing the line above to change to after boot:
# iptables -L -t nat -v [...] Chain POSTROUTING (policy ACCEPT 1282 packets, 67383 bytes) pkts bytes target prot opt in out source destination 2476 131K postrouting_rule all -- any any anywhere anywhere 1190 64662 MASQUERADE !ipv6 -- any eth0.1 anywhere anywhere 4 326 SNAT all -- any br-lan 192.168.200.0/24 nobaq.intra.nobaq.net to:93.83.102.170 0 0 SNAT all -- any br-lan 192.168.200.0/24 ns0.intra.nobaq.net to:93.83.102.171 [...]
This should be correct, shouldn't it? Where else could I search? The NOTRACK-options is actually not available on OpenWRT :-( Is it possible to somehow view the NAT table and the "tracked" connections? Best regards, Niki
proto-41 tunnel "drops" connection
[au] Shadow Hawkins on Tuesday, 18 November 2008 04:38:01
From: http://lists.netfilter.org/pipermail/netfilter/2006-August/066486.html Sems to work for me. Assuming that the local IPv6 tunnel endpoint IPv4 address is 192.168.0.2 and the router's external interface is ppp0, try this : # inbound destination NAT for IPv6 tunnel iptables -t nat -A PREROUTING -i ppp0 -p 41 -j DNAT --to 192.168.0.2 # inbound forwarding for IPv6 tunnel iptables -t filter -A FORWARD -i ppp0 -p 41 -d 192.168.0.2 -j ACCEPT AFAIK, adding these rules to iptables completely gets around any CONNTRACK issues.

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

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker