Hi,
First let me explain the situation.
I'd like to setup a regular 6to4 tunnel for my IPv4 address. Sadly my ISP is blocking ICMP Echo. PLEASE don't stop reading now!
To clarify ONLY ICMP Echo is blocked...
The problem is: tunnelbroker/HE has a policy of specifically requesting ICMP Echo verification to check if the host is up and not bogus.
Sadly I cannot influence my ISP...
I'm asking if You can allow me to create a tunnel with an alternate form of verification for the ipv4 endpoint.
I know there's a IPv4 verification method to see if you really own the host: http://tunnelbroker.com/ipv4_verify.php
I KNOW that method is only meant to check if you own the host that you're trying to set the tunnel endpoint to.
Why not let me verify my IP (that my host is up) with this method?
Let me upload a random string file on my webserver so i can perform the "fetch file" option and finally create the tunnel.
Any help is highly appreciated.
Best regards
Also
what's the point of this:
http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&pass=$MD5PASS&user_id=$USERID&tunnel_id=$GTUNID (http://ipv4.tunnelbroker.net/ipv4_end.php)
If I you pick up my IP with AUTO then SURELY my host is reachable!
Please google "ping online" (without the quotes) so you can confirm that ping is being blocked. If so google "traceroute online" to find out where the IMCP packets may be being blocked and post the results. Note that most IP packets have at least two IP addresses. If tunnelbroker.net did not get your IP address it would not know where to send the response.
--- PING 161.53.129.187 (161.53.129.187) 56(84) bytes of data. ---
From 193.198.162.2: icmp_seq=1 Packet filtered
From 193.198.162.2 icmp_seq=1 Packet filtered
From 193.198.162.2 icmp_seq=2 Packet filtered
--- 161.53.129.187 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3001ms
traceroute to 161.53.129.187(161.53.129.187), 20 hops max, 40 byte packets
1 208.64.252.229.uscolo.com (208.64.252.229) 0.331 ms 0.338 ms 0.388 ms
2 208.64.248.17.uscolo.com (208.64.248.17) 0.740 ms 0.808 ms 0.854 ms
3 ae5-148.edge5.LosAngeles1.Level3.net (4.71.142.65) 94.205 ms 94.225 ms 94.228 ms
4 ae-34-80.car4.LosAngeles1.Level3.net (4.69.144.134) 0.808 ms ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 0.948 ms ae-34-80.car4.LosAngeles1.Level3.net (4.69.144.134) 0.988 ms
5 globalcrossing-level3-10ge.LosAngeles1.Level3.net (4.68.110.66) 0.676 ms 0.783 ms 0.657 ms
6 DANTE.tenGigabitEthernet1-3.ar2.VIE1.gblx.net (64.214.145.146) 169.424 ms 169.400 ms 168.846 ms
7 carnet-gw.rt1.vie.at.geant2.net (62.40.124.10) 177.625 ms * carnet-gw.rt1.vie.at.geant2.net (62.40.124.10) 177.566 ms
8 CN-Srce-03-ES.core.carnet.hr (193.198.238.106) 178.065 ms 178.358 ms 178.034 ms
9 193.198.228.42 (193.198.228.42) 177.860 ms 177.819 ms 177.826 ms
10 CN-Irb.01-ES.core.carnet.hr (193.198.229.6) 178.022 ms 177.546 ms 177.729 ms
11 193.198.162.2 (193.198.162.2) 180.368 ms 180.396 ms 180.281 ms
12 lna6.irb.hr (161.53.129.187) 180.507 ms 180.445 ms 180.389 ms
As you can see ping fails on the last router on the network where my host lies.
The reason why traceroute passed may be because they used UDP probes!
SIXXS or GoGo6 have clients that work without the need to respond to ICMP.
I suggest going that direction.
SIXXS is large in Europe, and as long as you can work with the point system, would be a viable alternative.
Isn't ICMP here used only as a measure to prevent bogus IP registrations?
If so i really am saddened that nobody of the staff understands my problem. A manual tunnel creation/edit shouldn't be a problem for someone from the staff.
It really is a pitty for i have static IP and a 100Mbps direct uplink on said host :(
1) I explained policy in the ticket you opened. If we make an exception for 1 person, it sets precedence for everyone else to ask for the same special treatment. So we avoid that.
2) That script auto-detects your IPv4 endpoint, but still requires it to respond properly to ICMP.
There are other options out there, even 6to4 which gives you a /48 instantly for your use without any broker registrations, and is based on your IPv4 address. You should be asking the provider when they are going to deliver IPv6 to their customers, so they know there is demand. And if they filter ICMP on IPv6 like they are with IPv4, expect a good portion of IPv6 breakage.
I understand and respect that.
But at LEAST consider an alternative way to check host status eg. via UDP probes or TCP ack.
I'm sure there are more users out there whose ISP is overly paranoic and have ICMP disabled.
Gosh i would even pay you if could get that host to run your tunnel... Alternatives aren't that nice.
Quote from: vobelic on October 25, 2010, 08:00:43 PM
Gosh i would even pay you if could get that host to run your tunnel... Alternatives aren't that nice.
We sell a tunnel service, as well, which wouldn't require the same ICMP check as the free service. You can contact sales@he.net, or call 510-580-4190 Mon-Fri 8a-5p Pacific, for more information on locations and commit rates.
Ok thanks, didn't know that!
But if it's that service that is paid 1$/Mbps that's an astronomical amount!
I just want to bypass that ICMP check and i'd pay for that. I'm not an ISP.
RE - Reply #3: What does your traceroute look like if you use the "-I" option?
PS: If your colo provider continues to block ICMP or protocol 41, would you consider moving to one that does permit such? My colo provider allows such. However, they are not in the downtown LA circle of providers that group around Grand and 7th/Wilshire (like your's does), but to the west in the Koreatown district (if you're interested). They also seemed to have the best price when I last relocated in 2006. They can offer space for 1U through a full cabinet.
traceroute -I (forced ICMP probes) ends at 193.198.162.2 with packet filtered message...
Proto 41 isn't blocked!
Well, then it's not your traceroute source but "carnet.hr" which is blocking ICMP on your sample traceroute. That's very bad for any ISP to do. Such can cause all sorts of other problems.
I didn't realize you were tracing to yourself from an external point.
I said from the beginning my ISP is the problem...
It's been blosked for 15 years now it seems... So far i never had any problems running all sorts of services (http, torrent tracker, ftp, ssh, you name it...).
Also I realise HE made this wretched ping policy not that long ago.
A fellow admin managed to establish a tunnel for a host on the same network a year ago or something without any problems.
@broquea I sent immediately as you suggested a mail to sales@he.net yet nobody responds...
I still don't understand why other methods of "pinging" cannot be used if that's a policy. Some of us who seriously work with networks yet their ISP netops being bastards are simply unfairly left in the dark.
Update:
just checked, only INCOMING ICMP echo is blocked!
I can ping from the host, but my host cannot be pinged tho.
Quote from: snarked on October 27, 2010, 10:51:21 AM
Well, then it's not your traceroute source but "carnet.hr" which is blocking ICMP on your sample traceroute.
Just to clarify, it is not "carnet.hr" that is doing the blocking. 161.53.129.187 is owned by "Institut Rudjer Boskovic", which is a member of CARNet.
CARNet is Croatian NREN (National Research & Education Network) which among other things provides Internet connectivity and other services to its members. CARNet not only does not block ICMP to its members, it also has working IPv6 setup since 2004. [1], and have been providing it to any interested member institutions (and is currently working on pushing it to home users).
So ICMP blocking is probably happening at "Institut Rudjer Boskovic" border routers. One would need to contact IRB network admins, and persuade them to either remove ICMP echo request blocking and/or request native IPv6 from CARNet; or the user should get some other way than tunnelbroker.net to get IPv6 connectivity (sixxs.net should work with its AYIYA tunnels, or Teredo might work [2] is SIXXS is too troublesome)
[1] see http://ipv6.carnet.hr/obavijesti/index.html (http://ipv6.carnet.hr/obavijesti/index.html) (Croatian only, sorry)
[2] on Debian Lenny for example, it is as simple as "apt-get install miredo", and violla, you've got IPv6 connectivity.
Heh you did your research :)
Yes I was just simplifying by not mentioning IRB.
Right try you to pursuade them to enable IPv6...
They are even trying to put existing hosts behind NAT and one public IP to make the network more "secure" ...
Suggest, also that they consider carefully the impact if, when they get there, blocking ICMP in the v6 world ans doing that will have significant impact on a fully functional IPv6 Network...
Regards
lukec
If IMB wants to block ICMP echo into their machines, they may do so. However, they shouldn't block anything that merely transits their router without entering their network. You need to talk to them about this.
Quote from: snarked on November 03, 2010, 11:07:44 AM
If IMB wants to block ICMP echo into their machines, they may do so. However, they shouldn't block anything that merely transits their router without entering their network. You need to talk to them about this.
IRB (not IMB) is in fact final "customer" - they are leaf network, and they are blocking icmp echo entering their network.
They are not transit network, and hence they don't block anything that "merely transits their router without entering their network" -- ALL traffic that transits their router are either exiting or entering their network.
CARNet is the one in the role of ISP -- having both traffic entering the CARNet network, as well as lots of traffic which is just passing through their routers from some other source to some other destination - but they do not block anything here...
So yes, IRB is quite allowed to block ICMP echo requests to their network if that's their policy, although it makes problems for its users :(
Then your choice is to move to another provider. It's that simple.
Quote from: snarked on November 04, 2010, 12:11:23 PM
Then your choice is to move to another provider. It's that simple.
Well, it's not my choice, but Vobelics (I just jumped in the discussion with some clarifications). And as it is not (as established above) providers (Internet Service Provider is CARNet) fault, moving to another provider (ISP) is not going to help at all (as it seems you imply). Because, whichever ISP the the IRB chooses, their (IRBs) policy stays the same, and they would
still drop incoming ICMP echo request packets (as it is IRBs policy, and not of their ISP, which is CARNet).
Now the issue is
simple1 as you say, but not in a way you mention -- Vobelic could try:
- to talk to IRB network admins to remove that "ICMP Echo unwanted" policy or to request native IPv6 from CARNet (which provides it free of charge to all it's members). Pestering for native IPv6 is probably the best choice, if somewhat time consuming and of uncertain outcome -- but also of biggest reward.
- he could try to persuade HE.net staff to remove "ICMP Echo request" requirement if using "AUTO" script (which he did try and got refused)
- he could use some other IPv6 tunnel provider which does not require ICMP Echo, like sixxs.net AYIYA tunnels (probably the easiest way out)
- he could leave IRB (probably his place of employment I'd guess) for some other company
- he could give up on IPv6 for the time being
Ok, that last one is unacceptable, and
he might even argue that next-to-last is also somewhat extreme ;)
Footnotes:
1 definition of
simple: "anything that one does not have to do himself/herself". Or, as we'd say in Croatian "lako je tuđim kurcem po koprivama mlatiti"