[Shorewall-users] Three way ICMP ?

Tom Eastep
2003-12-02T12:48:05Z

On Tue, 2003-12-02 at 11:39, Bill.Light@kp.org wrote:
> On Mon, 2003-12-01 at 18:04, Bill.Light@kp.org wrote:
> > I''m getting 2 or three of these a day...Any ideas ?
> >
> > The 192.168.250.zz  is a eth0:3  on a box that currently only has
eth0:1
>
> > active
> >
> > Dec  1 15:47:40 machine-name kernel: Shorewall:all2all:REJECT:IN=
> OUT=eth0
> > SRC=my.real.ip.addr DST=66.228.216.22 LEN=68 TOS=0x00 PREC=0xC0
TTL=255
> > ID=12031 PROTO=ICMP TYPE=3 CODE=1 [SRC=66.228.216.22
DST=192.168.250.zz
> > LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=36178 PROTO=TCP INCOMPLETE [8
bytes]
> ]
> >
> > This is the same type activity when Tom had guessed that I had been
> > compromised before - Tripwire says NO I have NOT been compromised as
> well
> > as anything else I can check says everything is still safe.   This box
> is
> > a SuSE 7.3 Professional (2.4.16 Kernel) running Shorewall 1.4.8.  The
> box
> > has been up 185 days straight (replaced UPS batteries) without a
hiccup
> > the 192.168.250.zz  is in my DMZ on eth0   That DMZ box is a SuSE 9.0
> > Professional (2.4.21 Kernel) running apache and shorewall 1.4.8
without
> > any log entries except for me to get NTP working (and I don''t
have it
> > yet...)
> >
> > The 66.228.216.22  is "SexTraffic.com" site that apparently
tries to
> > enlist webmasters to "sign up" for pay site portals...
> >
> > What in the dickens are they doing ?
>
> Do you have any DNAT rules with 192.168.250.zz as the target?
>
> -Tom
>
> ===============================================================>
> Sure do....
>
> Real IP   DNAT to 192.168.250.zz
> Real IP+1  DNAT to 192.168.250.zz+1
> Real IP +2 DNAT to 192.168.250.zz+2
>
> Until I re-do the IP routing that you suggested for this 5 IP setup of SBC

Here''s my best guess -- Because of the DNAT, a connection from
66.228.216.22 -> <Real IP> would be directed to 192.168.250.zz. Since
192.168.250.zz isn''t active, your firewall isn''t able to reach
it so it
is trying to return a <host unreachable> ICMP. The original packet
hasn''t yet been "un-natted" so you are still seeing the the
confusing
destination address 192.168.250.zz rather that "My.real.IP.addr".
Because a connection hasn''t yet been established, the ICMP
isn''t related
to an existing connection so it is being blocked.

You can eliminate these annoying messages by adding this to your
/etc/shorewall/start file:

run_iptables -I OUTPUT 3 -p icmp -j ACCEPT