|
Ticket ID: SIXXS #692478 Ticket Status: User PoP: deham01 - Easynet (Hamburg)
dynamic AYIYA tunnel not working. No UDP packets from PoP
![[de]](/s/countries/de.gif) Shadow Hawkins on Thursday, 20 March 2008 13:46:09
Hello Support,
I can setup the Aiccu tunnel from Linux and get the interface with the IP address. But the traffic isn't flowing. I'm sending out ICMP messages to the other endpoint of the tunnel but I don't get back a response. In Wireshark I can see the tunnel setup using tic.sixxs.net on port 3874. After the negotiation I can see first UDP packets going towards deham01.sixxs.net on port 5072 but there are no incoming packets. I did a UDP traceroute on port 5072 and it looks fine. All routers inbetween seem to be fine.
Interesting is that when I setup the tunnel from the Laptop at home from my DSL connection it works fine. When I run it in my company it doesn't work since two days. Before it worked for months. I checked with my IT admins and they don't block the UDP traffic and they didn't change anything. This is verified using the traceroute.
But something is different and I need it at my company for some important tests.
Thanks and regards,
Thomas Kempf
root@rfrdy-mcg03:/etc# aiccu start
Tunnel Information for T12066:
POP Id : deham01
IPv6 Local : 2001:6f8:900:91b::2/64
IPv6 Remote : 2001:6f8:900:91b::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
root@rfrdy-mcg03:/etc# ping6 2001:6f8:900:91b::1
PING 2001:6f8:900:91b::1(2001:6f8:900:91b::1) 56 data bytes
--- 2001:6f8:900:91b::1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4008ms
root@rfrdy-mcg03:/etc# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.3.103:sip *:* LISTEN
tcp 0 0 *:netbios-ssn *:* LISTEN
tcp 0 0 *:8110 *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
tcp 0 0 *:microsoft-ds *:* LISTEN
tcp 0 0 rfrdy-mcg03.europ:48661 dyna-addons.nllb0:https ESTABLISHED
tcp 0 0 rfrdy-mcg03.europ:45912 rfrdy-scs.europe.no:sip ESTABLISHED
tcp 0 0 localhost:53100 localhost:38098 ESTABLISHED
tcp 0 0 localhost:38098 localhost:53100 ESTABLISHED
tcp6 0 0 *:5900 *:* LISTEN
tcp6 0 0 *:ssh *:* LISTEN
udp 0 0 *:32769 *:*
udp 0 0 rfrdy-mcg03.:netbios-ns *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 rfrdy-mcg03:netbios-dgm *:*
udp 0 0 *:netbios-dgm *:*
udp 0 0 rfrdy-mcg03.europ:33837 deham01.sixxs.net:5072 ESTABLISHED
root@rfrdy-mcg03:/etc# traceroute -U -p 5072 -n deham01.sixxs.net
traceroute to deham01.sixxs.net (212.224.0.188), 30 hops max, 40 byte packets
1 47.163.92.1 0.679 ms 0.955 ms 1.243 ms
2 47.163.254.5 8.402 ms 8.794 ms 9.155 ms
3 47.163.76.3 8.332 ms 8.563 ms 8.792 ms
4 47.163.254.157 8.240 ms 8.322 ms 8.393 ms
5 47.255.2.78 8.233 ms 8.312 ms 8.382 ms
6 47.255.2.49 25.243 ms 26.411 ms 26.226 ms
7 47.255.2.110 26.104 ms 26.677 ms 26.704 ms
8 47.251.2.3 26.628 ms 26.643 ms 27.048 ms
9 47.251.0.11 27.473 ms 27.535 ms 27.610 ms
10 166.63.167.49 29.459 ms 29.399 ms 29.395 ms
11 195.2.12.37 28.961 ms 195.2.12.69 28.407 ms 195.2.12.36 28.863 ms
12 195.2.12.65 28.793 ms 28.757 ms 195.2.12.33 29.067 ms
13 195.2.25.5 29.101 ms 29.085 ms 29.069 ms
14 208.175.240.30 29.318 ms 28.788 ms 28.717 ms
15 130.117.2.18 28.633 ms 28.797 ms 28.729 ms
16 130.117.1.37 37.344 ms 130.117.1.117 37.361 ms 37.711 ms
17 130.117.0.86 36.058 ms 36.289 ms 35.962 ms
18 130.117.16.78 37.518 ms 38.287 ms 37.410 ms
19 193.238.248.16 38.742 ms 38.392 ms 38.385 ms
20 193.238.248.16 38.379 ms 38.642 ms 37.933 ms
21 87.86.71.192 37.680 ms 37.467 ms 37.412 ms
22 87.86.77.62 44.402 ms 44.080 ms 44.768 ms
23 87.86.71.233 43.707 ms 45.469 ms 45.445 ms
24 194.64.4.84 50.259 ms 49.797 ms 49.674 ms
25 212.224.4.89 49.636 ms 49.648 ms 49.337 ms
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@rfrdy-mcg03:/etc#
dynamic AYIYA tunnel not working. No UDP packets from PoP
AYIYA packets get received and traffic gets sent out also:
Last Beat : 2008-03-20 12:29:28 (0 seconds ago)
Octets (in) : 7800
Octets (out) : 47604
Packets (in) : 75
Packets (out) : 524
Endpoint : 47.163.94.161
PoP side is also up:
64 bytes from 2001:6f8:900:91b::1: icmp_seq=1 ttl=56 time=28.1 ms
How sure are you that you don't have a firewall in the middle though?
Clearly you are in a corporate network and behind a NAT and traceroutes don't even go inbound. As it is a corporate network, are you even allowed to use these kind of tunneling mechanisms, creating a hole in their firewall policy. They are most likely giving you an RFC1918 address for a reason, especially as they have 47.0.0.0/8 which should be enough to give everybody and every single thing a public IP address...
Also:
12 as0-dcr2.tsd.cw.net (195.2.10.166) 19.796 ms 19.744 ms 21.160 ms
13 so-4-0-0-dcr1.lnd.cw.net (195.2.9.14) 22.300 ms 21.110 ms 22.970 ms
14 bcr2.lnd.cw.net (195.2.12.69) 21.092 ms 21.092 ms 21.288 ms
15 gi-0-0-0-iar1.lnd.cw.net (195.2.12.46) 21.268 ms 21.249 ms 21.225 ms
16 nortel.lnd.cw.net (166.63.167.50) 24.671 ms 23.454 ms 24.605 ms
17 * * *
18 * * *
Seems they don't even allow traceroute inbound.
dynamic AYIYA tunnel not working. No UDP packets from PoP
Shadow Hawkins on Thursday, 20 March 2008 15:00:18
Of course I'm not 100% sure that there isn't a firewall. NAT isn't used. It worked already and there were no changes.
The traceroute doesn't work inbound. I did the traceroute with the UDP port 5072. This should be opened by the firewall.
What I can see in the Wireshark trace that the outgoing UDP packets are marked as "UDP CHECKSUM INCORRECT" . Are theses packets lost/removed by the tunnel application? Is the AICCU application calculating this?
For security we have the IP tunnel endpoint within a lab-network in a redlan segment.
dynamic AYIYA tunnel not working. No UDP packets from PoP
NAT isn't used
Then what is:
tcp 0 0 192.168.3.103:sip *puh LISTEN
That definitely is RFC1918 space there.
What I can see in the Wireshark trace that the outgoing UDP packets are marked as "UDP CHECKSUM INCORRECT".
That is because most decent OS/Hardware combinations do the checksum calculation in hardware.
As shown above the PoP states that the tunnel is fully up and running and also is trying to send packets but they are lost somewhere on route.
Somewhere between the PoP and your endpoint packets from the PoP to your endpoint are going missing, without an ICMP coming back for them.
Packets from your endpoint to the PoP do arrive and are correctly processed.
For security we have the IP tunnel endpoint within a lab-network in a redlan segment.
What does "redlan segment" mean? Google doesn't know the term either.
dynamic AYIYA tunnel not working. No UDP packets from PoP
Shadow Hawkins on Thursday, 20 March 2008 15:24:58
This is on another interface where I have indeed a NAT. This is another wrt54 device running OpenWRT where I'm testing the tunnel as well. In this scenario, the wrt54 is running the tunnel and I'm moving my laptop behind this NAT. Somehow a sip application is still waiting on this port.
"redlan" is mayby a proprietary name. I call a unsecure network "red".
Thanks for the info that packets from my side are arriving and are processed. I'll check with my IT guys if we could check the firewalls for proper settings.
Thanks and regards,
Thomas
State change: user
The state of this ticket has been changed to user
|
![[ch]](/s/countries/ch.gif)
on Thursday, 20 March 2008 14:36:44
Posting is only allowed when you are