Ok to let all ICMP traffic through firewall?

What the hell are you talking about, or are you being deliberately obtuse? At some time in the future your company may be in a position where data isn't getting through because of a problem in the intervening path, and the the only way an intermediate device can advise you of the reason is by sending ICMP. Which it sounds like you are filtering out.

Mike

No I didn't, we are just talking about two different methods/needs. My needs require that I provide ICMP responses to the world, and in many cases, neither do most that don't provide public services to the world.

If I had a website I would allow "some" forms of ICMP, but you have to ask yourself why you need to provide communications with people you don't want to communicate with.

If that happens, then "at some time in the future" I will adjust the settings. Until a time when it causes a problem we will leave it unavailable.

In article , Mike Civil wrote: :What the hell are you talking about, or are you being deliberately :obtuse? At some time in the future your company may be in a position :where data isn't getting through because of a problem in the intervening :path, and the the only way an intermediate device can advise you of the :reason is by sending ICMP. Which it sounds like you are filtering out.

If the routing infrastructure he is using enters a routing loop, then

a) there is a substantial chance that the ICMP TTL Exceeded won't get back either; and

b) the NOC for the intrastructure is likely going to find out and act on it faster than he would get a page saying "TTL exceeded" and log in and track down the cause and call the NOC.

If the routing infrastructure does not enter a routing loop, but loses the route, then if he has multiple routes then his routing protocol is going to notice the problem and adjust automatically. There are no routing protocols that I can think of that use icmp to determine whether the routing is working or not.

If the route is lost and he has only a single route, then his monitoring software is going to stop hearing back from the other side, and he will get an appropriate notification and will investigate. That investigation might be helped by the availability of icmp; if so then he can turn reception of icmp on at the time.

If you get no answer, all you know is that -something- along the way either did not generate a response or else that something dropped the response. That "something" is not necessarily the end host.

Our firewall drops icmp echo packets to hosts we don't permit echo to. No response is generated at all. That doesn't tell you whether the host exists or not.

if this really works with latency times, then it's no danger for Tor or AN.ON.

Yours, VB.

Yes, of course. And if I send IP packets over a line, where the other hosts only understand IPX, then I will not get a response either. But what should that explain?

We're talking about the TCP/IP protocol family here, aren't we?

And we're not talking about ICMP echo.

Yours, VB.

Art wrote: [...]

Where does it say that the NSA's patent requires ICMP pings?

Without reading the patent, I'd put money on it using all forms of IP traffic rather than just a specific protocol.

My (hazy) memory seems to recall that the POD only affected the stack on certain Win95 clients. E.

A problem with an upstream route or router is in what is called an SEP field: Someone Else's Problem. There is no way you could do anything yourself to fix it as you don't have access. I have been in exactly the situation you describe (random routing dropouts in a VPN path) and the SEP rule applied. The solution was to contact the ISP that owned the box (the E in SEP) and have them fix it.

The cause in this instance was a box on the border of 2 network types (ADSL and VDSL) stopping routing properly between the 2 networks whenever a techo from the VDSL backbone provider logged in to it.

The diagnosis for this obviously required echo replies back in. Also having traceroute data for the path most traffic would take under normal circumstances recorded to enable future diags. I basically rang the ISP involved and said traffic from A to B is failing between boxes X and Y.

My understanding of Leythos' statements is that ICMP is allowed between those he trusts, outbound is allowed, but unsolicited inbound from every other sod on the planet is dropped. Which seems normal to me.

Interestingly enough, after the Welchia type worms that came out most, if not all, ISP's blocked pings going into and out of their network ranges in this country. Tracert is also badly affected, which makes diagnostics a nightmare at times. E.

This is wrong:

Yup. I did say hazy for a reason... Cheers for the heads-up. E.

Don't use it. It does no good.

Since you recommend strongly the XP built in fire wall, what connections do you mean? In this XP fire wall there are no numbers, but only text explanations.

Klaas

I'm recommending the Windows-Firewall before using some "Personal Firewall" with extra security flaws. Unfortunately, the Windows-Firewalls has some flaws, too. They're not security related, though. For example, the Windows- Firewall does DROP instead of REJECT, if you send SYN to a closed port.

To know which type of ICMP message means what, just read RFC 792, please. You can find it here:

Hm... just the same nonsense without any reasons or arguments.

"Leythos", did you change your nick name?

VB.

Most people that tlak about blocking a specific type of ICMP message are very technical and probably don't use windows, i'm sure they have a unix based system and their firewall is a standard unix one which has advanced packet filtering (iptables?). They'd be using unix. And/Or perhaps a quality HW firewall like Checkpoint or Watchguard (I don't know if thsoe HW firewalls let you do advacned filtering but they probably do). A windows firewall with advanced filtering would certainly let you. But I wonder how many have advanced filtering

Amazingly, it seems that The Windows Firewall *does* actually let you coose specific types of ICMP message to allow or block. I am not an expert, infact the next chapter of the 2 books that I reading are titled ICMP. And I haven't started that chapter in those books yet

Anyhow, let's see RFC 792 which describes ICMP,

ICMP has a code field and a type field. Both have values. VB refered to the Type field.

--- ignore these codes, he only referred to type Code 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed.

I would never change my Nick, and I stand behind blocking ALL ICMP types to from sites that don't require it as part of our business.