ICMP Blocking

[kolodzij]

To set up a Tunnel with HE your router must be pingable.

After the Tunnel is set up I have disabled ICMP on my router and the Tunnel continues to work.

What is the impact of disabling ICMP on an active Tunnel?

[vobelic]

No impact whatsoever except HE.net's policy regretfully demands ping verification on setting IPv4 endpoint.

[kolodzij]

That's good to know!

What about ICMP IPv6?

I have a IPv4 router that passes ICMP IPv6 messages since it looks like a IPv4 packet. I have changed the firewall on the client computer to respond to ICMP v6 messages. It seems that blocking ICMP v6 messages at the client computer level would not be a good thing.

[snarked]

Does HE block ICMPv6 on its routers?  I ask because of the results of a traceroute to another tunnel user from me only registers our endpoints - not any router along the path.  As the path is 7 hops total, we'd expect hops 1 and 6 to be our respective tunnel servers, and 2-5 to be the HE routers in the path.  However, none respond. (Glorb uses a BGP tunnel server.)  Example:

traceroute to news.glorb.com (2607:fc18:dead:beef::27) from news.snarked.org (2001:470:d:4::1:4), 30 hops max, 16 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  news.glorb.com (2607:fc18:dead:beef::27)  81.073 ms  80.908 ms  125.633 ms

Could HE please turn on ICMPv6 -- at least when the source and/or destination address is within the 2001:470::/32 network?  Thanks.

[kolodzij]

Works for me!


C:\Windows\system32>tracert news.glorb.com

Tracing route to news.glorb.com [2607:fc18:dead:beef::27]
over a maximum of 30 hops:

  1     1 ms    <1 ms     1 ms  xxxx
  2    29 ms    24 ms    23 ms  xxxx
  3    22 ms    24 ms    24 ms  gige-g4-6.core1.lax1.he.net [2001:470:0:9d::1]
  4   100 ms    87 ms    94 ms  10gigabitethernet4-3.core1.nyc4.he.net [2001:470
:0:10e::2]
  5    96 ms    98 ms    98 ms  10gigabitethernet2-3.core1.ash1.he.net [2001:470
:0:36::1]
  6    90 ms   101 ms    99 ms  f0-0.ash.ipv6.he.net [2001:470:0:40::1]
  7   104 ms   102 ms   104 ms  news.glorb.com [2607:fc18:dead:beef::27]

Trace complete.

[cholzhauer]

Yeah, same here

Code Select Expand


[carl@mars ~]$ traceroute6 news.glorb.com
traceroute6 to news.glorb.com (2607:fc18:dead:beef::27) from 2001:470:c27d:e000:20c:29ff:fe8a:1618, 64 hops max, 12 byte packets
1  2001:470:c27d:d000:2e0:81ff:fe79:f4c4  0.986 ms  0.725 ms  0.768 ms
2  servicespring-1.tunnel.tserv9.chi1.ipv6.he.net  441.050 ms  441.558 ms  445.014 ms
3  gige-g3-4.core1.chi1.he.net  443.450 ms  402.819 ms  45.302 ms
4  10gigabitethernet2-4.core1.nyc4.he.net  67.336 ms  67.401 ms  71.981 ms
5  10gigabitethernet2-3.core1.ash1.he.net  81.696 ms  83.197 ms  73.532 ms
6  f0-0.ash.ipv6.he.net  73.845 ms  73.690 ms  74.042 ms
7  news.glorb.com  86.347 ms  86.117 ms  112.867 ms


[snarked]

Reply #4 - Thanks.  I also use the LA tunnel server, yet it doesn't work for me.  I inserted some logging statements into my firewall and the ONLY packets I got back were the three at hop 7 (which traceroute reported).  For some reason, these others did NOT have ICMPv6 packets coming back at all (of which I expected a type 1 or 3), even when I accepted all types 1-4 from any source.  The traceroute out packets were UDP and my rule for sending out did increment 21 times for each completed route (as expected).  Therefore, I had to assume that something was blocking the packets coming in.

Using Linux (2.6.36.1), and I have the rp_filter OFF.  I also log any packet that I drop (both in and out).

Obviously, for me to receive the response from the destination, my ICMP6 firewall settings seem correct.  What else should I look for?

[lukec]

Works from UK

Code Select Expand

traceroute6 news.glorb.com.
traceroute6 to news.glorb.com (2607:fc18:dead:beef::27) from 2001:470:9313:0:224:81ff:fe07:99, 64 hops max, 12 byte packets
1  lukec-gw  0.715 ms  0.690 ms  0.693 ms
2  lukec-1.tunnel.tserv5.lon1.ipv6.he.net  55.295 ms  54.004 ms  53.638 ms
3  gige-g4-6.core1.lon1.he.net  49.581 ms  60.349 ms  49.789 ms
4  10gigabitethernet2-3.core1.nyc4.he.net  116.821 ms  118.542 ms  116.729 ms
5  10gigabitethernet2-3.core1.ash1.he.net  124.902 ms  132.054 ms  123.385 ms
6  f0-0.ash.ipv6.he.net  123.708 ms  124.128 ms  123.732 ms
7  news.glorb.com  136.455 ms  136.538 ms  141.750 ms


permitting icmpv6 any any

Regards
lukec

[kolodzij]

Reply #4 - Thanks.  I also use the LA tunnel server, yet it doesn't work for me.  I inserted some logging statements into my firewall and the ONLY packets I got back were the three at hop 7 (which traceroute reported).  For some reason, these others did NOT have ICMPv6 packets coming back at all (of which I expected a type 1 or 3), even when I accepted all types 1-4 from any source.  The traceroute out packets were UDP and my rule for sending out did increment 21 times for each completed route (as expected).  Therefore, I had to assume that something was blocking the packets coming in.

Using Linux (2.6.36.1), and I have the rp_filter OFF.  I also log any packet that I drop (both in and out).

Obviously, for me to receive the response from the destination, my ICMP6 firewall settings seem correct.  What else should I look for?

On linux you can force traceroute to use ICMP over UDP with traceroute -P ICMP ipnr, note that the linux ICMP trace also uses type 8.

[snarked]

Traceroute using ICMP does not exist for IPv6.  That is an IPV4 property only.

There is no type 8 for ICMPv6.

21 Packets do go OUT:

86  5504 ACCEPT     udp      any    any     anywhere             anywhere            udp dpts:33434:33499

traceroute to news.glorb.com (2607:fc18:dead:beef::27) from news.snarked.org (2001:470:d:4::1:4), 30 hops max, 16 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  news.glorb.com (2607:fc18:dead:beef::27)  81.25 ms  81.218 ms  81.464 ms

 107  6848 ACCEPT     udp      any    any     anywhere             anywhere            udp dpts:33434:33499

107 - 86 = 21.  21 / 3 = 7.  The UDP traceroute packets were permitted by my firewall and therefore did go out.

However - the input chain:

3043 1655K ACCEPT    all      any    any     anywhere   ...

Traceroute...

3046 1656K ACCEPT    all      any    any     anywhere    ...

Only three packets come back.  This is consistent with the result from hop 7.  It also proves that I'm not seeing the other packets at all.  The 3 packets that I do get back are icmp6 destination-unreachable (bad port):

IPv6 PING TEST IN=sit1 OUT= MAC=... TUNNEL=66.220.18.42->x.x.x.x SRC=2607:fc18:dead:beef:0000:0000:0000:0027 DST=2001:0470:000d:0004:0000:0000:0001:0004 LEN=112 TC=0 HOPLIMIT=58 FLOWLBL=0 PROTO=ICMPv6 TYPE=1 CODE=4 [SRC=2001:0470:000d:0004:0000:0000:0001:0004 DST=2607:fc18:dead:beef:0000:0000:0000:0027 LEN=64 TC=0 HOPLIMIT=2 FLOWLBL=0 PROTO=UDP SPT=5183 DPT=33434 LEN=24 ]

Therefore, the 18 packets that are starred are really not being returned to my host.  Therefore, despite others seeing a return to their packets, I must ask my question again....  I should be getting 18 ICMP6 time-exceeded packets, but I'm not seeing those at all.

[kolodzij]

FWIW, I am using MS Win 7.

On modern Unix-like operating systems, the traceroute utility by default uses User Datagram Protocol (UDP) datagrams with destination port numbers from 33434 to 33534. The traceroute utility usually has an option to specify use of ICMP echo request type 128 instead, as used by the Windows tracert utility. If a network has a firewall and operates both Unix-like and MS Windows systems, both protocols must be enabled inbound through the firewall.

[snarked]

As I have stated, there is no ICMP option for traceroute6 under Linux.  That option exists only for the  IPv4 program.  Regardless, that does not explain why I'm not getting the "time exceeded" messages from the first six hops, which should occur either way (UDP or ICMP-ping outbound).

[kolodzij]

This sounds like your problem and a solution.

http://osdir.com/ml/linux.debian.devel.ipv6/2002-05/msg00012.html

Here is the possible fix:

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]
Linux tunnels inherit TTL by default

    * To: debian-ipv6@lists.debian.org
    * Subject: Linux tunnels inherit TTL by default
    * From: csmall@eye-net.com.au (Craig Small)
    * Date: Tue, 23 Oct 2001 12:27:09 +1000
    * Message-id: <20011023122709.B15803@eye-net.com.au>
    * Mail-followup-to: debian-ipv6@lists.debian.org

Hello,
  I got this wierd problem where traceroutes would not work once I sent
packets through my IPv6 tunnel.  I would get back ICMP ttl expired
messages, but they were IPv4 icmp messages.

It seems that the tunnel packets were inheriting the TTL of the IPv6
payload.  This meant the IPv4 routers carrying my tunnel packets dropped
them on the floor.

Finally I tracked it down to a tunnel paramter, it seems that the
inherit ttl is something that is on by default.  I think this is
incorrect though.

rowlf:/home/csmall# ip tunnel show trumpet
trumpet: ipv6/ip  remote 203.5.119.58  local 203.41.228.22  ttl inherit
rowlf:/home/csmall# ip tunnel change trumpet ttl 64
rowlf:/home/csmall# ip tunnel show trumpet
trumpet: ipv6/ip  remote 203.5.119.58  local 203.41.228.22  ttl 64

Traceroute now works as it should.  Should I be recommending people set
this ttl?

- Craig


Here is the "before" trace, nortice the TTL

08:39:19.759053 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 1) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) [ttl 1] (id 0)
08:39:24.757631 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 1) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) [ttl 1] (id 0)
08:39:24.917585 139.130.45.1 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 255, id 30635)
08:39:29.756208 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 1) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) [ttl 1] (id 0)
08:39:29.906165 139.130.45.1 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 255, id 30667)
08:39:34.754785 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 2) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) (ttl 2, id 0)
08:39:34.914740 203.50.15.195 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 254, id 18731)
08:39:39.763359 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 2) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) (ttl 2, id 0)
08:39:39.923314 203.50.15.195 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 254, id 18741)
08:39:44.761937 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 2) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) (ttl 2, id 0)
08:39:44.921891 203.50.15.195 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 254, id 18759)
08:39:49.760514 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 3) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) (ttl 3, id 0)
08:39:49.940463 203.50.12.181 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 253, id 56462)
08:39:54.769089 203.41.228.22 > 203.5.119.58: v6-in-v4
                 3ffe:8001:6:10:201:3ff:fe40:a029 > 3ffe:501:4819:2000:280:adff:fe71:81fc  (v0, priority 8, flow 1196328, len 32, hop 3) 3ffe:8001:6:10:201:3ff:fe40:a029.40496 > 3ffe:501:4819:2000:280:adff:fe71:81fc.33434: udp 24 (DF) (ttl 3, id 0)
08:39:54.989026 203.50.12.181 > 203.41.228.22: icmp: time exceeded in-transit [tos 0xc0] (ttl 253, id 56508)
--
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/        <csmall@eye-net.com.au>
MIEEE <csmall@ieee.org>                 Debian developer <csmall@debian.org>


Reply to:

    * debian-ipv6@lists.debian.org
    * Craig Small (on-list)
    * Craig Small (off-list)

    * Prev by Date: Re: pkgs
    * Next by Date: Route problem [LONG]
    * Previous by thread: Get guaranteed traffic to your website today @ incredible prices
    * Next by thread: Route problem [LONG]
    * Index(es):
          o Date
          o Thread

[snarked]

Thank you for finding this.  "TTL Inherit" was indeed the problem.  However, the interesting thing is that it appeared ONLY on my HE tunnel and NOT on my 6to4 tunnel (sit0).

>ip tunnel show
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc
sit1: ipv6/ip  remote 66.220.18.42  local x.x.x.x ttl inherit (my HE tunnel)

As I don't use the debian distribution, I would not have looked on their lists or forums.

However, also interesting is that sit0 defaults to a TTL and has the "nopmtudisc" flag enabled.  These two features are incompatible per "ip"'s manual page.