From: Taner Halicioglu <taner@taner.net>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: netfilter@lists.netfilter.org
Subject: Re: Bug? ICMPs sent by REJECT are not getting SNAT'd...
Date: Tue, 15 Apr 2003 15:37:57 -0700 [thread overview]
Message-ID: <20030415223757.GM5912@boom.net> (raw)
In-Reply-To: <20030411190805.GJ5912@boom.net>
Uh, ok... I solved this comepletely outside of iptables :-)
ip route change default via 10.1.1.1 dev eth1 src 200.1.1.1
works like a charm, and I got rid of my SNAT:
iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1
(no more need for that ;)
-Taner
On Fri, Apr 11, 2003 at 12:08:05PM -0700, Taner Halicioglu <taner@taner.net> wrote:
> On Fri, Apr 11, 2003 at 08:58:00PM +0200, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
>
> > > No, the problem is that when the firewall machine REJECTs any packets in a
> > > FORWARD chain (ie, anything I am blocking that is destined to the network
> > > behind it), the source IP of the ICMP UNREACH (or evn the RST packets) is
> > > that of the *outside* interface - the unroutable address. It seems the
> > > POSTROUTING is not performed on the ICMPs that are created by the actual
> > > host.
> >
> > If this is a problem of the forwarded packets, then it has nothing to do
> > with the connections initiated from/targeted to the firewall itself.
>
> What? Of course it does!
>
> I have a rule like:
>
> iptables -A Firewall -p tcp --dport 1434 -j REJECT
>
> where 'Firewall' is
>
> iptables -A FORWARD -i eth1 -j Firewall
>
> The above rule will generate an ICMPUNREACH if it tries to forward a packet
> coming in eth1 that is destined for port 1434 to anything behind the firewall
> machine.
>
> This UNREACH is generated with a source IP of my firewalls *outside*
> interface, which is the unrouteable address (and is filtered by my ISP). I
> need this ICMP to be generated with a source IP of my *inside* interface,
> instead.
>
> > But if the packets created by the REJECT target contain the address of the
> > firewall, then the packet they are rejecting was targeted to the firewall.
>
> No, see above.
>
> > Show me the tcpdump of both the packets rejected and the reject packets
> > generated.
>
> 12:05:31.037765 66.220.X.Y.38487 > 67.122.A.B.ms-sql-m: S 2857026105:2857026105(0) win 5840 <mss 1460,sackOK,timestamp 406253139 0,nop,wscale 0> (DF) [tos 0x10]
> 12:05:31.037805 10.0.0.1 > 66.220.X.Y: icmp: 67.122.196.121 tcp port ms-sql-m unreachable [tos 0xd0]
>
> Notice how the source address on the ICMP unreach is the unroutable IP. I
> need it to be an address on the 67.122.n.n address block (my inside
> interface).
>
> Refer to my original email w/ diagram again, if you need to :)
>
> -Taner
next prev parent reply other threads:[~2003-04-15 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-02 8:06 Bug? ICMPs sent by REJECT are not getting SNAT'd Taner Halicioglu
2003-04-02 18:38 ` Taner Halicioglu
2003-04-11 7:55 ` Jozsef Kadlecsik
2003-04-11 16:48 ` Taner Halicioglu
2003-04-11 18:58 ` Jozsef Kadlecsik
2003-04-11 19:08 ` Taner Halicioglu
2003-04-15 22:37 ` Taner Halicioglu [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-02 8:03 Taner Halicioglu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030415223757.GM5912@boom.net \
--to=taner@taner.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox