Print

[burnout]

Hey guys,

at first i was told to complete the certs to get sage level. so i did. i was told an unblock irc option would be available. I spoke with Tae. I'm still unable to irc via my tunnel.

I opened up at ticket #1874508. They keep telling me my tunnel pre dates the block i opened my account May 12, 2008 . But i am blocked. Could i get some assistance.. please and thanks. my tunnel is 2001:470:1f11:62::/64

┌─(burnout@wh0res)──(Sat, 21 Apr 12)──(/home/burnout)────┐
└─(12:56)─>ping6 -c10 ipv6.google.com
PING ipv6.google.com(atl14s07-in-x11.1e100.net) 56 data bytes
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=1 ttl=56 time=53.2 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=2 ttl=56 time=50.9 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=3 ttl=56 time=50.6 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=4 ttl=56 time=50.5 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=5 ttl=56 time=50.9 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=6 ttl=56 time=50.7 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=7 ttl=56 time=50.7 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=8 ttl=56 time=51.3 ms
64 bytes from atl14s07-in-x11.1e100.net: icmp_seq=9 ttl=56 time=50.6 ms

┌─(burnout@wh0res)──(Sat, 21 Apr 12)──(/home/burnout)────┐
└─(01:08)─>telnet -6 irc.efnet.org 6667
Trying 2001:470:0:6667::2...
Trying 2001:590::c603:a003...
Trying 2001:7b8:3:3f:201:2ff:fef6:574e...
Trying 2001:840:0:1000:1::1...
Trying 2001:888:0:2::2...
Trying 2001:16d8:26::...
Trying 2001:19f0::dead:beef:cafe...
Trying 2001:19f0:1004:5123:0:dead:beef:cafe...
Trying 2001:4200:fffe:0:204:23ff:feb4:1d96...
Trying 2001:4db0:10:6::6...
Trying 2607:f2c0::10...
telnet: Unable to connect to remote host: Connection timed out

[kasperd]

I opened up at ticket #1874508. They keep telling me my tunnel pre dates the block i opened my account May 12, 2008 .

What matters is not when the account was opened, but rather when the tunnel was created. I have no idea what reasoning was used to decide this. Since you will be able to create up to five tunnels under your account, you should be able to register another tunnel and compare how the two behaves.

For some obscure reason you cannot have both tunnels point at the same client IP, so you'll have to point the old tunnel at some other IP, if you want to test a new tunnel on the same IP. Notice that if you delete a tunnel you cannot get it back, ever.

I can confirm that something is blocking port 6667. I tested with this command:

Code: [Select]

traceroute -T -n -p 6667 2001:470:1f11:62::2I tried different port numbers and found the range 6660-6670 to be blocked. However remotely I cannot tell exactly where they are being blocked. I get responses from the tunnel server, but not from your tunnel endpoint. From my point of view it could be either of the two doing the blocking (or even a router between the two). A dump of the network traffic from your end might reveal more.

[burnout]

It wouldn't be a big deal to create a new tunnel. but i have 100 vhost setup and some i can't get back... just a pain...and i dont have any ip6tables filtering rules in place...my router is wide open..nothin has been changed..do you any chance work for tunnelbroker/HE. do you think they could unblock it? i tried emailing ipv6@he.net they keep saying im not blocked..it's frustrating..

[burnout]

Starting Nmap 5.00 ( http://nmap.org ) at 2012-04-27 07:06 PDT
Interesting ports on burnout-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:62::2):
Not shown: 992 closed ports
PORT     STATE    SERVICE
80/tcp   open     http
113/tcp  open     auth
6666/tcp filtered irc
6667/tcp filtered irc
6668/tcp filtered irc
6669/tcp filtered irc
7000/tcp filtered afs3-fileserver
9999/tcp filtered abyss

Nmap done: 1 IP address (1 host up) scanned in 2.29 seconds

[burnout]

Kelly Cochran ipv6@he.net
   
Apr 21 (6 days ago)
      
to me
I see nothing on the filters for the tserv that apply to your tunnel, or
generally to IRC.


-- -H U R R I C A N E - E L E C T R I C-
Kelly Cochran   Sr. Network Engineer
510-580-4100    http://www.he.net/   AS6939

[burnout]

Kelly Cochran ipv6@he.net
   
Apr 20 (6 days ago)
      
to me
Your tunnels pre-date the block, so you shouldn't be filtered.

-- -H U R R I C A N E - E L E C T R I C-
Kelly Cochran   Sr. Network Engineer
510-580-4100    http://www.he.net/   AS6939

[broquea]

For some obscure reason you cannot have both tunnels point at the same client IP

The majority of people do not know how to set up source route selection. Since there is RPF upstream of the tunnel, they would find that without knowing how to (let alone that they would HAVE to) set up proper source route selection, they might not get their packets anywhere at all if using the wrong prefixes over the incorrect tunnel interface.

What matters is not when the account was opened, but rather when the tunnel was created. I have no idea what reasoning was used to decide this.

Because there was a sudden spike in abuse of IRC over the tunnels as well as attacks directed at the previously operational HE.NET efnet IRC server. Rather than have dealing with the abuse of the free service eat up valuable engineer time to deal with IRC drama bullshit, the block stemmed the tide of IRC abuse and also saw the hosted efnet server go away (yay!).

[kasperd]

i tried emailing ipv6@he.net they keep saying im not blocked..it's frustrating..

I already pointed out that from here it is not possible to see where the blocking takes place.

You are saying you are not blocking it, and you are saying HE says they are not blocking it either. Which should I believe? Chances are one of the two statements is incorrect. Though there is another possibility, though unlikely, that the blocking happens on a router somewhere in between.

Try running traceroute with TCP packets on different ports from your end to see if it reveals anything.

Further investigation requires access to either end of the tunnel, which I do not have.

I might be able to figure out a few more details if you also had 6to4 addresses, which I could do a traceroute to and compare the results. I might also be able to figure out a bit more if I knew your IPv4 address.

The majority of people do not know how to set up source route selection. Since there is RPF upstream of the tunnel, they would find that without knowing how to (let alone that they would HAVE to) set up proper source route selection, they might not get their packets anywhere at all if using the wrong prefixes over the incorrect tunnel interface.

It might be few people who knows how to get two such tunnels working simultaneously. However, if both were configured on the tunnel servers, and only one of them configured on the client side, then the one configured on the client side would still work.

The current solution looks like it could easily end up with some DoS problems where some user leaves a tunnel configured on a dynamic IP, and when another user gets the same IP, he won't be able to update his tunnel endpoint due to this policy. Then you end up with a case where neither of the tunnels is working. Had two tunnels on the same IP been permitted, at least one of them would have been working.

The problem you mention only applies when the two tunnels are on different servers, if both were on the same tunnel server that problem would not apply.

It is possible to run a tunnel through a NAT in some cases. On some routers it will just work. It would even be possible for two computers behind the same NAT to run tunnels to different tunnel servers. In that case the problem you mention would not apply either, since it would be two independent tunnel endpoints. But due to the policy, it won't work anyway.

Because there was a sudden spike in abuse of IRC over the tunnels

That doesn't explain why existing tunnels were exempted, but new tunnels created by those same users were not.

[broquea]

That doesn't explain why existing tunnels were exempted, but new tunnels created by those same users were not.

Enough of the problem tunnels/accounts had been culled to the point where a large number of only new tunnels/accounts were causing issues. People that behaved got an exemption. Everyone new gets to prove they aren't IRC drama llamas. If someone is unhappy with having to spend time showing they have their IPv6 chops, or any of the other various policies, there are alternatives out there (totally my BOFH opinion and should not reflect on my previous employer's BOFH opinions

As for this guy's problem, it seems really strange that the filter would show up disabled in the broker (and I'll assume someone at HE physically logged into the tserv to verify there) but seemingly still enabled. Disabling it on my new tunnel definitely worked, but I'm not using Chicago.

[kasperd]

As for this guy's problem, it seems really strange that the filter would show up disabled in the broker (and I'll assume someone at HE physically logged into the tserv to verify there) but seemingly still enabled.

I'd try to turn the filter on and then off again. But I wouldn't know how to do that. Might be you cannot do that on your own.

[jtcloe]

As for this guy's problem, it seems really strange that the filter would show up disabled in the broker (and I'll assume someone at HE physically logged into the tserv to verify there) but seemingly still enabled.

I'd try to turn the filter on and then off again. But I wouldn't know how to do that. Might be you cannot do that on your own.

I think once its enabled, the option disappears.

On a tunnel I know I enabled it on (and I do irc over ipv6) I don't even see an option.  On a newly created tunnel, I see text that simply says "IRC Access" and a link that says "unblock".

[jtcloe]

As a test, try this:

Create a new tunnel (on the same tunnel server).

For it to work properly, you'll probably have to point your original tunnel to another IPv4 address (since just deleting it doesn't seem to be an option).

On the new tunnel, choose the option to unblock it.

Test.

Since you seem sure that nothing on your side is blocking it, this could show if something in between or HE may be blocking it (remember, SIT tunnels aren't encrypted by default, and HE doesn't give any options that I'm aware of to encrypt them), there's nothing that says an intermediate ISP or carrier might still be filtering its contents).  It is very possible for a firewall to not only block port 6667 (or all irc ports), but also to block any gre or sit packet that is using port 6667 also.

If it fails, then I would try a tunnel to another tunnel server, if it works, then that does seem to point to a possibility of a problem on HE's side.

Just curious, can you use IRC over ipv4 from your connection?
Are you testing from one of your routed /64 (or /48), or are you testing from the tunnel endpoint?
Don't know the answer to this, but does unblocking IRC unblock it for the tunnel IP's, or just the routed IP's?

[kasperd]

On the new tunnel, choose the option to unblock it.

Test.

While you are at it. Test both before and after you choose the unblock option. And dump the traffic using tcpdump or equivalent. And consider showing us the dump files, cause right now we don't have sufficient information to help you.

Since you seem sure that nothing on your side is blocking it, this could show if something in between or HE may be blocking it (remember, SIT tunnels aren't encrypted by default, and HE doesn't give any options that I'm aware of to encrypt them), there's nothing that says an intermediate ISP or carrier might still be filtering its contents).  It is very possible for a firewall to not only block port 6667 (or all irc ports), but also to block any gre or sit packet that is using port 6667 also.

Loads of things can possibly be wrong. I have even seen routers that sometimes remove the IPv4 header of tunnelled packets for no reason and instead forwards the IPv6 packet from inside of it causing the IPv6 packet to take a completely unexpected path through the network and with a bit of luck still reach the intended destination.

[lattera]

I'm having the same issue. I'm seeing SYN packets go out on my firewall, but no SYN+ACK coming back. A normal ICMPv6 ping and UDP traceroute work fine. But a TCP traceroute to port 6667 doesn't work. I can get to any IPv6 server port 80 and 443 just fine, but not a single IPv6 server port 6667.

Here's some debugging output (2001:470:8142:3::2 is me, 2001:6b0:e:2018::172 is a freenode irc server):

Code: [Select]

# tcpdump -ni gif0 port 6667
tcpdump: WARNING: gif0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
18:43:41.685493 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13840751 ecr 0], length 0
18:43:44.669321 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13843751 ecr 0], length 0
18:43:47.853217 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13846951 ecr 0], length 0
^C
3 packets captured
51 packets received by filter
0 packets dropped by kernel
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 75.148.101.65 --> 72.52.104.74
        inet6 fe80::213:20ff:fe5c:bf69%gif0 prefixlen 64 scopeid 0xf
        inet6 2001:470:1f04:1a28::2 prefixlen 64
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        options=1<ACCEPT_REV_ETHIP_VER>


[lattera]

I'm having the same issue. I'm seeing SYN packets go out on my firewall, but no SYN+ACK coming back. A normal ICMPv6 ping and UDP traceroute work fine. But a TCP traceroute to port 6667 doesn't work. I can get to any IPv6 server port 80 and 443 just fine, but not a single IPv6 server port 6667.

Here's some debugging output (2001:470:8142:3::2 is me, 2001:6b0:e:2018::172 is a freenode irc server):

Code: [Select]

# tcpdump -ni gif0 port 6667
tcpdump: WARNING: gif0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
18:43:41.685493 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13840751 ecr 0], length 0
18:43:44.669321 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13843751 ecr 0], length 0
18:43:47.853217 IP6 2001:470:8142:3::2.49161 > 2001:6b0:e:2018::172.6667: Flags [S], seq 1070001761, win 65535, options [mss 1220,nop,wscale 6,sackOK,TS val 13846951 ecr 0], length 0
^C
3 packets captured
51 packets received by filter
0 packets dropped by kernel
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 75.148.101.65 --> 72.52.104.74
        inet6 fe80::213:20ff:fe5c:bf69%gif0 prefixlen 64 scopeid 0xf
        inet6 2001:470:1f04:1a28::2 prefixlen 64
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        options=1<ACCEPT_REV_ETHIP_VER>


Nevermind. I realized that I have to go through all the certifications to enable IRC ports.