|
Ticket ID: SIXXS #867954 Ticket Status: User PoP: dedus01 - SpeedPartner GmbH (Duesseldorf)
Loss statistic for T16455 / no IKS credits given for running tunnel
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 01 December 2008 11:54:31
Hello,
I'm wondering why my heartbeat tunnel is having a 100% package loss on the statistic page.
I can ping the given IP address from every location I have IPv6 access which are three different servers on the outside. Also I can ping the IP from http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php
Is this the reason I do not see a last alive date?
I also have not many IKS credits although the tunnel is up and running since August this year.
This results in running out of IKS credits - I cannot create a subnet for the new created tunnel.
Maybe you can help me out.
Username: MSV6-SIXXS
Tunnel name: T16455
Thanks and kindest regards,
Martin Sebald
State change: user
The state of this ticket has been changed to user
Loss statistic for T16455 / no IKS credits given for running tunnel
I'm wondering why my heartbeat tunnel is having a 100% package loss on the statistic page.
Because your endpoint doesn't respond to ICMPv6 pings that the PoP is sending you? Please see the FAQ.
I can ping the given IP address from every location I have IPv6 access which are three different servers on the outside
"The outside" is not the PoP. How exactly are you routing your packets?
I also have not many IKS credits although the tunnel is up and running since August this year.
If your endpoint doesn't respond to the ICMPv6 pings by the PoP, then it can't count your tunnel as being 'up', thus no, you won't get any extra ISK.
This is all answered in the FAQ.
This results in running out of IKS credits - I cannot create a subnet for the new created tunnel.
Read the FAQ and also read the "Reporting Problems Checklist" as requested several times on the ticket submission page.
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Monday, 01 December 2008 13:36:53
Hello Jeroen,
thank you for your quick reply.
I wrote into the ticket system because I did not know what else to do. I read the FAQ before to check if I made something wrong. Also I was and am sure that my setup is ok.
I'm routing my packets real easy, no big deal. I accept 2 incoming ICMPv6 packets per second and I also accept incoming IPv6 traffic if related (connection tracking). Same as routed IPv6 traffic into the LAN where I also use connection tracking.
I started up tcpdump before lunch and got this when returning:
13:00:47.949517 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:00:47.949664 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:00:59.697470 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:00:59.697585 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:01:12.121661 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:01:12.121824 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:01:25.005819 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:01:25.005948 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:01:38.009671 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:01:38.009788 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:01:51.077899 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:01:51.078081 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:02:04.158118 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:02:04.158251 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:02:17.234058 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:02:17.234195 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:02:30.166258 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:02:30.166377 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:02:43.226760 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:02:43.226885 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:02:56.274801 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:02:56.274913 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:03:09.402640 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:03:09.402751 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:03:22.511650 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:03:22.511772 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:03:35.651959 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:03:35.652112 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:03:48.679415 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:03:48.679555 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:04:01.675992 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:04:01.676165 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:04:14.684119 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:04:14.684249 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:04:27.723179 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:04:27.723341 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:04:40.796947 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:04:40.797060 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
13:04:53.764364 IP6 gw-399.dus-01.de.sixxs.net > cl-399.dus-01.de.sixxs.net: ICMP6, echo request, seq 34049, length 64
13:04:53.764529 IP6 cl-399.dus-01.de.sixxs.net > gw-399.dus-01.de.sixxs.net: ICMP6, echo reply, seq 34049, length 64
Looks pretty much like the 20 pings which are sent by the PoP for me.
Kindest regards,
Martin
Loss statistic for T16455 / no IKS credits given for running tunnel
Looks pretty much like the 20 pings which are sent by the PoP for me.
Doesn't say a thing, as you are not showing the actual IPv4 path that they are being routed over, nor if they are dropped maybe in your firewall etc etc etc.
Please actually try reading the "Reporting Problems Checklist", it is there for a reason.
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Monday, 01 December 2008 14:56:24Doesn't say a thing, as you are not showing the actual IPv4 path that they are being routed over, nor if they are dropped maybe in your firewall etc etc etc.
If it's dropped then it's dropped on the way back. Because it seems to me that my router is replying to pings from the PoP. I also checked my firewall logs and don't see any dropped packets.
Let me try to provide more information, working down the "Reporting Problems Checklist":
"aiccu test" runned through without any problems, all 8 tests passed. I can post the log if you like.
I'm using AICCU 20070115-9, which should be the latest Debian version, also running kernel 2.6.26-1-686 #1 SMP (original Debian) on a Debian 4.0 system.
/etc/network/interfaces:
auto eth0 eth1 sixxs
iface eth0 inet static
address 172.27.0.1
netmask 255.255.255.0
network 172.27.0.0
broadcast 172.27.0.255
iface eth0 inet6 static
address 2a01:198:2b4:0::1
netmask 64
iface eth1 inet dhcp
iface sixxs inet6 manual
up /etc/init.d/aiccu start
up /etc/network/ipv6-routing.sh || true
up /etc/init.d/firewall
post-up /etc/init.d/radvd start
post-down /etc/init.d/radvd stop
down /etc/network/ipv6-routing.sh || true
down /etc/init.d/aiccu stop
iptables/ip6tables Firewall:
#!/bin/sh
echo -n "Starte iptables Firewall..."
modprobe ip_nat_ftp --remove
modprobe ip_conntrack_ftp --remove
modprobe ip_conntrack_ftp ports=21,2266
modprobe ip_nat_ftp
SLN_SENECA_IPv4_1="172.27.0.1"
SLN_SENECA_IPv4_2="172.27.2.1"
SLN_SENECA_IPv6_1="2a01:198:2b4::1/64"
SLN_SENECA_IPv6_2="2a01:198:200:18e::2/64"
SLN_SENECA_NETv4_1="172.27.0.0/24"
SLN_SENECA_NETv4_2="172.27.2.0/24"
SLN_SENECA_NETv6_1="2a01:198:2b4::/48"
SLN_SENECA_NETv6_2="2a01:198:200:18e::/64"
SLN_SENECA_BCv4_1="172.27.0.255"
SLN_SENECA_BCv4_2="172.27.2.255"
SLN_SENECA_INTERFACEv4_LAN="eth0"
SLN_SENECA_INTERFACEv4_WAN="eth1"
SLN_SENECA_INTERFACEv6_LAN="eth0"
SLN_SENECA_INTERFACEv6_WAN="sixxs"
SLN_FTPSERVER_IPv4="172.27.0.2"
SLN_FTPSERVER_IPv6="2a01:198:2b4::1/64"
SLN_TORRENTCLIENT_IPv4="172.27.0.2"
SLN_ATLAN_IPv4="172.27.0.2"
SLN_ATLAN_IPv6="2a01:198:2b4::1/64"
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
# Tables flushen
iptables -F
iptables -F -t nat
iptables -F -t mangle
ip6tables -F
ip6tables -F -t mangle
# alle benutzerdefinierten Tables loeschen
iptables -X
ip6tables -X
# Table log-and-drop-input erstellen
iptables -N log-and-drop-input
iptables -A log-and-drop-input -j LOG --log-prefix "IPTABLES INPUT: " --log-level INFO
iptables -A log-and-drop-input -j DROP
ip6tables -N log-and-drop-input
ip6tables -A log-and-drop-input -j LOG --log-prefix "IP6TABLES INPUT: " --log-level INFO
ip6tables -A log-and-drop-input -j DROP
# Table log-and-drop-forward erstellen
iptables -N log-and-drop-forward
iptables -A log-and-drop-forward -j LOG --log-prefix "IPTABLES FORWARD: " --log-level INFO
iptables -A log-and-drop-forward -j DROP
ip6tables -N log-and-drop-forward
ip6tables -A log-and-drop-forward -j LOG --log-prefix "IP6TABLES FORWARD: " --log-level INFO
ip6tables -A log-and-drop-forward -j DROP
# Table log-and-drop-output erstellen
iptables -N log-and-drop-output
iptables -A log-and-drop-output -j LOG --log-prefix "IPTABLES OUTPUT: " --log-level INFO
iptables -A log-and-drop-output -j DROP
ip6tables -N log-and-drop-output
ip6tables -A log-and-drop-output -j LOG --log-prefix "IP6TABLES OUTPUT: " --log-level INFO
ip6tables -A log-and-drop-output -j DROP
## LOOPBACK
# Allow unlimited traffic on the loopback interface.
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
# IPv6: Remove RH0 vulnerability
ip6tables -A INPUT -m rt --rt-type 0 -j LOG --log-prefix "IP6TABLES RH0-IN: " --log-level INFO
ip6tables -A INPUT -m rt --rt-type 0 -j DROP
ip6tables -A OUTPUT -m rt --rt-type 0 -j LOG --log-prefix "IP6TABLES RH0-OUT: " --log-level INFO
ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -m rt --rt-type 0 -j LOG --log-prefix "IP6TABLES RH0-FORWARD: " --log-level INFO
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
# IP-Maquerading
iptables -t nat -A POSTROUTING -o $SLN_SENECA_INTERFACEv4_WAN -j MASQUERADE
# FTP-Server Weiterleitung
iptables -t nat -A PREROUTING -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 2266 -j DNAT --to $SLN_FTPSERVER_IPv4:21
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_WAN -d $SLN_FTPSERVER_IPv4 -p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Torrent Weiterleitung
iptables -t nat -A PREROUTING -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 6881:6890 -j DNAT --to $SLN_TORRENTCLIENT_IPv4
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_WAN -d $SLN_TORRENTCLIENT_IPv4 -p tcp --dport 6881:6890 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -i $SLN_SENECA_INTERFACEv4_WAN -p udp --dport 6881:6890 -j DNAT --to $SLN_TORRENTCLIENT_IPv4
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_WAN -d $SLN_TORRENTCLIENT_IPv4 -p udp --dport 6881:6890 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Forward RPC nur fuer tun0 (VPN) zulassen
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p tcp --sport 135 -j ACCEPT
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p udp --sport 135 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p tcp --sport 135 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p udp --sport 135 -j ACCEPT
# Forward RPC log-and-drop
iptables -A FORWARD -p tcp --sport 135 -j log-and-drop-forward
iptables -A FORWARD -p udp --sport 135 -j log-and-drop-forward
# Forward NETBIOS nur fuer tun0 (VPN) zulassen
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p tcp --sport 137:139 -j ACCEPT
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p udp --sport 137:139 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p tcp --sport 137:139 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p udp --sport 137:139 -j ACCEPT
# Forward NETBIOS log-and-drop
iptables -A FORWARD -p tcp --sport 137:139 -j log-and-drop-forward
iptables -A FORWARD -p udp --sport 137:139 -j log-and-drop-forward
# Forward SNMP und SNMPTRAP log-and-drop
iptables -A FORWARD -p tcp --sport 161:162 -j log-and-drop-forward
iptables -A FORWARD -p udp --sport 161:162 -j log-and-drop-forward
# Forward Active Directory nur fuer tun0 (VPN) zulassen
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p tcp --sport 445 -j ACCEPT
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -p udp --sport 445 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p tcp --sport 445 -j ACCEPT
iptables -A FORWARD -i tun0 -o $SLN_SENECA_INTERFACEv4_LAN -p udp --sport 445 -j ACCEPT
# Forward Active Directory log-and-drop
iptables -A FORWARD -p tcp --sport 445 -j log-and-drop-forward
iptables -A FORWARD -p udp --sport 445 -j log-and-drop-forward
# Forward nur Pakete an eth0 von 172.27.0.x fuer eth1 und nicht 172.27.0.x
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o $SLN_SENECA_INTERFACEv4_WAN -s $SLN_SENECA_NETv4_1 -d ! $SLN_SENECA_NETv4_1 -j ACCEPT
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_WAN -o $SLN_SENECA_INTERFACEv4_LAN -s ! $SLN_SENECA_NETv4_1 -d $SLN_SENECA_NETv4_1 -m state --state ESTABLISHED,RELATED -j ACCEPT
# IPv6 Forward-Regeln
echo "1" >/proc/sys/net/ipv6/conf/all/forwarding
# ausgehender Forward
ip6tables -A FORWARD -i $SLN_SENECA_INTERFACEv6_LAN -o $SLN_SENECA_INTERFACEv6_WAN -s ff00::/8 -j ACCEPT
ip6tables -A FORWARD -i $SLN_SENECA_INTERFACEv6_LAN -o $SLN_SENECA_INTERFACEv6_WAN -s fe80::/10 -j ACCEPT
ip6tables -A FORWARD -i $SLN_SENECA_INTERFACEv6_LAN -o $SLN_SENECA_INTERFACEv6_WAN -s $SLN_SENECA_NETv6_1 -j ACCEPT
# Connection Tracking eingehender Forward
ip6tables -A FORWARD -o $SLN_SENECA_INTERFACEv6_LAN -i $SLN_SENECA_INTERFACEv6_WAN -d ff00::/8 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -o $SLN_SENECA_INTERFACEv6_LAN -i $SLN_SENECA_INTERFACEv6_WAN -d fe80::/10 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -o $SLN_SENECA_INTERFACEv6_LAN -i $SLN_SENECA_INTERFACEv6_WAN -d $SLN_SENECA_NETv6_1 -m state --state ESTABLISHED,RELATED -j ACCEPT
# 2 Pakete pro Sekunde icmpv6 erlauben
ip6tables -A FORWARD -p icmpv6 -m limit --limit 2/s -j ACCEPT
# Windows Remote Assistance Forward ATLAN (Server)
#ip6tables -A FORWARD -o $SLN_SENECA_INTERFACEv6_LAN -i $SLN_SENECA_INTERFACEv6_WAN -d $SLN_ATLAN_IPv6 -p tcp --dport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# FTP-Server Forward
ip6tables -A FORWARD -o $SLN_SENECA_INTERFACEv6_LAN -i $SLN_SENECA_INTERFACEv6_WAN -d $SLN_FTPSERVER_IPv6 -p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# restlichen Forward verbieten
ip6tables -A FORWARD -j log-and-drop-forward
# Forward nur Pakete ueber eth0 an tun0
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun0 -j ACCEPT
# Forward nur Pakete ueber tun0 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun0 -j ACCEPT
# Forward nur Pakete ueber eth0 an tun1
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun1 -j ACCEPT
# Forward nur Pakete ueber tun1 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun1 -j ACCEPT
# Forward nur Pakete ueber eth0 an tun2
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun2 -j ACCEPT
# Forward nur Pakete ueber tun2 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun2 -j ACCEPT
# Forward nur Pakete ueber eth0 an tun3
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun3 -j ACCEPT
# Forward nur Pakete ueber tun3 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun3 -j ACCEPT
# Forward nur Pakete ueber eth0 an tun4
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun4 -j ACCEPT
# Forward nur Pakete ueber tun4 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun4 -j ACCEPT
# Forward nur Pakete ueber eth0 an tun5
iptables -A FORWARD -i $SLN_SENECA_INTERFACEv4_LAN -o tun5 -j ACCEPT
# Forward nur Pakete ueber tun5 an eth0
iptables -A FORWARD -o $SLN_SENECA_INTERFACEv4_LAN -i tun5 -j ACCEPT
# andere Forwards log-and-drop
iptables -A FORWARD -j log-and-drop-forward
# Input auf eth0 aus lokalem Netz erlauben
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_LAN -s $SLN_SENECA_NETv4_1 -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_LAN -s fe80::/10 -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_LAN -s ff00::/8 -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_LAN -s $SLN_SENECA_NETv6_1 -j ACCEPT
# Input auf tun0, tun1, tun2, tun3, tun4, tun5 erlauben (der Einfachheit halber aus allen Netzen)
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A INPUT -i tun1 -j ACCEPT
iptables -A INPUT -i tun2 -j ACCEPT
iptables -A INPUT -i tun3 -j ACCEPT
iptables -A INPUT -i tun4 -j ACCEPT
iptables -A INPUT -i tun5 -j ACCEPT
# Input SSHD
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 2277 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp --dport 2277 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Input Apache
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 80 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp --dport 80 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Input OpenVPN
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p udp --dport 2255 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p udp --dport 2255 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Input Authentication Service Port 113 (AUTH) log und reject
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 113 -j LOG --log-prefix "IPTABLES AUTH: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --dport 113 -j REJECT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp --dport 113 -j LOG --log-prefix "IP6TABLES AUTH: " --log-level INFO
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp --dport 113 -j REJECT
# Input nur ESTABLISHED und RELATED erlauben
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -m state --state ESTABLISHED,RELATED -j ACCEPT
## SYN-FLOODING PROTECTION
iptables -N syn-flood
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
iptables -A syn-flood -j LOG --log-prefix "IPTABLES SYN-FLOODING: " --log-level INFO
iptables -A syn-flood -j DROP
ip6tables -N syn-flood
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp --syn -j syn-flood
ip6tables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
ip6tables -A syn-flood -j LOG --log-prefix "IP6TABLES SYN-FLOODING: " --log-level INFO
ip6tables -A syn-flood -j DROP
## Make sure NEW tcp connections are SYN packets
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "IPTABLES NEW-TCP-NOT-SYN: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp ! --syn -m state --state NEW -j DROP
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "IP6TABLES NEW-TCP-NOT-SYN: " --log-level INFO
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp ! --syn -m state --state NEW -j DROP
## FRAGMENTS
# Log fragments just to see if we get any, and deny them too.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -f -j LOG --log-prefix "IPTABLES FRAGMENTS: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -f -j DROP
## SPOOFING
# Refuse spoofed packets pretending to be from your IP address.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s $SLN_SENECA_IPv4_1 -j log-and-drop-input
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s $SLN_SENECA_IPv4_2 -j log-and-drop-input
# Refuse packets claiming to be from a Class A private network.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s 10.0.0.0/8 -j log-and-drop-input
# Refuse packets claiming to be from a Class B private network.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s 172.16.0.0/12 -j log-and-drop-input
# Refuse packets claiming to be from a Class C private network.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s 192.168.0.0/16 -j log-and-drop-input
# Refuse Class D multicast addresses. Multicast is illegal as a source address.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s 224.0.0.0/4 -j log-and-drop-input
# Refuse Class E reserved IP addresses.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -s 240.0.0.0/4 -j log-and-drop-input
# Refuse packets claiming to be to the loopback interface.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -d 127.0.0.0/8 -j log-and-drop-input
# Refuse broadcast address packets.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -d $SLN_SENECA_BCv4_1 -j log-and-drop-input
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -d $SLN_SENECA_BCv4_2 -j log-and-drop-input
# Any udp not already allowed is logged and then dropped.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p udp -j LOG --log-prefix "IPTABLES UDP-IN: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p udp -j DROP
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p udp -j LOG --log-prefix "IP6TABLES UDP-IN: " --log-level INFO
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p udp -j DROP
# Nur 2 Pakete pro Sekunde icmp Typ 0, 3, 4, 8, 11, 12 erlauben
#0 - echo-reply
#3 - destination-unreachable
#8 - echo-request
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p icmp --icmp-type echo-reply -m limit --limit 2/s -j ACCEPT
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p icmp --icmp-type destination-unreachable -m limit --limit 2/s -j ACCEPT
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p icmp --icmp-type echo-request -m limit --limit 2/s -j ACCEPT
# Nur 2 Pakete pro Sekunde icmpv6 erlauben
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p icmpv6 -m limit --limit 2/s -j ACCEPT
# icmp Typ 4, 11, 12 sollten durch RELATED abgedeckt sein
#4 - source-quench
#11 - time-exceeded
#12 - parameter-problem
# Any icmp not already allowed is logged and then dropped.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p icmp -j LOG --log-prefix "IPTABLES ICMP-IN: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p icmp -j DROP
# Any tcp not already allowed is logged and then dropped.
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp -j LOG --log-prefix "IPTABLES TCP-IN: " --log-level INFO
iptables -A INPUT -i $SLN_SENECA_INTERFACEv4_WAN -p tcp -j DROP
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp -j LOG --log-prefix "IP6TABLES TCP-IN: " --log-level INFO
ip6tables -A INPUT -i $SLN_SENECA_INTERFACEv6_WAN -p tcp -j DROP
# Anything else not already allowed is logged and then dropped.
# It will be dropped by the default policy anyway ... but let's be paranoid.
iptables -A INPUT -j log-and-drop-input
ip6tables -A INPUT -j log-and-drop-input
# Output RCP log-and-drop
iptables -A OUTPUT -p tcp --sport 135 -j log-and-drop-output
iptables -A OUTPUT -p udp --sport 135 -j log-and-drop-output
ip6tables -A OUTPUT -p tcp --sport 135 -j log-and-drop-output
ip6tables -A OUTPUT -p udp --sport 135 -j log-and-drop-output
# Output NETBIOS log-and-drop
iptables -A OUTPUT -p tcp --sport 137:139 -j log-and-drop-output
iptables -A OUTPUT -p udp --sport 137:139 -j log-and-drop-output
ip6tables -A OUTPUT -p tcp --sport 137:139 -j log-and-drop-output
ip6tables -A OUTPUT -p udp --sport 137:139 -j log-and-drop-output
# Output SNMP und SNMPTRAP log-and-drop
iptables -A OUTPUT -p tcp --sport 161:162 -j log-and-drop-output
iptables -A OUTPUT -p udp --sport 161:162 -j log-and-drop-output
ip6tables -A OUTPUT -p tcp --sport 161:162 -j log-and-drop-output
ip6tables -A OUTPUT -p udp --sport 161:162 -j log-and-drop-output
# Output Active Directory log-and-drop
iptables -A OUTPUT -p tcp --sport 445 -j log-and-drop-output
iptables -A OUTPUT -p udp --sport 445 -j log-and-drop-output
ip6tables -A OUTPUT -p tcp --sport 445 -j log-and-drop-output
ip6tables -A OUTPUT -p udp --sport 445 -j log-and-drop-output
# restlichen Output akzeptieren
iptables -A OUTPUT -j ACCEPT
ip6tables -A OUTPUT -j ACCEPT
echo " fertig!"
IPv4 traceroute to PoP:
traceroute to 91.184.37.98 (91.184.37.98), 30 hops max, 40 byte packets
1 HSI-KBW-078-042-200-001.hsi3.kabel-badenwuerttemberg.de (78.42.200.1) 9.703 ms 6.357 ms 7.222 ms
2 172.30.9.69 (172.30.9.69) 18.539 ms 14.509 ms 8.461 ms
3 172.30.9.169 (172.30.9.169) 8.209 ms 4.802 ms HSI-KBW-078-042-040-241.hsi3.kabel-badenwuerttemberg.de (78.42.40.241) 8.546 ms
4 ae1.FRA-M2.ip-bb.kabel-badenwuerttemberg.de (78.42.40.15) 22.158 ms ae1.FRA-M1.ip-bb.kabel-badenwuerttemberg.de (78.42.40.17) 17.847 ms 12.508 ms
5 decix.r1.fra3.opencarrier.eu (80.81.192.24) 12.140 ms 172.30.30.6 (172.30.30.6) 12.003 ms decix.r1.fra3.opencarrier.eu (80.81.192.24) 15.806 ms
6 oc-fra.speedpartner.de (194.54.95.218) 17.967 ms decix.r1.fra3.opencarrier.eu (80.81.192.24) 12.794 ms oc-fra.speedpartner.de (194.54.95.218) 14.620 ms
7 oc-fra.speedpartner.de (194.54.95.218) 14.682 ms 15.156 ms dedus01.sixxs.net (91.184.37.98) 17.468 ms
IPv6 traceroute to PoP:
traceroute to gw-399.dus-01.de.sixxs.net (2a01:198:200:18e::1) from 2a01:198:200:18e::1, port 80, from port 41194, 30 hops max, 16 byte packets
1 gw-399.dus-01.de.sixxs.net (2a01:198:200:18e::1) [open] 0.226 ms 0.221 ms 0.115 ms
Hope I did not forget anything.
Regards,
Martin
Loss statistic for T16455 / no IKS credits given for running tunnel
7 oc-fra.speedpartner.de (194.54.95.218) 14.682 ms 15.156 ms dedus01.sixxs.net (91.184.37.98) 17.468 ms
1 gw-399.dus-01.de.sixxs.net (2a01:198:200:18e::1) [open] 0.226 ms 0.221 ms 0.115 ms
I would love to have your IPv6 super-magic-latency-optimizer. 0.226ms instead of 14ms, yeah, right.
Then again, the answer is in this line:
traceroute to gw-399.dus-01.de.sixxs.net (2a01:198:200:18e::1) from 2a01:198:200:18e::1, port 80, from port 41194, 30 hops max, 16 byte packets
Hope I did not forget anything.
The routing table, the addresses etc. And I am sure, from the above line, there is something in there which will be very obvious and will clearly demonstrate why you are having this problem.
PS: we are not your firewall-debugging-team. clear it out, and then test what is going wrong (even with it cleared it will fail btw in this case)
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Monday, 01 December 2008 16:00:21
You're right, I did not check the latency times. So it should be clear the traffic to gw-399.dus-01.de.sixxs.net (2a01:198:200:18e::1) is not leaving the router...
PS: we are not your firewall-debugging-team. clear it out, and then test what is going wrong (even with it cleared it will fail btw in this case)
I did not want you to debug my firewall. But as I read the "Reporting problems checklist" I read "full" firewall etc so I put the full firewall into the post. ;-) I like my firewall. Yes, it's huge but it does what I want. Ok, one exeption: this problem here...
So here's some more information:
PoP v6: 2a01:198:200:18e::1
My v6: 2a01:198:200:18e::2
ifconfig sixxs:
sixxs Link encap:IPv6-in-IPv4
inet6 addr: 2a01:198:200:18e::2/64 Scope:Global
inet6 addr: fe80::4e2a:c830/64 Scope:Link
inet6 addr: fe80::ac1c:406/64 Scope:Link
inet6 addr: fe80::ac1c:106/64 Scope:Link
inet6 addr: fe80::ac1c:6/64 Scope:Link
inet6 addr: fe80::ac1b:1/64 Scope:Link
inet6 addr: fe80::ac1c:306/64 Scope:Link
inet6 addr: fe80::ac1b:201/64 Scope:Link
inet6 addr: fe80::ac1c:206/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4168 (4.0 KiB) TX bytes:1007 (1007.0 b)
eth0 is the LAN interface, eth1 is the cable internet interface. 172.27.0.0/24 is local LAN v4. You can forget about the 172.28.*.* nets. These are OpenVPN networks to several servers.
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2a01:198:200:18e::/64 :: U 256 1 0 sixxs
2a01:198:200:18e::/64 :: U 256 0 0 eth0
2a01:198:2b4::/64 :: U 256 0 0 eth0
2000::/3 :: U 1024 0 0 sixxs
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 sixxs
::/0 2a01:198:200:18e::1 UG 1024 0 0 sixxs
::1/128 :: U 0 70 1 lo
2a01:198:200:18e::/128 :: U 0 0 1 lo
2a01:198:200:18e::/128 :: U 0 0 1 lo
2a01:198:200:18e::1/128 :: U 0 5 1 lo
2a01:198:200:18e::2/128 :: U 0 9 1 lo
2a01:198:2b4::/128 :: U 0 0 1 lo
2a01:198:2b4::1/128 :: U 0 3414 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::4e2a:c830/128 :: U 0 0 1 lo
fe80::ac1b:1/128 :: U 0 0 1 lo
fe80::ac1b:201/128 :: U 0 0 1 lo
fe80::ac1c:6/128 :: U 0 0 1 lo
fe80::ac1c:106/128 :: U 0 0 1 lo
fe80::ac1c:206/128 :: U 0 0 1 lo
fe80::ac1c:306/128 :: U 0 0 1 lo
fe80::ac1c:406/128 :: U 0 0 1 lo
fe80::202:ffff:fe00:b55a/128 :: U 0 0 1 lo
fe80::2d0:b7ff:fe9f:c59b/128 :: U 0 1924 1 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixxs
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.28.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun2
172.28.3.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun3
172.27.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.28.1.1 172.28.1.5 255.255.255.255 UGH 0 0 0 tun2
172.28.3.1 172.28.3.5 255.255.255.255 UGH 0 0 0 tun3
172.28.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun4
172.28.2.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
172.28.4.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun5
172.28.0.1 172.28.0.5 255.255.255.255 UGH 0 0 0 tun4
172.28.2.1 172.28.2.5 255.255.255.255 UGH 0 0 0 tun1
172.28.4.1 172.28.4.5 255.255.255.255 UGH 0 0 0 tun5
192.168.6.0 172.27.2.2 255.255.255.0 UG 0 0 0 tun0
192.168.2.0 172.27.2.2 255.255.255.0 UG 0 0 0 tun0
172.16.66.0 172.27.2.2 255.255.255.0 UG 0 0 0 tun0
172.27.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.27.2.0 172.27.2.2 255.255.255.0 UG 0 0 0 tun0
78.42.200.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1
0.0.0.0 78.42.200.1 0.0.0.0 UG 0 0 0 eth1
/etc/default/sixxs:
PREFIX=2a01:198:200:18e::1/64
SUBNET=2a01:198:200:18e/64
ROUTER=2a01:198:200:18e::1/64
LAN=eth0
/etc/network/ipv6-routing.sh:
#!/bin/sh
# Environment:
# IFACE = Logical interface name
# MODE = { start | stop }
# METHOD = manual, otherwise exit
# ADDRFAM = inet6, otherwise exit
# ADDRFAM muss inet6 sein
if [ "$ADDRFAM" != "inet6" ]; then
echo "Fehlerhafter Aufruf ..."
exit -1
fi
# Einstellungen aus /etc/default/sixxs laden:
#
# PREFIX=2001:db8:123::/48
# SUBNET=2001:db8:123:1/64
# ROUTER=2001:db8:123:1::1/64
# LAN=eth0
test -f /etc/default/sixxs && . /etc/default/sixxs || exit -1
# Adressen und Subnetz-Praefix zusammensetzen
echo "Prefix: $PREFIX"
echo "Subnet: $SUBNET"
echo "Router: $ROUTER"
case $MODE in
start)
ACTION=add
;;
stop)
ACTION=del
;;
esac
ip -6 route $ACTION $PREFIX dev lo
ip -6 route $ACTION 2000::/3 dev $IFACE
ip -6 addr $ACTION dev $LAN $ROUTER
Loss statistic for T16455 / no IKS credits given for running tunnel
Ok, one exeption: this problem here...
Which is most likely not even an issue with your "firewall" which is so buggy in so many respects.
PoP v6: 2a01:198:200:18e::1
Remember that really well, and then look at this line:
2a01:198:200:18e::1/128 :: U 0 5 1 lo
You might want to resolve that.
What is the tunnel /64 doing on eth0 btw:
2a01:198:200:18e::/64 :: U 256 0 0 eth0
and why don't you have a nexthop for this 'semi-default' route?:
2000::/3 :: U 1024 0 0 sixxs
Amazing that anything works at all(pure luck that the kernel likes to just throw everything out on the other side of the tunnel without doing any ND). Also, unless you have a broken kernel the normal default:
::/0 2a01:198:200:18e::1 UG 1024 0 0 sixxs
But as the 2000::/3 overrides it that one is never used, otherwise the default would be your local computer, great.
What is this doing there:
ip -6 route $ACTION $PREFIX dev lo
And why are you doing that?
And what is this supposed to do:
ip -6 addr $ACTION dev $LAN $ROUTER
You don't specify any address, except for that of the "Router", which is the PoP. Seems to me you are doing a lot of weird things and you probably can't explain why, not so weird it doesn't work.
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Monday, 01 December 2008 16:36:22Ok, one exeption: this problem here... Which is most likely not even an issue with your "firewall" which is so buggy in so many respects.
I know you're not my firewall debugger as you mentioned above ;-) but maybe you have a state-of-the-art firewall or one or more good examples in the internet. My firewall runs for years now and I did not have the time to look deeply into it so I just added new stuff to the already existing rules. That's all.
Amazing that anything works at all(pure luck that the kernel likes to just throw everything out on the other side of the tunnel without doing any ND). ... You don't specify any address, except for that of the "Router", which is the PoP. Seems to me you are doing a lot of weird things and you probably can't explain why, not so weird it doesn't work.
I used the howto http://www.sixxs.net/faq/connectivity/?faq=ossetup&os=linuxdebian and several hints in the internet when I tried to install the tunnel last summer. After trying and trying it worked.
So it could be that the setup is very weird. I'll take a deep look into later and try to use your hints. Hopefully I can figure out how I set up this correctly.
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Tuesday, 02 December 2008 00:53:50
It works now. I reconfigured start and stop of the sixxs interface, which means the routing stuff related to it. ;-)
I'll post some output (routing tables etc) tomorrow.
Loss statistic for T16455 / no IKS credits given for running tunnel
Shadow Hawkins on Wednesday, 03 December 2008 11:28:59
Ok as promised:
I did not change anything at the firewall.
The sixxs part of /etc/network/interfaces looks like this:
auto sixxs
iface sixxs inet6 manual
up /etc/init.d/aiccu start
up /etc/init.d/firewall
post-up /etc/network/ipv6-routing.sh || true
post-up /etc/init.d/radvd start
post-down /etc/init.d/radvd stop
post-down /etc/network/ipv6-routing.sh || true
down /etc/init.d/aiccu stop
New /etc/network/ipv6-routing.sh:
#!/bin/sh
# ADDRFAM muss inet6 sein
if [ "$ADDRFAM" != "inet6" ]; then
echo "Fehlerhafter Aufruf ..."
exit -1
fi
test -f /etc/default/sixxs && . /etc/default/sixxs || exit -1
case $MODE in
start)
ACTION=add
;;
stop)
ACTION=del
;;
esac
ip -6 route add 2000::/3 via $ROUTER
New /etc/default/sixxs:
ROUTER=2a01:198:200:18e::1
The new routing table:
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2a01:198:200:18e::/64 :: U 256 15682 0 sixxs
2a01:198:2b4::/64 :: U 256 0 0 eth0
2000::/3 2a01:198:200:18e::1 UG 1024 64532 0 sixxs
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 sixxs
::/0 2a01:198:200:18e::1 UG 1024 0 0 sixxs
::1/128 :: U 0 151 1 lo
2a01:198:200:18e::/128 :: U 0 0 1 lo
2a01:198:200:18e::2/128 :: U 0 15824 1 lo
2a01:198:2b4::/128 :: U 0 0 1 lo
2a01:198:2b4::1/128 :: U 0 5669 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::4e2a:c830/128 :: U 0 0 1 lo
fe80::ac1b:1/128 :: U 0 0 1 lo
fe80::ac1b:201/128 :: U 0 0 1 lo
fe80::ac1c:6/128 :: U 0 0 1 lo
fe80::ac1c:106/128 :: U 0 0 1 lo
fe80::ac1c:206/128 :: U 0 0 1 lo
fe80::ac1c:306/128 :: U 0 0 1 lo
fe80::ac1c:406/128 :: U 0 0 1 lo
fe80::202:ffff:fe00:b55a/128 :: U 0 0 1 lo
fe80::2d0:b7ff:fe9f:c59b/128 :: U 0 4354 1 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixxs
Does it look ok now?
I still got a problem and I don't know if it is new. I think so but I cannot say for sure: The tunnel seems to be not 100% there. Which means it flaps away and is back again without me or the router doing anything. If you watch the statistics this night you see that the tunnel endpoint was not reachable by the PoP over several long periods.
Because I think it was not so before I'm wondering why this is now... When IPv6 is going down here I notice it because clients are still trying to get hosts via IPv6 for some time.
Regards,
Martin
|
![[ch]](/s/countries/ch.gif)
on Monday, 01 December 2008 11:55:06
Posting is only allowed when you are