Dealing with sites that block all icmp

[sporkv6]

So as a tunnel user, there can be MTU problems if the site you're trying to reach blocks all v6 ICMP, since that breaks path MTU discovery.

A good long standing example of this is the IRS's payments site: https://www.eftps.gov/

What are my fellow tunnel users doing to work around this?  My solution so far involves toggling IPv6 off, using the site, then turning IPv6 on again.

[cholzhauer]

Semi off-topic, but I have no issues in reaching the site you've listed; it loads instantaneously for me.

[snarked]

Remember that it may not be the end site but some router in the path which is causing problems.  You should post a traceroute to identify which routers are in your path to that site.

[Jim Whitby]

Semi off-topic, but I have no issues in reaching the site you've listed; it loads instantaneously for me.

Not for me. Not using v6 anyway. V4 works.

Ping and traceroute(s)

PING www.eftps.gov(2620:10f:400f:a::12) 56 data bytes

--- www.eftps.gov ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

traceroute to www.eftps.gov (204.194.122.19), 30 hops max, 60 byte packets
1  gateway (192.168.10.1)  0.338 ms  0.415 ms  0.508 ms
2  L100.RCMDVA-VFTTP-14.verizon-gni.net (96.248.18.1)  4.111 ms  4.169 ms  6.043 ms
3  G0-4-4-3.RCMDVA-LCR-22.verizon-gni.net (130.81.218.146)  6.228 ms  6.229 ms  6.258 ms
4  130.81.162.104 (130.81.162.104)  21.258 ms ge-4-2-0-0.ATL01-BB-RTR2.verizon-gni.net (130.81.29.112)  11.047 ms 130.81.162.104 (130.81.162.104)  21.259 ms
5  0.so-3-0-2.XT2.DCA6.ALTER.NET (152.63.42.190)  46.165 ms  46.194 ms *
6  * * *
7  * * *
8  * * *
9  0.xe-11-0-1.XL1.MSP3.ALTER.NET (140.222.228.33)  33.566 ms 0.xe-11-0-1.XL2.MSP3.ALTER.NET (140.222.228.35)  33.828 ms 0.xe-11-0-1.XL1.MSP3.ALTER.NET (140.222.228.33)  33.688 ms
10  GigabitEthernet6-0-0.GW3.MSP3.ALTER.NET (152.63.65.201)  36.361 ms  36.450 ms GigabitEthernet7-0-0.GW3.MSP3.ALTER.NET (152.63.65.205)  36.526 ms
11  firstdata-gw.customer.alter.net (152.179.59.134)  44.915 ms  44.945 ms  45.065 ms
12  10.178.237.34 (10.178.237.34)  44.716 ms  44.677 ms  44.809 ms
13  10.178.237.42 (10.178.237.42)  47.112 ms  44.871 ms  47.132 ms
...
30  * * *

traceroute to www.eftps.gov (2620:10f:400f:a::12) from 2001:470:8:67:6e62:6dff:feec:930f, 30 hops max, 24 byte packets
1  2001:470:8:67:26a4:3cff:fe05:c8d (2001:470:8:67:26a4:3cff:fe05:c8d)  0.61 ms  0.511 ms  0.453 ms
2  jameswhitby-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:67::1)  31.746 ms  18.93 ms  27.345 ms
3  ge4-12.core1.ash1.he.net (2001:470:0:90::1)  42.824 ms  42.75 ms  37.535 ms
4  100ge7-1.core1.nyc4.he.net (2001:470:0:299::2)  57.277 ms  64.302 ms  27.576 ms
5  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2)  50.008 ms  74.08 ms  45.04 ms
6  n54ny22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:81:110)  97.656 ms  124.064 ms  147.579 ms
7  wswdc22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:3:38)  112.11 ms  124.142 ms  105.338 ms
8  attga21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:1:173)  89.726 ms  100.812 ms  107.189 ms
9  dlstx22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:28:174)  95.145 ms  86.502 ms  104.978 ms
10  dlstx21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:1:209)  122.703 ms  118.149 ms  109.629 ms
11  phmaz21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:28:182)  92.579 ms  125.59 ms  82.484 ms
12  phmaz402me3.ipv6.att.net (2001:1890:ff:ffff:12:122:125:136)  115.124 ms  86.689 ms  107.462 ms
13  2001:1890:c00:9a02::11aa:dd4f (2001:1890:c00:9a02::11aa:dd4f)  122.182 ms  121.724 ms  87.366 ms
14  2620:10f:400f:1::2 (2620:10f:400f:1::2)  97.081 ms  102.48 ms  129.858 ms
...
30  * * *

Verified from my desktop (using v6 ) and my blackberry ( using v4 ) to access the web site.

While not conclusive, at least is reproducible. My "best guess" is the web server won't handle v6.

[snarked]

The IPv6 traceroute tells us that eftps.gov is:
1)  Not passing ICMP6 out of their gateway router at hop 14 (but responding on its external interface), or
2)  The destination machine itself isn't generating ICMP6 messages.
Either way, PMTU is indeed broken.

The IPv4 traceroute indicates the same - ICMP is being blocked inside their network.  The ping loss implies that they're dropping all ICMP packets (in the outbound direction certainly).

[Jim Whitby]

I agree they are blocking.

My point was that I couldn't get there using v6, but I could using v4.

My conclusion is they probably don't have v6 available from the web server.

[amskiurp]

Their site is available over V6 if you manually lower the MTU on your client device so that there are no icmp6 'packet too big' messages to get lost, e.g.

$ sudo ip link set dev eth0 mtu 1280
or
$ sudo ifconfig eth0 mtu 1280

[snarked]

Note this article:

http://www.federaltimes.com/article/20140214/BLG01/302140005/The-411-IPv6

The U.S. Government is still working on IPv6 compliance.  Although not said specifically, many agencies are way behind schedule.