traceroute

traceroute

[Prash]

Hi Peeps,

A weird problem. See my rules below on the INPUT chain. I have NOT
allowed 33434:33523 for traceroute on UDP but some people can and some
people can't do a traceroute. Any ideas? Traceroute should be accepted
only if I open 33434:33523 .. isn't it? Then why is it allowing some in.

I'm allowing everything on FORWARD and OUTPUT chain.

Also for DNS and Web, do I need to open any specific >1024 ports. That
should be covered by ESTABLISHED, RELATED .. isn't it?


#Accept ESTABLISHED
-A RH-Lokkit-0-50-INPUT -p tcp -m state --state ESTABLISHED,RELATED -j
ACCEPT
-A RH-Lokkit-0-50-INPUT -p udp -m state --state ESTABLISHED,RELATED
--dport 1024: -j ACCEPT

#Allow traceroute
###-A RH-Lokkit-0-50-INPUT -p udp --dport 33434:33523 -j ACCEPT

#Accept ICMP Ping
-A RH-Lokkit-0-50-INPUT -p icmp --icmp-type echo-request -m limit
--limit 5/second -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p icmp -j LOG

# Drop Everything else
-A RH-Lokkit-0-50-INPUT -j DROP

Re: traceroute

[Cedric Blancher]

Le dim 13/06/2004 à 15:55, Prash a écrit :
> A weird problem. See my rules below on the INPUT chain. I have NOT
> allowed 33434:33523 for traceroute on UDP but some people can and some
> people can't do a traceroute. Any ideas? Traceroute should be accepted
> only if I open 33434:33523 .. isn't it? Then why is it allowing some in.

There's a lot of way of performing a "traceroute". Speaking of classical
traceroute tools, you have two approaches :

	. the Unix traceroute that uses an UDP packet to a high port
	. the Windows traceroute that uses an ICMP echo

So, in your approach, you only block the Unix approach, not the Windows
one.

Moreover, one can perform traceroute using any type of message that will
trigger an answer on target, such as TCP SYN on open port. The only way
to detect a traceroute is to examine TTL and decide you block packets
with TTL under a given value, say your internal network depth. But I do
not think this to be a very good idea, has it may break legitimate
communications.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

traceroute

[Peter Marshall]

Hi.  I was wondering what I would need for rules to have traceroute work
through my firewall.  (I have a box behind the firewall trying to get out
using traceroute).

I have an allow established connections on my forwared chain, and I am
allowing anything from the source IP of the box in question to leave ... It
appears that the problem is on the packets comming back in .. but I am not
sure what I have to do to fix it ....

Thanks

Peter

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute work
> through my firewall.  (I have a box behind the firewall trying to get out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave ... It
> appears that the problem is on the packets comming back in .. but I am not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the sense of 
achievement you get from getting them to work at all. In other words - and 
this is the rock solid principle on which the whole of the Corporation's 
Galaxy-wide success is founded - their fundamental design flaws are 
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

RE: traceroute

[Piszcz, Justin Michael]

You need to set up the ESTABLISHED,RELATED rule.

Here is an example of a test firewall:
http://installkernel.tripod.com/ipls



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Wednesday, June 30, 2004 9:06 AM
To: netfilter
Subject: traceroute

Hi.  I was wondering what I would need for rules to have traceroute work
through my firewall.  (I have a box behind the firewall trying to get
out
using traceroute).

I have an allow established connections on my forwared chain, and I am
allowing anything from the source IP of the box in question to leave ...
It
appears that the problem is on the packets comming back in .. but I am
not
sure what I have to do to fix it ....

Thanks

Peter

RE: traceroute

[Piszcz, Justin Michael]

Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of 
achievement you get from getting them to work at all. In other words -
and 
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are 
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Ruprecht Helms]

Peter Marshall wrote:

>Hi.  I was wondering what I would need for rules to have traceroute work
>through my firewall.  (I have a box behind the firewall trying to get out
>using traceroute).
>
>Have a look to the icmp-types. You can begin by enabling icmp generally.
>  
>
Regards,
Ruprecht

Re: traceroute

[Peter Marshall]

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has <gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38 byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

RE: traceroute

[Piszcz, Justin Michael]

Is there a reason why you are doing stuff with the FORWARD chain?
Have you tried enabling ACCEPT for the FORWARD chain and seeing if it
works?

Generally, with the FORWARD chain, over all other chains you need to be
careful on how you use it. If used improperly, you could screw a lot of
things up on the network.

I would recommend trying it without any forward options.
Ie: iptables -P FORWARD ACCEPT

You need the ESTABLISHED,RELATED option for the INPUT chain.

# STEP 9 - ALLOW IN WHAT WE SEND OUT
####################################### $IPTABLES -A INPUT -m state
--state ESTABLISHED,RELATED -j ACCEPT

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com] 
Sent: Wednesday, June 30, 2004 10:25 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a
traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has
<gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is
at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38
byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am
trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

RE: traceroute

[Piszcz, Justin Michael]

The default UNIX traceroute uses UDP sockets, port > 30,000+.

ICMP would not help him here, unless he is using (mtr) which uses ICMP.

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Ruprecht Helms
Sent: Wednesday, June 30, 2004 10:04 AM
To: Peter Marshall
Cc: netfilter
Subject: Re: traceroute

Peter Marshall wrote:

>Hi.  I was wondering what I would need for rules to have traceroute
work
>through my firewall.  (I have a box behind the firewall trying to get
out
>using traceroute).
>
>Have a look to the icmp-types. You can begin by enabling icmp
generally.
>  
>
Regards,
Ruprecht

Re: traceroute

[Peter Marshall]

Why would I use the INPUT chain .. I am doing a trace route from an internal
box to an internet box ... on the other side of my firewall ... I am pretty
sure that is a forwared rule ... is it not ?

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 11:34 AM
Subject: RE: traceroute


Is there a reason why you are doing stuff with the FORWARD chain?
Have you tried enabling ACCEPT for the FORWARD chain and seeing if it
works?

Generally, with the FORWARD chain, over all other chains you need to be
careful on how you use it. If used improperly, you could screw a lot of
things up on the network.

I would recommend trying it without any forward options.
Ie: iptables -P FORWARD ACCEPT

You need the ESTABLISHED,RELATED option for the INPUT chain.

# STEP 9 - ALLOW IN WHAT WE SEND OUT
####################################### $IPTABLES -A INPUT -m state
--state ESTABLISHED,RELATED -j ACCEPT

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com]
Sent: Wednesday, June 30, 2004 10:25 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a
traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has
<gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is
at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38
byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am
trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

RE: traceroute

[Piszcz, Justin Michael]

Hrm, perhaps..

Maybe showing a diagram of your network might help?

It sounds like you have two firewalls then?
If so, I still believe you would be using INPUT.., have you tried it,
default POLICY for FORWARD to ACCEPT and enable the INPUT rule?

Traceroute:

[yourbox (iptables firewall)] ---------> [nat+firewall] -------> host?

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com] 
Sent: Wednesday, June 30, 2004 10:50 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

Why would I use the INPUT chain .. I am doing a trace route from an
internal
box to an internet box ... on the other side of my firewall ... I am
pretty
sure that is a forwared rule ... is it not ?

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 11:34 AM
Subject: RE: traceroute


Is there a reason why you are doing stuff with the FORWARD chain?
Have you tried enabling ACCEPT for the FORWARD chain and seeing if it
works?

Generally, with the FORWARD chain, over all other chains you need to be
careful on how you use it. If used improperly, you could screw a lot of
things up on the network.

I would recommend trying it without any forward options.
Ie: iptables -P FORWARD ACCEPT

You need the ESTABLISHED,RELATED option for the INPUT chain.

# STEP 9 - ALLOW IN WHAT WE SEND OUT
####################################### $IPTABLES -A INPUT -m state
--state ESTABLISHED,RELATED -j ACCEPT

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com]
Sent: Wednesday, June 30, 2004 10:25 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a
traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has
<gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is
at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38
byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am
trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:

> -----Original Message-----
> From: Peter Marshall [mailto:peter.marshall@caris.com]
> Sent: Wednesday, June 30, 2004 10:25 AM
> To: Piszcz, Justin Michael; netfilter
> Subject: Re: traceroute
>
> I don't get anything (except the name lookup) from traceroute.
>
> Below are the relavant rules .... tracert is the ip of the box I am
> trying to traceroute form.
> The Ip of that box is an internet routable ip addess.
>
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
>
> $IPT -A rh-net -s <tracert box> -j ACCEPT
> $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

You should allow ICMP packets through your system.

You should certainly allow ICMP through if you want traceroute to work, and 
you should generally allow ICMP if you want many other things to work.   If 
you want to block certain types of ICMP, that's fine (many people do), but 
don't block all ICMP.

Traceroute works by sending either ICMP "ping" (echo request) packets, or UDP 
packets to high port numbers (which are assumed not to be listening), 
depending on the Operating System of the client doing the traceroute.   In 
both cases the important response is an ICMP TTL exceeded packet, which 
contains the IP address of the router where TTL became == 0.

Remember that firewalling can be a dangerous topic - if you block things you 
don't understand, and therefore don't know that you should allow, some things 
will break.

Regards,

Antony.

-- 
Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Nobel Prizewinner in Physics

                                                     Please reply to the list;
                                                           please don't CC me.

RE: traceroute

[Piszcz, Justin Michael]

ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.

You do not have to allow it explicitly (ie: allow icmp so other machines
can ping your machine).

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 10:58 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:

> -----Original Message-----
> From: Peter Marshall [mailto:peter.marshall@caris.com]
> Sent: Wednesday, June 30, 2004 10:25 AM
> To: Piszcz, Justin Michael; netfilter
> Subject: Re: traceroute
>
> I don't get anything (except the name lookup) from traceroute.
>
> Below are the relavant rules .... tracert is the ip of the box I am
> trying to traceroute form.
> The Ip of that box is an internet routable ip addess.
>
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
>
> $IPT -A rh-net -s <tracert box> -j ACCEPT
> $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

You should allow ICMP packets through your system.

You should certainly allow ICMP through if you want traceroute to work,
and 
you should generally allow ICMP if you want many other things to work.
If 
you want to block certain types of ICMP, that's fine (many people do),
but 
don't block all ICMP.

Traceroute works by sending either ICMP "ping" (echo request) packets,
or UDP 
packets to high port numbers (which are assumed not to be listening), 
depending on the Operating System of the client doing the traceroute.
In 
both cases the important response is an ICMP TTL exceeded packet, which 
contains the IP address of the router where TTL became == 0.

Remember that firewalling can be a dangerous topic - if you block things
you 
don't understand, and therefore don't know that you should allow, some
things 
will break.

Regards,

Antony.

-- 
Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Nobel Prizewinner in Physics

                                                     Please reply to the
list;
                                                           please don't
CC me.

RE: traceroute

[Jozsef Kadlecsik]

On Wed, 30 Jun 2004, Piszcz, Justin Michael wrote:

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.

That's false.

> You do not have to allow it explicitly (ie: allow icmp so other machines
> can ping your machine).

That's false, again.

Read the documentation and do not spread false info.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: traceroute

[Piszcz, Justin Michael]

I use -I INPUT ESTABLISHED,RELATED.

I can ping outbound just fine, ESTABLISHED,RELATED keeps track of the
ICMPs.

Here:

$ ping yahoo.com
PING yahoo.com (216.109.127.28) 56(84) bytes of data.
64 bytes from w1.rc.dcn.yahoo.com (216.109.127.28): icmp_seq=1 ttl=54
time=114 ms
--- yahoo.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 114.523/114.523/114.523/0.000 ms
$

I do not allow any ICMP explicitly and I have never had a problem using
NAT or similar.

I do not know where you are getting your info from, but it is clearly
incorrect.

-----Original Message-----
From: Jozsef Kadlecsik [mailto:kadlec@blackhole.kfki.hu] 
Sent: Wednesday, June 30, 2004 11:19 AM
To: Piszcz, Justin Michael
Cc: netfilter
Subject: RE: traceroute

On Wed, 30 Jun 2004, Piszcz, Justin Michael wrote:

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.

That's false.

> You do not have to allow it explicitly (ie: allow icmp so other
machines
> can ping your machine).

That's false, again.

Read the documentation and do not spread false info.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
>
> You do not have to allow it explicitly (ie: allow icmp so other machines
> can ping your machine).

Please look at the rules which are being used:

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

They are explicitly accepting TCP and UDP only.   ICMP will not be matched by 
the above rules.

Regards,

Antony.

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 10:58 AM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > -----Original Message-----
> > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > Sent: Wednesday, June 30, 2004 10:25 AM
> > To: Piszcz, Justin Michael; netfilter
> > Subject: Re: traceroute
> >
> > I don't get anything (except the name lookup) from traceroute.
> >
> > Below are the relavant rules .... tracert is the ip of the box I am
> > trying to traceroute form.
> > The Ip of that box is an internet routable ip addess.
> >
> > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
> >
> > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> >
> > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> You should allow ICMP packets through your system.
>
> You should certainly allow ICMP through if you want traceroute to work,
> and
> you should generally allow ICMP if you want many other things to work.
> If
> you want to block certain types of ICMP, that's fine (many people do),
> but
> don't block all ICMP.
>
> Traceroute works by sending either ICMP "ping" (echo request) packets,
> or UDP
> packets to high port numbers (which are assumed not to be listening),
> depending on the Operating System of the client doing the traceroute.
> In
> both cases the important response is an ICMP TTL exceeded packet, which
> contains the IP address of the router where TTL became == 0.
>
> Remember that firewalling can be a dangerous topic - if you block things
> you
> don't understand, and therefore don't know that you should allow, some
> things
> will break.
>
> Regards,
>
> Antony.

-- 
This is not a rehearsal.
This is Real Life.

                                                     Please reply to the list;
                                                           please don't CC me.

RE: traceroute

[Piszcz, Justin Michael]

Yes, that is why I recommended to him to set the INPUT to
ESTABLISHED,RELATED, which may help to solve his problem, as well as
setting the policy (FORWARD) to ACCEPT until he can find out what
exactly is causing his problem(s).



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 11:33 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
>
> You do not have to allow it explicitly (ie: allow icmp so other
machines
> can ping your machine).

Please look at the rules which are being used:

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

They are explicitly accepting TCP and UDP only.   ICMP will not be
matched by 
the above rules.

Regards,

Antony.

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 10:58 AM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > -----Original Message-----
> > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > Sent: Wednesday, June 30, 2004 10:25 AM
> > To: Piszcz, Justin Michael; netfilter
> > Subject: Re: traceroute
> >
> > I don't get anything (except the name lookup) from traceroute.
> >
> > Below are the relavant rules .... tracert is the ip of the box I am
> > trying to traceroute form.
> > The Ip of that box is an internet routable ip addess.
> >
> > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j
ACCEPT
> > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j
ACCEPT
> >
> > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> >
> > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> You should allow ICMP packets through your system.
>
> You should certainly allow ICMP through if you want traceroute to
work,
> and
> you should generally allow ICMP if you want many other things to work.
> If
> you want to block certain types of ICMP, that's fine (many people do),
> but
> don't block all ICMP.
>
> Traceroute works by sending either ICMP "ping" (echo request) packets,
> or UDP
> packets to high port numbers (which are assumed not to be listening),
> depending on the Operating System of the client doing the traceroute.
> In
> both cases the important response is an ICMP TTL exceeded packet,
which
> contains the IP address of the router where TTL became == 0.
>
> Remember that firewalling can be a dangerous topic - if you block
things
> you
> don't understand, and therefore don't know that you should allow, some
> things
> will break.
>
> Regards,
>
> Antony.

-- 
This is not a rehearsal.
This is Real Life.

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 5:10 pm, Piszcz, Justin Michael wrote:

> Yes, that is why I recommended to him to set the INPUT to
> ESTABLISHED,RELATED, which may help to solve his problem, as well as
> setting the policy (FORWARD) to ACCEPT until he can find out what
> exactly is causing his problem(s).

What's the purpose of making any changes to the INPUT chain when the packets 
are being routed through the firewall to somewhere else?

I could just about understand if you were ensuring that his OUTPUT chain 
allowed the ICMP TTL Exceeded packets to leave the firewall for that 
particular hop, but I don't see where INPUT comes into it at all?

Regards,

Antony.

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 11:33 AM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:
> > ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
> >
> > You do not have to allow it explicitly (ie: allow icmp so other
>
> machines
>
> > can ping your machine).
>
> Please look at the rules which are being used:
>
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> They are explicitly accepting TCP and UDP only.   ICMP will not be
> matched by
> the above rules.
>
> Regards,
>
> Antony.
>
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org
> > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> > Sent: Wednesday, June 30, 2004 10:58 AM
> > To: netfilter
> > Subject: Re: traceroute
> >
> > On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > > -----Original Message-----
> > > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > > Sent: Wednesday, June 30, 2004 10:25 AM
> > > To: Piszcz, Justin Michael; netfilter
> > > Subject: Re: traceroute
> > >
> > > I don't get anything (except the name lookup) from traceroute.
> > >
> > > Below are the relavant rules .... tracert is the ip of the box I am
> > > trying to traceroute form.
> > > The Ip of that box is an internet routable ip addess.
> > >
> > > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j
>
> ACCEPT
>
> > > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j
>
> ACCEPT
>
> > > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> > >
> > > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
> >
> > You should allow ICMP packets through your system.
> >
> > You should certainly allow ICMP through if you want traceroute to
>
> work,
>
> > and
> > you should generally allow ICMP if you want many other things to work.
> > If
> > you want to block certain types of ICMP, that's fine (many people do),
> > but
> > don't block all ICMP.
> >
> > Traceroute works by sending either ICMP "ping" (echo request) packets,
> > or UDP
> > packets to high port numbers (which are assumed not to be listening),
> > depending on the Operating System of the client doing the traceroute.
> > In
> > both cases the important response is an ICMP TTL exceeded packet,
>
> which
>
> > contains the IP address of the router where TTL became == 0.
> >
> > Remember that firewalling can be a dangerous topic - if you block
>
> things
>
> > you
> > don't understand, and therefore don't know that you should allow, some
> > things
> > will break.
> >
> > Regards,
> >
> > Antony.

-- 
The first fifty percent of an engineering project takes ninety percent of the 
time, and the remaining fifty percent takes another ninety percent of the 
time.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: traceroute

[Peter Marshall]

It is fixed now .. I needed the established / related to be icmp and on both
subchains (in and out) of the forwared chain pertaining to the ip address of
the machine that I was running the traceroute from.

Thank you all for the help.

The strange thing is that I also had to allow icmp type 11 on the output
chain (comming into my dmz) ... I do not understand why I need this here ..
but it does not work without it ...

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 1:10 PM
Subject: RE: traceroute


Yes, that is why I recommended to him to set the INPUT to
ESTABLISHED,RELATED, which may help to solve his problem, as well as
setting the policy (FORWARD) to ACCEPT until he can find out what
exactly is causing his problem(s).



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 11:33 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
>
> You do not have to allow it explicitly (ie: allow icmp so other
machines
> can ping your machine).

Please look at the rules which are being used:

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

They are explicitly accepting TCP and UDP only.   ICMP will not be
matched by
the above rules.

Regards,

Antony.

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 10:58 AM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > -----Original Message-----
> > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > Sent: Wednesday, June 30, 2004 10:25 AM
> > To: Piszcz, Justin Michael; netfilter
> > Subject: Re: traceroute
> >
> > I don't get anything (except the name lookup) from traceroute.
> >
> > Below are the relavant rules .... tracert is the ip of the box I am
> > trying to traceroute form.
> > The Ip of that box is an internet routable ip addess.
> >
> > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j
ACCEPT
> > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j
ACCEPT
> >
> > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> >
> > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> You should allow ICMP packets through your system.
>
> You should certainly allow ICMP through if you want traceroute to
work,
> and
> you should generally allow ICMP if you want many other things to work.
> If
> you want to block certain types of ICMP, that's fine (many people do),
> but
> don't block all ICMP.
>
> Traceroute works by sending either ICMP "ping" (echo request) packets,
> or UDP
> packets to high port numbers (which are assumed not to be listening),
> depending on the Operating System of the client doing the traceroute.
> In
> both cases the important response is an ICMP TTL exceeded packet,
which
> contains the IP address of the router where TTL became == 0.
>
> Remember that firewalling can be a dangerous topic - if you block
things
> you
> don't understand, and therefore don't know that you should allow, some
> things
> will break.
>
> Regards,
>
> Antony.

-- 
This is not a rehearsal.
This is Real Life.

                                                     Please reply to the
list;
                                                           please don't
CC me.

RE: traceroute

[Piszcz, Justin Michael]

I was not aware he had a DMZ.

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 12:22 PM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 5:10 pm, Piszcz, Justin Michael wrote:

> Yes, that is why I recommended to him to set the INPUT to
> ESTABLISHED,RELATED, which may help to solve his problem, as well as
> setting the policy (FORWARD) to ACCEPT until he can find out what
> exactly is causing his problem(s).

What's the purpose of making any changes to the INPUT chain when the
packets 
are being routed through the firewall to somewhere else?

I could just about understand if you were ensuring that his OUTPUT chain

allowed the ICMP TTL Exceeded packets to leave the firewall for that 
particular hop, but I don't see where INPUT comes into it at all?

Regards,

Antony.

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 11:33 AM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:
> > ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
> >
> > You do not have to allow it explicitly (ie: allow icmp so other
>
> machines
>
> > can ping your machine).
>
> Please look at the rules which are being used:
>
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> They are explicitly accepting TCP and UDP only.   ICMP will not be
> matched by
> the above rules.
>
> Regards,
>
> Antony.
>
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org
> > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony
Stone
> > Sent: Wednesday, June 30, 2004 10:58 AM
> > To: netfilter
> > Subject: Re: traceroute
> >
> > On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > > -----Original Message-----
> > > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > > Sent: Wednesday, June 30, 2004 10:25 AM
> > > To: Piszcz, Justin Michael; netfilter
> > > Subject: Re: traceroute
> > >
> > > I don't get anything (except the name lookup) from traceroute.
> > >
> > > Below are the relavant rules .... tracert is the ip of the box I
am
> > > trying to traceroute form.
> > > The Ip of that box is an internet routable ip addess.
> > >
> > > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j
>
> ACCEPT
>
> > > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j
>
> ACCEPT
>
> > > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> > >
> > > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j
ACCEPT
> >
> > You should allow ICMP packets through your system.
> >
> > You should certainly allow ICMP through if you want traceroute to
>
> work,
>
> > and
> > you should generally allow ICMP if you want many other things to
work.
> > If
> > you want to block certain types of ICMP, that's fine (many people
do),
> > but
> > don't block all ICMP.
> >
> > Traceroute works by sending either ICMP "ping" (echo request)
packets,
> > or UDP
> > packets to high port numbers (which are assumed not to be
listening),
> > depending on the Operating System of the client doing the
traceroute.
> > In
> > both cases the important response is an ICMP TTL exceeded packet,
>
> which
>
> > contains the IP address of the router where TTL became == 0.
> >
> > Remember that firewalling can be a dangerous topic - if you block
>
> things
>
> > you
> > don't understand, and therefore don't know that you should allow,
some
> > things
> > will break.
> >
> > Regards,
> >
> > Antony.

-- 
The first fifty percent of an engineering project takes ninety percent
of the 
time, and the remaining fifty percent takes another ninety percent of
the 
time.

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 5:28 pm, Piszcz, Justin Michael wrote:

> I was not aware he had a DMZ.

I am not aware whether he has a DMZ either.

As I understood the problem, he's trying to traceroute from a machine inside 
his network to a machine outside his network.

That means the packets will be going through his FORWARD chain, and it doesn't 
make a difference either way whether he has a DMZ or not (nor does it make a 
difference whether either of the endpoints of the traceroute is *within* the 
DMZ...)

Regards,

Antony.

PS: Is there any chance you could stop top-posting on the list please?   It 
gets awfully confusing when people do that...

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> Sent: Wednesday, June 30, 2004 12:22 PM
> To: netfilter
> Subject: Re: traceroute
>
> On Wednesday 30 June 2004 5:10 pm, Piszcz, Justin Michael wrote:
> > Yes, that is why I recommended to him to set the INPUT to
> > ESTABLISHED,RELATED, which may help to solve his problem, as well as
> > setting the policy (FORWARD) to ACCEPT until he can find out what
> > exactly is causing his problem(s).
>
> What's the purpose of making any changes to the INPUT chain when the
> packets
> are being routed through the firewall to somewhere else?
>
> I could just about understand if you were ensuring that his OUTPUT chain
>
> allowed the ICMP TTL Exceeded packets to leave the firewall for that
> particular hop, but I don't see where INPUT comes into it at all?
>
> Regards,
>
> Antony.
>
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org
> > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
> > Sent: Wednesday, June 30, 2004 11:33 AM
> > To: netfilter
> > Subject: Re: traceroute
> >
> > On Wednesday 30 June 2004 4:10 pm, Piszcz, Justin Michael wrote:
> > > ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
> > >
> > > You do not have to allow it explicitly (ie: allow icmp so other
> >
> > machines
> >
> > > can ping your machine).
> >
> > Please look at the rules which are being used:
> >
> > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
> >
> > They are explicitly accepting TCP and UDP only.   ICMP will not be
> > matched by
> > the above rules.
> >
> > Regards,
> >
> > Antony.
> >
> > > -----Original Message-----
> > > From: netfilter-admin@lists.netfilter.org
> > > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony
>
> Stone
>
> > > Sent: Wednesday, June 30, 2004 10:58 AM
> > > To: netfilter
> > > Subject: Re: traceroute
> > >
> > > On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:
> > > > -----Original Message-----
> > > > From: Peter Marshall [mailto:peter.marshall@caris.com]
> > > > Sent: Wednesday, June 30, 2004 10:25 AM
> > > > To: Piszcz, Justin Michael; netfilter
> > > > Subject: Re: traceroute
> > > >
> > > > I don't get anything (except the name lookup) from traceroute.
> > > >
> > > > Below are the relavant rules .... tracert is the ip of the box I
>
> am
>
> > > > trying to traceroute form.
> > > > The Ip of that box is an internet routable ip addess.
> > > >
> > > > $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j
> >
> > ACCEPT
> >
> > > > $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j
> >
> > ACCEPT
> >
> > > > $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> > > > $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
> > > >
> > > > $IPT -A rh-net -s <tracert box> -j ACCEPT
> > > > $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j
>
> ACCEPT
>
> > > You should allow ICMP packets through your system.
> > >
> > > You should certainly allow ICMP through if you want traceroute to
> >
> > work,
> >
> > > and
> > > you should generally allow ICMP if you want many other things to
>
> work.
>
> > > If
> > > you want to block certain types of ICMP, that's fine (many people
>
> do),
>
> > > but
> > > don't block all ICMP.
> > >
> > > Traceroute works by sending either ICMP "ping" (echo request)
>
> packets,
>
> > > or UDP
> > > packets to high port numbers (which are assumed not to be
>
> listening),
>
> > > depending on the Operating System of the client doing the
>
> traceroute.
>
> > > In
> > > both cases the important response is an ICMP TTL exceeded packet,
> >
> > which
> >
> > > contains the IP address of the router where TTL became == 0.
> > >
> > > Remember that firewalling can be a dangerous topic - if you block
> >
> > things
> >
> > > you
> > > don't understand, and therefore don't know that you should allow,
>
> some
>
> > > things
> > > will break.
> > >
> > > Regards,
> > >
> > > Antony.

-- 
If you can't find an Open Source solution for it, then it isn't a real 
problem.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 5:25 pm, Peter Marshall wrote:

> It is fixed now .. I needed the established / related to be icmp and on
> both subchains (in and out) of the forwared chain pertaining to the ip
> address of the machine that I was running the traceroute from.
>
> Thank you all for the help.
>
> The strange thing is that I also had to allow icmp type 11 on the output
> chain (comming into my dmz) ... I do not understand why I need this here ..
> but it does not work without it ...

Aha :) So you *do* have a DMZ after all...   Okay.

The reason you need ICMP type 11 on the OUTPUT chain (presumably facing 
towards the client machine running the traceroute) is so that the TTL 
Exceeded message generated by the firewall itself can exit the machine.

It should only affect that specific hop - all others should work even if you 
just get * * * for the firewall itself.

(I assume you *do* know how traceroute works?   The client sends several 
packets, all addressed to the target of the traceroute, with the first packet 
having TTL=1, the second packet having TTL=2, the third packet..... etc   
Each router which the packets pass through decrements the TTL value, and 
returns ICMP TTL Exceeded if the value becomes zero.   Therefore each router 
along the way generates one message back to the originating client, and all 
the routers up to that point forward both the original packet and the ICMP 
response.)

Regards,

Antony.

-- 
In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

                                                     Please reply to the list;
                                                           please don't CC me.

RE: traceroute

[Jozsef Kadlecsik]

On Wed, 30 Jun 2004, Piszcz, Justin Michael wrote:

> I use -I INPUT ESTABLISHED,RELATED.
>
> I can ping outbound just fine, ESTABLISHED,RELATED keeps track of the
> ICMPs.

You could not ping outbound without setting up proper rules in the OUTPUT
chain. Your machine cannot be pinged with the rules above alone. Your rule
above does not let through ping responses on a firewall. In other words it
does not allow ICMP in general.

> I do not know where you are getting your info from, but it is clearly
> incorrect.

You yourself claimed that:

> > You do not have to allow it explicitly (ie: allow icmp so other
> > machines can ping your machine).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: traceroute

[Piszcz, Justin Michael]

If the output chain POLICY is set to ACCEPT; there is no need to setup
rules for it.


-----Original Message-----
From: Jozsef Kadlecsik [mailto:kadlec@blackhole.kfki.hu] 
Sent: Wednesday, June 30, 2004 2:18 PM
To: Piszcz, Justin Michael
Cc: netfilter
Subject: RE: traceroute

On Wed, 30 Jun 2004, Piszcz, Justin Michael wrote:

> I use -I INPUT ESTABLISHED,RELATED.
>
> I can ping outbound just fine, ESTABLISHED,RELATED keeps track of the
> ICMPs.

You could not ping outbound without setting up proper rules in the
OUTPUT
chain. Your machine cannot be pinged with the rules above alone. Your
rule
above does not let through ping responses on a firewall. In other words
it
does not allow ICMP in general.

> I do not know where you are getting your info from, but it is clearly
> incorrect.

You yourself claimed that:

> > You do not have to allow it explicitly (ie: allow icmp so other
> > machines can ping your machine).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: traceroute

[Cedric Blancher]

Le mer 30/06/2004 à 17:21, Piszcz, Justin Michael a écrit :
> I do not know where you are getting your info from, but it is clearly
> incorrect.

From the source code, I guess, just like I did.

You have two type of ICMP handling. On one hand hand, you have
request/response ICMP stuff : echo, timestamp, netmask and info. Theses
messages are handled with state NEW for request and state ESTABLISHED
for answer. So an ICMP echo request has NEW state and related ICMP echo
reply is ESTABLISHED. A lonely ICMP echo reply is INVALID. On the other
hand, you have ICMP errors, that have RELATED state as long as kernel is
able to find to which conntrack entry they belong. Otherwise, they're
INVALID.

So, if you don't allow ICMP with NEW state in INPUT chain, then no one
will be able to ping you.

See /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c file.

So you're simply wrong.

> I do not allow any ICMP explicitly and I have never had a problem
> using NAT or similar.

And if you're able to ping anyway, it means you have a rule that
implicitly accepts thoses packets, and then should read your ruleset
again.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

RE: traceroute

[Cedric Blancher]

Le mer 30/06/2004 à 20:20, Piszcz, Justin Michael a écrit :
> If the output chain POLICY is set to ACCEPT; there is no need to setup
> rules for it.

Indeed, if you accept _any_ packet, you don't need to make rules to
accept ICMP ones in particular... And if you set all chains policy to
accept, then you do not need any rule, for any type of packet, and then
it's so easy to configure...

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: traceroute

[Florian Boelstler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have a similar problem.

My traceroute says:

traceroute to www.google.akadns.net (66.102.11.99), 30 hops max, 38 byte
packets
traceroute: sendto: Operation not permitted
 1 traceroute: wrote www.google.akadns.net 38 chars, ret=-1
[ ... ]

My setup is rather simple. I have "black-boxed" router connected to the
internet, that is able to forward traceroutes. My client is equipped
with netfilter.
When I disable my local netfilter on the client, traceroute works fine.

I use

$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

at the beginning of my firewall script.

Nevertheless traceroute does not work.

Do I miss something?

Thanks.

Cheers,

  Florian


Antony Stone wrote:
> On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:
>
>
>>Hi.  I was wondering what I would need for rules to have traceroute work
>>through my firewall.  (I have a box behind the firewall trying to get out
>>using traceroute).
>>
>>I have an allow established connections on my forwared chain, and I am
>>allowing anything from the source IP of the box in question to leave
... It
>>appears that the problem is on the packets comming back in .. but I am not
>>sure what I have to do to fix it ....
>
>
> Allow RELATED packets as well as ESTABLISHED.
>
> Regards,
>
> Antony.
>




...............................

Someone on the net said:
Frank, have you been sniffing medical samples again? - Hawkeye


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA4zTswT2gPfZm6tURAoOnAKCtHbVHsvg7nrTBCviE4DVydenpQgCfeVuS
jdBS08sKpALhTTMJ+gGYcsc=
=g53n
-----END PGP SIGNATURE-----

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 10:47 pm, Florian Boelstler wrote:

> Hi,
>
> I have a similar problem.
>
> My traceroute says:
>
> traceroute to www.google.akadns.net (66.102.11.99), 30 hops max, 38 byte
> packets
> traceroute: sendto: Operation not permitted
>  1 traceroute: wrote www.google.akadns.net 38 chars, ret=-1
> [ ... ]
>
> My setup is rather simple. I have "black-boxed" router connected to the
> internet, that is able to forward traceroutes. My client is equipped
> with netfilter.
> When I disable my local netfilter on the client, traceroute works fine.
>
> I use
>
> $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> at the beginning of my firewall script.
>
> Nevertheless traceroute does not work.
>
> Do I miss something?

Tell us how you handle NEW packets leaving the machine.

Regards,

Antony.

-- 
"The problem with television is that the people must sit and keep their eyes 
glued on a screen; the average American family hasn't time for it."

 - New York Times, following a demonstration at the 1939 World's Fair.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: traceroute

[Florian Boelstler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Antony Stone wrote:
> Tell us how you handle NEW packets leaving the machine.

Well, I just realized by looking at your reply that I only have set:

$IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT

Which of the icmp-type displayed "iptables -p icmp -h" do I need to make
traceroute work?

By looking at other posts in this thread I've learned that traceroutes
are done with echo-requests. Is this true for Linux 2.6.6 ?

Thanks,

  Florian



...............................

Someone on the net said:
G'Kar: 2 hours ago my government declared war on the Centari Republic


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA40BiwT2gPfZm6tURAkaLAJ4zRVtBrVbhxVgcPuCs/ZiGVvX1TACdGJOU
eKewKcpjQbMlyTtm9omcJZ8=
=qjuX
-----END PGP SIGNATURE-----

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 11:36 pm, Florian Boelstler wrote:

> Hi,
>
> Antony Stone wrote:
> > Tell us how you handle NEW packets leaving the machine.
>
> Well, I just realized by looking at your reply that I only have set:
>
> $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT
>
> Which of the icmp-type displayed "iptables -p icmp -h" do I need to make
> traceroute work?
>
> By looking at other posts in this thread I've learned that traceroutes
> are done with echo-requests. Is this true for Linux 2.6.6 ?

No, that's true for Windows systems.   Unix machines (Linux included) uses 
high-port numbered UDP packets.

Therefore you need to allow UDP packets to leave your machine for you to be 
able to run traceroute from it.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.

Re: traceroute

[Florian Boelstler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Antony Stone wrote:
>>By looking at other posts in this thread I've learned that traceroutes
>>are done with echo-requests. Is this true for Linux 2.6.6 ?
>
>
> No, that's true for Windows systems.   Unix machines (Linux included)
uses
> high-port numbered UDP packets.
>
> Therefore you need to allow UDP packets to leave your machine for you
to be
> able to run traceroute from it.

Hmm, this could end up in an unfeasible task, when I do not allow
unrestricted output.

I just found out that traceroute offers a -I switch, that uses ICMP echo
requests instead.
On the other hand one could use -p for a specific base port to get a
certain determinism.

   Florian



...............................

Someone on the net said:
I am Clinton of Borg. Prepare to see me make a fool of myself.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA40d1wT2gPfZm6tURAn4AAJ9OfnD/kMw7Ua1ss/7lRfQzIbo5SgCfezgN
Ch0ifus6ReGzusVIarwR+z8=
=bIgk
-----END PGP SIGNATURE-----

Re: traceroute

[Cedric Blancher]

Le mer 30/06/2004 à 23:47, Florian Boelstler a écrit :
> My traceroute says:
> traceroute to www.google.akadns.net (66.102.11.99), 30 hops max, 38 byte
> packets
> traceroute: sendto: Operation not permitted
>  1 traceroute: wrote www.google.akadns.net 38 chars, ret=-1
> [ ... ]

You must have an OUTPUT rule that forbid UDP to high ports, thus
traceroute cannot send its packets.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

RE: traceroute

[Jozsef Kadlecsik]

On Wed, 30 Jun 2004, Piszcz, Justin Michael wrote:

> If the output chain POLICY is set to ACCEPT; there is no need to setup
> rules for it.

Exactly, if. And what about the other two possibilities?:

> Your machine cannot be pinged with the rules above alone. Your rule
> above does not let through ping responses on a firewall. In other
> words it does not allow ICMP in general.
>
> You yourself claimed that:
>
> > > You do not have to allow it explicitly (ie: allow icmp so other
> > > machines can ping your machine).

Sorry, but you made a general statement which is true only when a couple
of other conditions are met as well. Without even mentioning that is
misleading for the readers of the list.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: traceroute

[Jozsef Kadlecsik]

On Wed, 30 Jun 2004, Antony Stone wrote:

> On Wednesday 30 June 2004 11:36 pm, Florian Boelstler wrote:
>
> > > Tell us how you handle NEW packets leaving the machine.
> >
> > By looking at other posts in this thread I've learned that traceroutes
> > are done with echo-requests. Is this true for Linux 2.6.6 ?
>
> No, that's true for Windows systems.   Unix machines (Linux included) uses
> high-port numbered UDP packets.
>
> Therefore you need to allow UDP packets to leave your machine for you to be
> able to run traceroute from it.

Actually UDP based traceroute uses ports in the range 33434-33523.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: traceroute

[Antony Stone]

On Thursday 01 July 2004 10:21 am, Jozsef Kadlecsik wrote:

> On Wed, 30 Jun 2004, Antony Stone wrote:
> > On Wednesday 30 June 2004 11:36 pm, Florian Boelstler wrote:
> > >
> > > By looking at other posts in this thread I've learned that traceroutes
> > > are done with echo-requests. Is this true for Linux 2.6.6 ?
> >
> > No, that's true for Windows systems.   Unix machines (Linux included)
> > use high-port numbered UDP packets.
> >
> > Therefore you need to allow UDP packets to leave your machine for you to
> > be able to run traceroute from it.
>
> Actually UDP based traceroute uses ports in the range 33434-33523.

That's one of things I like about this mailing list - I can find people who 
are even more precise and pedantic than I am :)

Antony.

-- 
There are two possible outcomes:

 If the result confirms the hypothesis, then you've made a measurement.
 If the result is contrary to the hypothesis, then you've made a discovery.

 - Enrico Fermi

                                                     Please reply to the list;
                                                           please don't CC me.

RE: traceroute

[Piszcz, Justin Michael]

He was talking about pinging from behind his NAT, it has nothing to do with people pinging him, FYI.


-----Original Message-----
From: Cedric Blancher [mailto:blancher@cartel-securite.fr] 
Sent: Wednesday, June 30, 2004 4:51 PM
To: Piszcz, Justin Michael
Cc: Jozsef Kadlecsik; netfilter
Subject: RE: traceroute

Le mer 30/06/2004 à 17:21, Piszcz, Justin Michael a écrit :
> I do not know where you are getting your info from, but it is clearly
> incorrect.

From the source code, I guess, just like I did.

You have two type of ICMP handling. On one hand hand, you have
request/response ICMP stuff : echo, timestamp, netmask and info. Theses
messages are handled with state NEW for request and state ESTABLISHED
for answer. So an ICMP echo request has NEW state and related ICMP echo
reply is ESTABLISHED. A lonely ICMP echo reply is INVALID. On the other
hand, you have ICMP errors, that have RELATED state as long as kernel is
able to find to which conntrack entry they belong. Otherwise, they're
INVALID.

So, if you don't allow ICMP with NEW state in INPUT chain, then no one
will be able to ping you.

See /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c file.

So you're simply wrong.

> I do not allow any ICMP explicitly and I have never had a problem
> using NAT or similar.

And if you're able to ping anyway, it means you have a rule that
implicitly accepts thoses packets, and then should read your ruleset
again.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: traceroute

[Jozsef Kadlecsik]

On Thu, 1 Jul 2004, Antony Stone wrote:

> > > No, that's true for Windows systems.   Unix machines (Linux included)
> > > use high-port numbered UDP packets.
> > >
> > Actually UDP based traceroute uses ports in the range 33434-33523.
>
> That's one of things I like about this mailing list - I can find people who
> are even more precise and pedantic than I am :)

It's from Building Internet Firewalls by Chapman & Zwicky :-).

We have been using the corresponding rule for ages. It failed for HPUX
only because we used unclean matching as well and the old one did not know
about the fact that UDP checksumming is not mandatory. [unclean match has
been fixed since then, of course.]

Can't be repeated enough time, your tireless valuable help on the list is
highly appreciated! (And your sigs are simply great! :-)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: traceroute

[Cedric Blancher]

Le jeu 01/07/2004 à 11:21, Jozsef Kadlecsik a écrit :
> Actually UDP based traceroute uses ports in the range 33434-33523.

Just an add-on for those who want to allow traceroute through a
Netfilter firewall in FORWARD : Windows traceroute uses ICMP echo
requests. Thus, ICMP echo has to be accepted in order to have it work
from Windwos boxes.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

RE: traceroute

[Cedric Blancher]

Le jeu 01/07/2004 à 11:52, Piszcz, Justin Michael a écrit :
> He was talking about pinging from behind his NAT, it has nothing to do
> with people pinging him, FYI.

I picked the thread at this stage, and for what I understood, your
statement about ICMP filtering was far more general than this very
situation with some profitable ruleset :

> ICMP is "allowed" when you -I INPUT ESTABLISHED,RELATED.
> You do not have to allow it explicitly (ie: allow icmp so other
> machines can ping your machine).


Anyway, even in this kind of situation, NAT handling is one thing, and
filtering is another. So, depending on how your filtering rules are
implemented, your statement remains wrong.

I don't mean to be aggressive upon you, but for what I read from this
thread, you made a wrong statement about ICMP filtering, and that's it.
Bas faith arguing on some special background context has no relevance.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!