Forum - Connection lost after a few seconds :: SixXS

Connection lost after a few seconds

Shadow Hawkins on Monday, 15 July 2013 09:11:03

Hey everyone, I hope someone can help me with my problem of my v6-Tunnel. I have no more ideas what it could be :/ The problem I have with the v6-Tunnel is the following: If I start AICCU I have a working IPv6 connection for a few seconds (mostly between 15 - 60 seconds). After that, the connection is going down (or connection is lost) and no more IPv6 traffic is sent (or received) until I restart AICCU - and then the problem starts from the beginning. This happend after an AICCU restart:

[root@rasp:~] > ping6 2001:4dd0:ff00:1348::1 PING 2001:4dd0:ff00:1348::1(2001:4dd0:ff00:1348::1) 56 data bytes 64 bytes from 2001:4dd0:ff00:1348::1: icmp_seq=1 ttl=64 time=11.5 ms [...] 64 bytes from 2001:4dd0:ff00:1348::1: icmp_seq=31 ttl=64 time=8.76 ms ^C --- 2001:4dd0:ff00:1348::1 ping statistics --- 45 packets transmitted, 31 received, 31% packet loss, time 44051ms rtt min/avg/max/mdev = 8.594/9.726/21.853/2.310 ms

My setup: Router (D-Link, NAT) On the local site (LAN): -> Raspberry Pi (with Wheezy) for IPv6 (AICCU) -> My Workstation (IPv4 directly over the router, IPv6 over Raspberry) -> some other devices like NAS, Smartphone and Notebook "aiccu test" Output:

####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.0.11) ### This should return so called 'echo replies' ### If it doesn't then check your firewall settings ### Your local endpoint should always be pingable ### It could also indicate problems with your IPv4 stack PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data. 64 bytes from 192.168.0.11: icmp_req=1 ttl=64 time=0.213 ms 64 bytes from 192.168.0.11: icmp_req=2 ttl=64 time=0.172 ms 64 bytes from 192.168.0.11: icmp_req=3 ttl=64 time=0.168 ms --- 192.168.0.11 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.168/0.184/0.213/0.023 ms ###### Did this work? [Y/n] Y ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (78.35.24.124) ### These pings should reach the PoP and come back to you ### In case there are problems along the route between your ### host and the PoP this could not return replies ### Check your firewall settings if problems occur PING 78.35.24.124 (78.35.24.124) 56(84) bytes of data. 64 bytes from 78.35.24.124: icmp_req=1 ttl=55 time=14.2 ms 64 bytes from 78.35.24.124: icmp_req=2 ttl=55 time=10.7 ms 64 bytes from 78.35.24.124: icmp_req=3 ttl=55 time=9.63 ms --- 78.35.24.124 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 9.631/11.553/14.253/1.969 ms ###### Did this work? [Y/n] Y ####### [3/8] Traceroute to the PoP (78.35.24.124) over IPv4 ### This traceroute should reach the PoP ### In case this traceroute fails then you have no connectivity ### to the PoP and this is most probably the problem traceroute to 78.35.24.124 (78.35.24.124), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 0.634 ms 0.521 ms 0.378 ms 2 10.154.64.1 (10.154.64.1) 9.413 ms 9.188 ms 8.942 ms 3 1311A-MX960-01-ae15-1040.cgn.unity-media.net (80.69.103.193) 9.039 ms 8.826 ms 8.501 ms 4 13NOC-MX960-02-ae4.krp.unity-media.net (80.69.106.205) 9.653 ms 9.530 ms 9.272 ms 5 1411G-MX960-02-ae9.nss.unity-media.net (80.69.107.6) 35.202 ms 34.948 ms 34.813 ms 6 1411G-MX960-01-ae0.nss.unity-media.net (80.69.107.205) 10.386 ms 12.385 ms 12.168 ms 7 rtint3-po1.netcologne.de (194.146.118.3) 13.183 ms 12.609 ms 12.422 ms 8 core-pg1-po4.netcologne.de (87.79.16.29) 10.814 ms 10.594 ms 10.404 ms 9 core-eup2-t41.netcologne.de (87.79.16.205) 10.188 ms 10.014 ms 13.555 ms 10 sixxs-pop1.netcologne.net (78.35.24.124) 14.798 ms 14.672 ms 13.665 ms ###### Did this work? [Y/n] Y ###### [4/8] Checking if we can ping IPv6 localhost (::1) ### This confirms if your IPv6 is working ### If ::1 doesn't reply then something is wrong with your IPv6 stack PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.275 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.240 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.239 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.239/0.251/0.275/0.021 ms ###### Did this work? [Y/n] Y ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4dd0:ff00:1348::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:4dd0:ff00:1348::2(2001:4dd0:ff00:1348::2) 56 data bytes 64 bytes from 2001:4dd0:ff00:1348::2: icmp_seq=1 ttl=64 time=0.310 ms 64 bytes from 2001:4dd0:ff00:1348::2: icmp_seq=2 ttl=64 time=0.257 ms 64 bytes from 2001:4dd0:ff00:1348::2: icmp_seq=3 ttl=64 time=0.254 ms --- 2001:4dd0:ff00:1348::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.254/0.273/0.310/0.032 ms ###### Did this work? [Y/n] Y ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4dd0:ff00:1348::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was successful then this could be both ### a firewalling and a routing/interface problem PING 2001:4dd0:ff00:1348::1(2001:4dd0:ff00:1348::1) 56 data bytes 64 bytes from 2001:4dd0:ff00:1348::1: icmp_seq=1 ttl=64 time=13.6 ms 64 bytes from 2001:4dd0:ff00:1348::1: icmp_seq=2 ttl=64 time=10.5 ms 64 bytes from 2001:4dd0:ff00:1348::1: icmp_seq=3 ttl=64 time=10.5 ms --- 2001:4dd0:ff00:1348::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 10.527/11.579/13.649/1.468 ms ###### Did this work? [Y/n] Y ###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c), 30 hops max, 80 byte packets 1 gw-4937.cgn-01.de.sixxs.net (2001:4dd0:ff00:1348::1) 14.281 ms 13.712 ms 13.213 ms 2 2001:4dd0:1234:3::42 (2001:4dd0:1234:3::42) 12.709 ms 15.614 ms 15.194 ms 3 core-eup2-ge1-22.netcologne.de (2001:4dd0:1234:3:dc40::a) 19.621 ms 19.176 ms 18.690 ms 4 rtamsix-te4-2.netcologne.de (2001:4dd0:a2b:6d:30::b) 16.433 ms 19.644 ms 19.197 ms 5 ams-ix.ipv6.concepts.nl (2001:7f8:1::a501:2871:1) 19.306 ms 18.818 ms 17.837 ms 6 2001:838:5:a::2 (2001:838:5:a::2) 19.077 ms 22.355 ms 21.783 ms 7 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 20.839 ms 19.982 ms 19.888 ms ###### Did this work? [Y/n] Y ###### [8/8] Traceroute6 to (www.kame.net) ### This confirms that you can reach a Japanese IPv6 destination ### If that one is reachable you should be able to reach most IPv6 destinations ### You should also check http://www.kame.net which should display ### a animated kame (turtle), of course only when your browser supports and uses IPv6 traceroute to www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7), 30 hops max, 80 byte packets 1 gw-4937.cgn-01.de.sixxs.net (2001:4dd0:ff00:1348::1) 13.296 ms 12.473 ms 16.660 ms 2 2001:4dd0:1234:3::42 (2001:4dd0:1234:3::42) 16.243 ms 15.767 ms 15.284 ms 3 core-eup2-ge1-22.netcologne.de (2001:4dd0:1234:3:dc40::a) 14.794 ms 14.233 ms 16.559 ms 4 rtint5-te2-1.netcologne.de (2001:4dd0:a2b:2f:dc40::b) 16.583 ms 16.104 ms 15.626 ms 5 kol-b2-link.telia.net (2001:2000:3080:d2::1) 14.204 ms 13.695 ms 13.216 ms 6 ffm-b12-v6.telia.net (2001:2000:3018:4a::1) 19.104 ms 18.197 ms 17.281 ms 7 ntt-ic-155239-ffm-b12.c.telia.net (2001:2000:3080:58e::2) 19.300 ms 18.399 ms 18.107 ms 8 ae-2.r20.frnkge04.de.bb.gin.ntt.net (2001:728:0:2000::65) 16.618 ms 19.721 ms 19.466 ms 9 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::6e) 26.693 ms 26.193 ms 24.273 ms 10 ae-0.r22.amstnl02.nl.bb.gin.ntt.net (2001:418:0:2000::1c5) 29.553 ms 27.408 ms 32.811 ms 11 as-0.r25.tokyjp05.jp.bb.gin.ntt.net (2001:418:0:2000::16) 322.673 ms 312.105 ms 326.888 ms 12 po-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:0:6000::116) 310.398 ms 304.316 ms 330.834 ms 13 ge-8-2.a15.tokyjp01.jp.ce.gin.ntt.net (2001:218:2000:5000::82) 376.466 ms 374.507 ms 374.246 ms 14 ve44.foundry6.otemachi.wide.ad.jp (2001:200:0:10::141) 317.263 ms 290.224 ms 285.328 ms 15 ve42.foundry4.nezu.wide.ad.jp (2001:200:0:11::66) 286.219 ms 284.205 ms 294.521 ms 16 2001:200:0:1c0a::80 (2001:200:0:1c0a::80) 294.056 ms 284.824 ms 292.110 ms 17 2001:200:dff:fff1:216:3eff:feb1:44d7 (2001:200:dff:fff1:216:3eff:feb1:44d7) 317.313 ms 322.955 ms 316.716 ms ###### Did this work? [Y/n] Y ###### ACCU Quick Connectivity Test (done)

I'm using the latest AICCU Version from the Raspbian Wheezy Repository: aiccu 20070115-15.1 armhf Information about my Raspberry: [root@rasp:~] > cat /etc/issue Debian GNU/Linux 7 \n \l [root@rasp:~] > uname -a Linux rasp 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux My Raspberry is ntp-synced. Information about interface, routing and firewall setup:

[root@rasp:~] > ip a 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 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether b8:27:eb:62:68:3f brd ff:ff:ff:ff:ff:ff inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0 inet6 2001:4dd0:ff00:9348::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe62:683f/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN link/sit 0.0.0.0 brd 0.0.0.0 inet6 ::192.168.0.11/96 scope global valid_lft forever preferred_lft forever inet6 ::127.0.0.1/96 scope host valid_lft forever preferred_lft forever 16: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500 link/none inet6 2001:4dd0:ff00:1348::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::4cd0:ff00:1348:2/64 scope link valid_lft forever preferred_lft forever [root@rasp:~] > ip r default via 192.168.0.1 dev eth0 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11 [root@rasp:~] > ip -6 r ::/96 via :: dev sit0 metric 256 2001:4dd0:ff00:1348::/64 dev sixxs proto kernel metric 256 2001:4dd0:ff00:9348::/64 dev eth0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 fe80::/64 dev sixxs proto kernel metric 256 default via 2001:4dd0:ff00:1348::1 dev sixxs metric 1024 [root@rasp:~] > 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@RaspiX:~] > ip6tables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT icmpv6 ::/0 ::/0 ACCEPT all ::/0 ::/0 ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED ACCEPT all ::/0 ::/0 DROP all ::/0 ::/0 rt type:0 segsleft:0 ACCEPT all fe80::/10 ::/0 ACCEPT all ::/0 ff00::/8 Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmpv6 ::/0 ::/0 DROP all ::/0 ::/0 rt type:0 segsleft:0 ACCEPT all ::/0 ::/0 state NEW ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT icmpv6 ::/0 ::/0 ACCEPT all ::/0 ::/0 ACCEPT all ::/0 ::/0 ACCEPT all ::/0 ::/0 DROP all ::/0 ::/0 rt type:0 segsleft:0 ACCEPT all fe80::/10 ::/0 ACCEPT all ::/0 ff00::/8

Thank you in advance. King regards, Dennis

Connection lost after a few seconds

Jeroen Massar SixXS Staff

on Monday, 15 July 2013 12:46:42

If I start AICCU I have a working IPv6 connection for a few seconds (mostly between 15 - 60 seconds).

Sounds like a timeout of some timer somewhere.

[root@rasp:~] > ping6 2001:4dd0:ff00:1348::1

What does a tcpdump of the underlying IPv4 interface show? Any ICMP errors or so? Does the traffic really go out?

####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.0.11)

You are behind a NAT. Check if your NAT times out connections quickly...

traceroute to 78.35.24.124 (78.35.24.124), 30 hops max, 60 byte packets

1 192.168.0.1 (192.168.0.1) 0.634 ms 0.521 ms 0.378 ms

2 10.154.64.1 (10.154.64.1) 9.413 ms 9.188 ms 8.942 ms

That looks even worse, that looks like a double NAT.

3 1311A-MX960-01-ae15-1040.cgn.unity-media.net (80.69.103.193) 9.039 ms 8.826 ms 8.501 ms

Nope, even worse than that, you are behind Carrier Grade NAT. That ISP also provides native IPv6 though in that setup. I have heard various people complaining about the slowness of that system though. Note that you are thus sitting behind 3 layers of NAT, one of which is likely heavily overloaded and might be doing something like transferring your connections to another of their nodes to do load balancing... not a very good situation to be at.

[root@rasp:~] > iptables -L -n

Try doing that with:

iptables -v --list -n --line-numbers

especially the '-v' is important as it will show you which packets are dropped or not. According to your Live Tunnel Status (see your home and then the tunnel) you sometimes sent back ICMP unreachables for your endpoint: ICMPv4 Errors Received : 114, last: 88.153.24.39 2013-07-15 08:01:00 (1373875260; 0 days 04:43:44 ago) Might be related to all this too.

Connection lost after a few seconds

Shadow Hawkins on Tuesday, 16 July 2013 10:31:22

Hey, thanks for your quick response.

What does a tcpdump of the underlying IPv4 interface show? Any ICMP errors or so? Does the traffic really go out?

Its very funny. Actually, the IPv6 Tunnel has an uptime for 5 minutes right now. I try a tcpdump next time. *edit* After writing this post, the v6 connection failed again. There are no ICMP errors in my dump:

[root@rasp:~] > tcpdump -i eth0 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 12:20:23.708026 IP 192.168.0.11.41547 > 78.35.24.124.5072: UDP, length 148 12:20:23.725558 IP 78.35.24.124.5072 > 192.168.0.11.41547: UDP, length 148 12:20:24.708038 IP 192.168.0.11.41547 > 78.35.24.124.5072: UDP, length 148 12:20:24.726048 IP 78.35.24.124.5072 > 192.168.0.11.41547: UDP, length 148

> ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.0.11) You are behind a NAT. Check if your NAT times out connections quickly...

Yep, welcome to German ISPs :) I have no NAT errors in my router log.

Unitymedia offers IPv6 for some customers. But the requirements to get native IPv6 are the following: - you need a Fritzbox as a router - you can't do any IPv4 Portforwarding (if you have native v6) - it's not that stable as IPv4 is (statement from an Unitymedia technician)

Try doing that with:

iptables -v --list -n --line-numbers

especially the '-v' is important as it will show you which packets are dropped or not.

[root@rasp:~] > iptables -v --list -n --line-numbers Chain INPUT (policy ACCEPT 803K packets, 198M bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 451K packets, 72M bytes) num pkts bytes target prot opt in out source destination

I think I'll contact a friend of mine. He works at Unitymedia, so maybe he can do something for me (honestly I don't think so :/).

Connection lost after a few seconds

Jeroen Massar SixXS Staff

on Tuesday, 16 July 2013 12:28:48

After writing this post, the v6 connection failed again.

What does a tcpdump look like while it is failing? In the tcpdump you show it looks a lot like packets are moving fine.

I have no NAT errors in my router log.

But how many NAT levels are there?

- you need a Fritzbox as a router

As a Fritz!Box is more or less just another Linux box that is quite an odd restriction. IP is just IP.

- you can't do any IPv4 Portforwarding (if you have native v6)

But you can't now either as you are behind a NAT. Unless you are doing both those NAT levels... are you?

[root@rasp:~] > iptables -v --list -n --line-numbers

And the IPv6 variant where you have rules?

Connection lost after a few seconds

Shadow Hawkins on Tuesday, 23 July 2013 15:03:40

Hey,

What does a tcpdump look like while it is failing? In the tcpdump you show it looks a lot like packets are moving fine.

You saw a tcpdump when the v6 connection is failing in my previous post :)

> I have no NAT errors in my router log. But how many NAT levels are there?

One NAT level (at home). I don't know (and I can't control it) how many levels my provider is using.

> - you need a Fritzbox as a router As a Fritz!Box is more or less just another Linux box that is quite an odd restriction. IP is just IP.

Of course, it's just a normal router. But that's what my provider said :)

> - you can't do any IPv4 Portforwarding (if you have native v6) But you can't now either as you are behind a NAT. Unless you are doing both those NAT levels... are you?

Actually, I use IPv4 Portforwarding in the normal way: configure a port-forwarding in my D-Link Router and it works.

> [root@rasp:~] > iptables -v --list -n --line-numbers And the IPv6 variant where you have rules?

Sorry, I forgot to post :) Here is my ip6tables rules:

[root@RaspiX:~] > ip6tables -v --list -n --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 78 10104 ACCEPT icmpv6 * * ::/0 ::/0 2 0 0 ACCEPT all lo * ::/0 ::/0 3 0 0 ACCEPT all sixxs * ::/0 ::/0 state RELATED,ESTABLISHED 4 0 0 ACCEPT all eth0 * ::/0 ::/0 5 0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0 6 0 0 ACCEPT all * * fe80::/10 ::/0 7 0 0 ACCEPT all * * ::/0 ff00::/8 Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT icmpv6 * * ::/0 ::/0 2 0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0 3 0 0 ACCEPT all eth0 sixxs ::/0 ::/0 state NEW 4 0 0 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED Chain OUTPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 80 9292 ACCEPT icmpv6 * * ::/0 ::/0 2 0 0 ACCEPT all * lo ::/0 ::/0 3 1 1028 ACCEPT all * sixxs ::/0 ::/0 4 0 0 ACCEPT all * eth0 ::/0 ::/0 5 0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0 6 0 0 ACCEPT all * * fe80::/10 ::/0 7 0 0 ACCEPT all * * ::/0 ff00::/8

Frank Ambacher wrote:

Dennis Steinmann wrote: Is your timezone OK?

My timezone is correct Kind regards, Dennis

Connection lost after a few seconds

Jeroen Massar SixXS Staff

on Tuesday, 23 July 2013 15:53:51

You saw a tcpdump when the v6 connection is failing in my previous post :)

Looks likes tunneled packets are flowing on the IPv4 level there. Unless those port numbers do not map to applications or the application (aiccu) does not pick it up.

Actually, I use IPv4 Portforwarding in the normal way: configure a port-forwarding in my D-Link Router and it works.

That is odd, as you have no control over your ISP NAT. Note that AYIYA does not need any portforwarding tricks.

3 0 0 ACCEPT all sixxs * ::/0 ::/0 state RELATED,ESTABLISHED

You have state tracking there, are you sure that proper state is generated and kept?

5 0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0

That rule should be at the top. You should never see any such packets anymore though. Also you might want to match only the routing header type, matching also segsleft kinda defeats the point as an attacker will always set it to a non-zero value.

6 0 0 ACCEPT all * * fe80::/10 ::/0

You do not actually have to accept all kinds of link-local (unless you really want to), only ICMP is necessary for IPv6 functioning.

Connection lost after a few seconds

Shadow Hawkins on Wednesday, 24 July 2013 08:08:19

Hey,

> Actually, I use IPv4 Portforwarding in the normal way: configure a port-forwarding in my D-Link Router and it works. That is odd, as you have no control over your ISP NAT. Note that AYIYA does not need any portforwarding tricks.

I need v4 portforwarding for other applications - that's the reason, why I don't use the native v6 from Unitymedia. :)

> 3 0 0 ACCEPT all sixxs * ::/0 ::/0 state RELATED,ESTABLISHED You have state tracking there, are you sure that proper state is generated and kept?

5 0 0 DROP all * * ::/0 ::/0 rt type:0 segsleft:0

6 0 0 ACCEPT all * * fe80::/10 ::/0

You do not actually have to accept all kinds of link-local (unless you really want to), only ICMP is necessary for IPv6 functioning.

I tried it without any firewall rules and the v6 connection dropped after 485 ICMPv6 packages. So I think the firewall rules aren't responsible for the problem :/ I wrote a mail to Unitymedia, so I'm waiting for response now :)

Connection lost after a few seconds

Shadow Hawkins on Sunday, 21 July 2013 00:07:03

Dennis Steinmann wrote: Is your timezone OK?

Thank you in advance. King regards, Dennis

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