icmp type 11 not go via nat POSTROUTING table

Got strange thing: I have rule
iptables -t nat -A POSTROUTING -s x.y.z.t -j SNAT --to-source a.b.c.d
but localy generated
icmp packets type 11 not go via nat POSTROUTING table
while almost same packets with differrent type (8) get going and
altered according rule
Anybody know why?

(E-Mail Removed) wrote:
> Got strange thing: I have rule
> iptables -t nat -A POSTROUTING -s x.y.z.t -j SNAT --to-source a.b.c.d
> but localy generated

Do you mean "locally generated" on a.b.c.d? Is this a gateway/router
or an end station?

> icmp packets type 11 ...

Do you mean "ICMP type 11, Time exceeded message"? Code 0 (TTL) or
code 1 (fragment reassembly timeout)? Code 0 is approprate for a
router and is generally mandatory, code 1 is appropriate for an end
host (routers don't reassemble fragments) and is optional (and I don't
remember seeing one or looking for one on a Linux box).

The internet header plus the first 8 bytes of the original datagram's
data is returned to the sender. [From link below]

> ... not go via nat POSTROUTING table

_All_ packets leaving an interface pass through the postrouting chain
before exiting. What do you mean here? By what test did you determine
this?

> while almost same packets with differrent type (8) get going and
> altered according rule
> Anybody know why?

It's really not clear to me what you are observing or what you expect
to observe. "ICMP type 8, Echo request" are quite common, and if
everthing is working as it "should", there is no reason for a "ICMP
type 11, Time exceeded message" to be generated under normal
circumstances. Could you clarify?

You might doulbe check here for a quick look at the protocol format:
http://www.networksorcery.com/enp/pr...icmp/msg11.htm
http://www.networksorcery.com/enp/default0504.htm

cheers,
prg

>> Got strange thing: I have rule
>> iptables -t nat -A POSTROUTING -s x.y.z.t -j SNAT --to-source a.b.c.d
>> but localy generated

> Do you mean "locally generated" on a.b.c.d?

packets were generated on x.y.z.t

>> icmp packets type 11 ...

>Do you mean "ICMP type 11, Time exceeded message"? ...

exactly right


>> ... not go via nat POSTROUTING table

>_All_ packets leaving an interface pass through the postrouting chain
>before exiting. What do you mean here? By what test did you determine
>this?

I also belived so, but
I looked using tcpdump

>> while almost same packets with differrent type (8) get going and
>> altered according rule
>> Anybody know why?

>It's really not clear to me what you are observing or what you expect
>to observe. "ICMP type 8, Echo request" are quite common, and if
>everthing is working as it "should", there is no reason for a "ICMP
>type 11, Time exceeded message" to be generated under normal
>circumstances. Could you clarify?

so: I generated two test icmp packets
1) src x.y.z.t dst host.on.inet icmp-type 11 code 0
2) src x.y.z.t dst host.on.inet icmp-type 8
tcpdump on output interface showed
1) src x.y.z.t dst host.on.inet icmp-type 11 code 0
2) src a.b.c.d dst host.on.inet icmp-type 8

ICMP type 11 in my case is intended to answer to traceroute showing
nexthop a.b.c.d, not x.y.z.t(which is private address so answering
packet then get lost when travelling via inet)

(E-Mail Removed) wrote:
> >> Got strange thing: I have rule
> >> iptables -t nat -A POSTROUTING -s x.y.z.t -j SNAT --to-source a.b.c.d
> >> but localy generated
>
> > Do you mean "locally generated" on a.b.c.d?
>
> packets were generated on x.y.z.t
>
> >> icmp packets type 11 ...
>
> >Do you mean "ICMP type 11, Time exceeded message"? ...
>
> exactly right
>
>
> >> ... not go via nat POSTROUTING table
>
> >_All_ packets leaving an interface pass through the postrouting chain
> >before exiting. What do you mean here? By what test did you determine
> >this?
>
> I also belived so, but
> I looked using tcpdump

Thought this might be what you were doing. It confirms what is going
out on the wire. Good.

> >> while almost same packets with differrent type (8) get going and
> >> altered according rule
> >> Anybody know why?
>
> >It's really not clear to me what you are observing or what you expect
> >to observe. "ICMP type 8, Echo request" are quite common, and if
> >everthing is working as it "should", there is no reason for a "ICMP
> >type 11, Time exceeded message" to be generated under normal
> >circumstances. Could you clarify?
>
> so: I generated two test icmp packets

Would be interesting -- but probably not relavant -- to know how you
generated the packets.

> 1) src x.y.z.t dst host.on.inet icmp-type 11 code 0

This is an ICMP _error_ code. They are "special".

> 2) src x.y.z.t dst host.on.inet icmp-type 8
> tcpdump on output interface showed
> 1) src x.y.z.t dst host.on.inet icmp-type 11 code 0

So Linux refused to honor your attempt to "break" the ICMP protocol
standards. This is good. I don't know offhand if this is a netfilter
or TCP/IP stack enforcement. Look at the source code to find out where
the check is made. The src in the IP header here should (MUST?) be the
IP of the host that generated the error message, IIRC. Haven't looked
closely at the RFCs lately. This is how traceroute knows the IP of the
host/router that sees the TTL go zero.

> 2) src a.b.c.d dst host.on.inet icmp-type 8

These are ICMP queries -- _not_ errors -- so can reasonably be less
strictly enforced.

> ICMP type 11 in my case is intended to answer to traceroute showing
> nexthop a.b.c.d, not x.y.z.t(which is private address so answering
> packet then get lost when travelling via inet)

If x.y.z.t is a private IP address, it cannot be tracerouted anyway, so
there is nothing really to "fix". What you are trying to do by
"explicitly" indicating/predicting/routing to the nexthop along the
path breaks the protocol and won't work anyway. Traceroute relies on
the routing tables to forward packets and the destination never
changes. In fact, traceroute is "notorious" for _ignoring_ ICMP error
messages -- it just uses the IP src indicated in the header returned to
indicate the host that saw TTL go zero and never looks at the ICMP
data. Even if it gets _no_ response from a host/router along the path,
it will continue sending additional probes till it maxes out or reaches
its destination.

$ man traceroute

to see some interesting examples of how traceroute works in the "real
world". Also note that there are other means of performing a
"traceroute". The thing they all have in common is that none of them
can traceroute a private IP address over the internet -- the addresses
are not routable.

Some ASNs operated by ISPs interpose a private network between the
internet and their clients' stubs and tracerouting a private IP _may_
produce some interesting results inside the private network.

What is interesting is that Linux code is preventing you from
"breaking" the protocol standard. It could be code in the kernel's IP
stack or it could be (or additionally be) code in netfilter. ICMP
error messages are meant to keep IP running "true to form" or at least
help when problems arise. If any bloke could willy-nilly start
slinging ICMP error messages around with inconsistent/bogus
headers/data then the protocol would be useless.

It is best to contol probes and ICMP error messages at your gateway by
other means.

does this help?
prg