Address HE is pinging me from

[tedllewellyn]

  I cannot get a tunnel configured because of the ICMP issue.  I can see the address HE is pinging me from; is that the only address I need to allow, or is there a range?
  And why isn't this info in the FAQ somewhere?  I've also looked through the posts, and maybe I missed it, but I cannot find this info.  Openning up ICMP to the Great Cesspool is not a great recommendation.

[Night]

For windows VIsta/netsh firewall set icmpsetting 8 enable this will enable ping requests :)

[kriteknetworks]

 Openning up ICMP to the Great Cesspool is not a great recommendation.

According to what?

[kcochran]

There's just the one IP it'll ping from.

As to ICMP, be very careful with how much ICMP you choose to block.  A blanket ICMP block is going to be asking for trouble with certain DNS queries today (EDNS0), and once DNSSEC is deployed, you will have all sorts of resolution issues.

[tedllewellyn]

>>>>  According to what?

  If they can't find me they can't portscan me, and while it may only be wasting bandwidth, it's my bandwidth.

>>>>  As to ICMP, be very careful with how much ICMP you choose to block.  A blanket ICMP block is going to be asking for trouble with certain DNS queries today (EDNS0), and once DNSSEC is deployed, you will have all sorts of resolution issues.

I'm moving to a new firewall; either this hasn't been an issue (I thought my old firewall was blocking ICMP completely) or things haven't been working just the way I thought it was.  I'll have to monitor things; thanks for the info and the tip.

[snarked]

A blanket ICMP6 block will also cause all kinds of problems if one has multiple machines at the tunnel endpoint.  IPv6 uses ICMP6 messages for neighbor discovery, as opposed to IPv4's ARP.  Stateless autoconfiguration also needs ICMP6.

As far as the pings from HE are concerned, they will come ONLY from HE's tunnel endpoint address ending in "::1".  Although a "/64" is declared for this, a "/126" works just as well.

[jimb]

There's just the one IP it'll ping from.

As to ICMP, be very careful with how much ICMP you choose to block.  A blanket ICMP block is going to be asking for trouble with certain DNS queries today (EDNS0), and once DNSSEC is deployed, you will have all sorts of resolution issues.

Yeah surprised he hasn't been bitten by the disabled PMTUD process because of his block all ICMP policy.

Also, it'll be interesting when DNSSEC starts being deployed on the major TLDs and roots (I believe major TLDs are imminent).  There's a lot of firewalls which automatically block UDP packets > 512 bytes.  Ouch.  And most DNS servers/firewalls also block DNS queries via TCP, or simply don't implement it (cable modems and consumer routers and such).  It'll be interesting to see what happens when all this hits.   :-\

[brad]

Yeah surprised he hasn't been bitten by the disabled PMTUD process because of his block all ICMP policy.

Also, it'll be interesting when DNSSEC starts being deployed on the major TLDs and roots (I believe major TLDs are imminent).  There's a lot of firewalls which automatically block UDP packets > 512 bytes.  Ouch.  And most DNS servers/firewalls also block DNS queries via TCP, or simply don't implement it (cable modems and consumer routers and such).  It'll be interesting to see what happens when all this hits.   :-\

Sit back and laugh at all of the broken networks. The "I block all ICMP" people especially make me laugh at their complete and utter lack of any clue.

[tedllewellyn]

A blanket ICMP6 block will also cause all kinds of problems if one has multiple machines at the tunnel endpoint.  IPv6 uses ICMP6 messages for neighbor discovery, as opposed to IPv4's ARP.  Stateless autoconfiguration also needs ICMP6.

As far as the pings from HE are concerned, they will come ONLY from HE's tunnel endpoint address ending in "::1".  Although a "/64" is declared for this, a "/126" works just as well.

I only block ICMP on the Internet-facing link.

As to the DNS issues, will opening up type 8 be enough?

[jimb]

A blanket ICMP6 block will also cause all kinds of problems if one has multiple machines at the tunnel endpoint.  IPv6 uses ICMP6 messages for neighbor discovery, as opposed to IPv4's ARP.  Stateless autoconfiguration also needs ICMP6.

As far as the pings from HE are concerned, they will come ONLY from HE's tunnel endpoint address ending in "::1".  Although a "/64" is declared for this, a "/126" works just as well.

I only block ICMP on the Internet-facing link.

As to the DNS issues, will opening up type 8 be enough?

Yeah that's a problem.  You're blocking ICMP and ICMPv6 "fragmentation needed/packet too big" messages from coming back to the hosts, which breaks Path MTU Discovery (PMTUD). 

[tedllewellyn]

Yeah that's a problem.  You're blocking ICMP and ICMPv6 "fragmentation needed/packet too big" messages from coming back to the hosts, which breaks Path MTU Discovery (PMTUD). 

Yeah, I just started looking at the ICMPv6 types (did I mention that this is not a production link?)  Something seems to be broken in my router so I don't think my stations could get MTU disco packets anyway.  That's OK, I'd rather troubleshoot a router than read some more RFCs right now anyway. ;-)  But thanks for the heads up.

[snarked]

As to the DNS issues, will opening up type 8 be enough?

Such has nothing to do with DNS.

You must open ICMP6 echo request (and response on the output side) to HE's tunnel server IPv6 address so that it can determine that the tunnel is still working during periods of inactivity.  Note that for ICMP6, echo is NOT type 8 as it is for ICMP under IPv4.

Neighbor or router solicitation requests don't need to be opened for a 6in4 connection, but do need to be open for any native IPv6 connection you may have.

All IPv6 connections regardless of type should remain open to receive error notifications (host unreachable, etc.) and path MTU discovery packets; the latter especially since IPv6 may not fragment packets mid-transit.

http://www.iana.org/assignments/icmpv6-parameters

[tedllewellyn]

Per RFC 4890 I've allowed icmpv6 types 1-4, 128 and 129; unreachable, packet too big, time exceeded, parameter problem, and ping.  No filtering on the inside interface.  I think that covers what people have said here.

As to the DNS issues, will opening up type 8 be enough?

Such has nothing to do with DNS.

I'll be darned if I can find anything about ICMP and DNSSEC; there is a "DNS ping" in the references on EDNS0 but it didn't look like it was ICMP.  DNS gives me a headache.

[kcochran]

ICMP 4/3 packet-too-big is the one you need to really be concerned with for EDNS0/DNSSEC.  With the extra stuff included in those more advanced DNS sequences, you will start seeing those whenever the MTU gets blown out.

[tedllewellyn]

ICMP 4/3 packet-too-big is the one you need to really be concerned with for EDNS0/DNSSEC.  With the extra stuff included in those more advanced DNS sequences, you will start seeing those whenever the MTU gets blown out.

Good info, thanks.