|
Ticket ID: SIXXS #3851673 Ticket Status: User PoP: deham02 - Easynet (Hamburg)
Tunnel stopped working
![[de]](/s/countries/de.gif) Shadow Hawkins on Tuesday, 08 March 2011 02:08:09
Hi,
my NIC handle is VKZ4-SIXXS, the tunnel in question is T55253.
My setup: PC with Windows 7 / Fedora 14 (dual boot) using AICCU on LAN with NAT Router, setup didn't change for weeks.
Problem: The tunnel is not working, i.e. I can't ping any given IPv6 address but my own (2001:6f8:1c00:3af::2), not even the POP's IPv6 tunnel endpoint (2001:6f8:1c00:3af::1).
I can ping the POP's IPv4 endpoint (212.224.0.189)
The problem was first discovered during a Windows session at approximately 01:00AM UTC+1, then confirmed under Fedora.
This is the output of a ping6 2001:6f8:1c00:3af::1 on my IPv6 enabled server (using POP decgn01):
PING 2001:6f8:1c00:3af::1(2001:6f8:1c00:3af::1) 56 data bytes
From 2001:6f8:800:1003::3 icmp_seq=1 Destination unreachable: No route
From 2001:6f8:800:1003::3 icmp_seq=2 Destination unreachable: No route
...
This is the complete output of the aiccu autotest on Fedora:
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.1.77)
### 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.1.77 (192.168.1.77) 56(84) bytes of data.
64 bytes from 192.168.1.77: icmp_req=1 ttl=64 time=0.047 ms
64 bytes from 192.168.1.77: icmp_req=2 ttl=64 time=0.036 ms
64 bytes from 192.168.1.77: icmp_req=3 ttl=64 time=0.031 ms
--- 192.168.1.77 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.031/0.038/0.047/0.006 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (212.224.0.189)
### 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 212.224.0.189 (212.224.0.189) 56(84) bytes of data.
64 bytes from 212.224.0.189: icmp_req=1 ttl=53 time=43.9 ms
64 bytes from 212.224.0.189: icmp_req=2 ttl=53 time=43.7 ms
64 bytes from 212.224.0.189: icmp_req=3 ttl=53 time=43.2 ms
--- 212.224.0.189 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 43.236/43.642/43.948/0.344 ms
######
####### [3/8] Traceroute to the PoP (212.224.0.189) 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 212.224.0.189 (212.224.0.189), 30 hops max, 60 byte packets
1 alice.box (192.168.1.1) 1.756 ms 2.047 ms 2.692 ms
2 rdsl-mnsr-de01.nw.mediaways.net (213.20.59.10) 25.356 ms 27.427 ms 29.610 ms
3 xmws-mnsr-de03-chan-18-0.nw.mediaways.net (195.71.10.242) 30.611 ms 31.823 ms 33.137 ms
4 xmws-frnk-de07-chan-0.nw.mediaways.net (213.20.249.202) 46.614 ms 48.120 ms 49.671 ms
5 te0-0-0-5.er10.ixfra.de.easynet.net (80.81.192.14) 52.156 ms 54.103 ms 55.544 ms
6 te0-1-0.gr11.isham.de.easynet.net (87.86.77.80) 64.312 ms 54.078 ms 55.443 ms
7 ge1-11.br3.isham.de.easynet.net (87.86.69.169) 155.357 ms 139.869 ms 140.240 ms
8 ge9-15.cr20.isham.de.easynet.net (212.224.4.93) 45.691 ms 44.082 ms 46.131 ms
9 212.224.0.189 (212.224.0.189) 47.566 ms 43.473 ms 44.796 ms
######
###### [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.036 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.036 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.036/0.038/0.042/0.003 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:6f8:1c00:3af::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:6f8:1c00:3af::2(2001:6f8:1c00:3af::2) 56 data bytes
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=3 ttl=64 time=0.040 ms
--- 2001:6f8:1c00:3af::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.037/0.038/0.040/0.005 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:6f8:1c00:3af::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 succesful then this could be both
### a firewalling and a routing/interface problem
PING 2001:6f8:1c00:3af::1(2001:6f8:1c00:3af::1) 56 data bytes
--- 2001:6f8:1c00:3af::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
######
###### [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 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### [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 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
This is the complete interface, routing and firewall information of my system:
[vince@phoenix ~]$ sudo 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 UNKNOWN qlen 1000
link/ether 80:ee:73:09:f4:e3 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.77/24 brd 192.168.1.255 scope global eth0
inet6 fe80::82ee:73ff:fe09:f4e3/64 scope link
valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.137.1/24 brd 192.168.137.255 scope global vmnet1
inet6 fe80::250:56ff:fec0:1/64 scope link
valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.230.1/24 brd 192.168.230.255 scope global vmnet8
inet6 fe80::250:56ff:fec0:8/64 scope link
valid_lft forever preferred_lft forever
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether c6:3c:d8:b5:34:5c brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
7: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
14: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet6 2001:6f8:1c00:3af::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4f8:1c00:3af:2/64 scope link
valid_lft forever preferred_lft forever
[vince@phoenix ~]$ sudo ip r
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.77 metric 1
192.168.230.0/24 dev vmnet8 proto kernel scope link src 192.168.230.1
192.168.137.0/24 dev vmnet1 proto kernel scope link src 192.168.137.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
default via 192.168.1.1 dev eth0 proto static
[vince@phoenix ~]$ sudo ip -6 r
2001:6f8:1c00:3af::/64 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 0
fe80::/64 dev vmnet1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev vmnet8 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 0
default via 2001:6f8:1c00:3af::1 dev sixxs metric 1024 mtu 1280 advmss 1220 hoplimit 0
[vince@phoenix ~]$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
10313 9068K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4 336 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
13 560 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:8080
106 18555 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 11054 packets, 1434K bytes)
pkts bytes target prot opt in out source destination
[vince@phoenix ~]$ sudo ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+88.198.70.163 193.67.79.202 2 u 10 64 37 38.398 -24.057 16.427
+178.26.105.100 .DCFi. 1 u 7 64 77 56.323 -28.987 16.200
+85.214.100.186 81.169.163.105 3 u 38 64 37 47.221 -27.418 13.024
+141.40.103.102 192.53.103.108 2 u 33 64 77 41.152 -20.881 15.881
+85.214.23.162 192.53.103.104 2 u 48 64 37 44.683 -24.718 13.664
*131.188.3.223 .PPS. 1 u 46 64 77 37.888 -19.258 16.802
+62.75.181.148 134.34.3.18 2 u 41 64 77 35.148 -19.601 15.400
+46.4.54.78 129.69.1.153 2 u 39 64 77 39.083 -21.231 16.178
Regards Vincent Kaibarta
State change: user
The state of this ticket has been changed to user
Tunnel stopped working
The PoP indicates that no valid AYIYA packets where received and thus the tunnel is not up on the PoP side.
106 18555 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
That definitely will cause packets to disappear (which clearly is happening) when there is no state and state goes away when you don't use the tunnel from your side as one example.
Please peruse the forums for resolving your issue, as this is not a ticket system for debugging firewall rules.
Tunnel stopped working
Shadow Hawkins on Tuesday, 08 March 2011 16:47:09
Dear Jeroen,
I can not confirm that this problem is caused by my firewall settings as it persists with the firewall deactivated which I did of course test before but forgot to state in my original ticket. Also, the tunnel is in use regularly.
[vince@phoenix yum.repos.d]$ sudo /etc/init.d/iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
[vince@phoenix yum.repos.d]$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 9 packets, 691 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 10 packets, 795 bytes)
pkts bytes target prot opt in out source destination
[vince@phoenix yum.repos.d]$ sudo aiccu autotest
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.1.77)
### 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.1.77 (192.168.1.77) 56(84) bytes of data.
64 bytes from 192.168.1.77: icmp_req=1 ttl=64 time=0.040 ms
64 bytes from 192.168.1.77: icmp_req=2 ttl=64 time=0.041 ms
64 bytes from 192.168.1.77: icmp_req=3 ttl=64 time=0.043 ms
--- 192.168.1.77 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.040/0.041/0.043/0.005 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (212.224.0.189)
### 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 212.224.0.189 (212.224.0.189) 56(84) bytes of data.
64 bytes from 212.224.0.189: icmp_req=1 ttl=53 time=44.1 ms
64 bytes from 212.224.0.189: icmp_req=2 ttl=53 time=43.5 ms
64 bytes from 212.224.0.189: icmp_req=3 ttl=53 time=44.2 ms
--- 212.224.0.189 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 43.559/43.992/44.284/0.395 ms
######
####### [3/8] Traceroute to the PoP (212.224.0.189) 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 212.224.0.189 (212.224.0.189), 30 hops max, 60 byte packets
1 alice.box (192.168.1.1) 3.964 ms 4.259 ms 4.613 ms
2 rdsl-mnsr-de01.nw.mediaways.net (213.20.59.10) 25.309 ms 27.489 ms 29.117 ms
3 xmws-mnsr-de03-chan-18-0.nw.mediaways.net (195.71.10.242) 30.943 ms 31.983 ms 33.000 ms
4 xmws-frnk-de07-chan-0.nw.mediaways.net (213.20.249.202) 83.998 ms 48.162 ms 49.816 ms
5 te0-0-0-5.er10.ixfra.de.easynet.net (80.81.192.14) 51.970 ms 53.359 ms 54.901 ms
6 te0-1-0.gr11.isham.de.easynet.net (87.86.77.80) 64.546 ms 54.385 ms 55.736 ms
7 ge1-11.br3.isham.de.easynet.net (87.86.69.169) 57.153 ms 45.356 ms 46.778 ms
8 ge9-15.cr20.isham.de.easynet.net (212.224.4.93) 47.521 ms 44.228 ms 45.407 ms
9 212.224.0.189 (212.224.0.189) 47.027 ms 44.139 ms 44.661 ms
######
###### [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.042 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.051 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.046 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.042/0.046/0.051/0.006 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:6f8:1c00:3af::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:6f8:1c00:3af::2(2001:6f8:1c00:3af::2) 56 data bytes
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=2 ttl=64 time=0.049 ms
64 bytes from 2001:6f8:1c00:3af::2: icmp_seq=3 ttl=64 time=0.049 ms
--- 2001:6f8:1c00:3af::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.040/0.046/0.049/0.004 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:6f8:1c00:3af::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 succesful then this could be both
### a firewalling and a routing/interface problem
PING 2001:6f8:1c00:3af::1(2001:6f8:1c00:3af::1) 56 data bytes
--- 2001:6f8:1c00:3af::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
######
###### [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 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### [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 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
[vince@phoenix yum.repos.d]$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 85 packets, 6854 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 290 packets, 35099 bytes)
pkts bytes target prot opt in out source destination
[vince@phoenix yum.repos.d]$
Regards Vincent
Tunnel stopped working
I can not confirm that this problem is caused by my firewall settings as it persists with the firewall deactivated which I did of course test before but forgot to state in my original ticket. Also, the tunnel is in use regularly.
As stated, we are not your debugging help.
As also stated, please actually provide ALL the information requested as per the contact page.
|
![[ch]](/s/countries/ch.gif)
on Tuesday, 08 March 2011 09:21:35
Posting is only allowed when you are