Bug? ICMPs sent by REJECT are not getting SNAT'd...

Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

Hi, I have a somewhat convoluted setup, so I'll try to describe it.

DSL provider gave me a /29 for my machines
	(say, 200.1.1.0/29)
DSL provider also supplied a /30 to go between DSL modem and the DSLAM.
	(say, 201.1.1.0/30 - irrelevant here, really)
I am using a random /30 to go between the DSL modem and my firewall
	(say, 10.1.1.0/30)

Here is the visual:

    [ISP]
      |
      | [201.1.1.0/30 - irrelevant]
      |
+------------+
| DSL router |
+------------+ = 10.1.1.2
      |
      | [10.1.1.0/30]
      |
+------------------+ eth1 = 10.1.1.1
| Firewall machine |
+------------------+ eth0 = 200.1.1.1
      |
      | [200.1.1.0/29]
      |
   [INSIDE]


For right now, my firewall rules are basiclaly nothing - I pass everything
thru the firewall machine.

I soon realised that since I'm using a non-routed address for the "outside"
interface of the firewall, I run into issues trying to initiate any
connection from the fw machine, so I added:

 iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1

This works for 99% of the traffic sourced on the firewall machine, it seems.

One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
packets that are generated by the REJECT target.  These get sourced from the
unroutable address, and since my ISP wisely filters things like that, the
ICMP never makes it to the sender.

Am I doing something wrong, or is this a bug?

Thanks,

	-Taner

Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

Hi, I have a somewhat convoluted setup, so I'll try to describe it.

DSL provider gave me a /29 for my machines
	(say, 200.1.1.0/29)
DSL provider also supplied a /30 to go between DSL modem and the DSLAM.
	(say, 201.1.1.0/30 - irrelevant here, really)
I am using a random /30 to go between the DSL modem and my firewall
	(say, 10.1.1.0/30)

Here is the visual:

    [ISP]
      |
      | [201.1.1.0/30 - irrelevant]
      |
+------------+
| DSL router |
+------------+ = 10.1.1.2
      |
      | [10.1.1.0/30]
      |
+------------------+ eth1 = 10.1.1.1
| Firewall machine |
+------------------+ eth0 = 200.1.1.1
      |
      | [200.1.1.0/29]
      |
   [INSIDE]


For right now, my firewall rules are basiclaly nothing - I pass everything
thru the firewall machine.

I soon realised that since I'm using a non-routed address for the "outside"
interface of the firewall, I run into issues trying to initiate any
connection from the fw machine, so I added:

 iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1

This works for 99% of the traffic sourced on the firewall machine, it seems.

One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
packets that are generated by the REJECT target.  These get sourced from the
unroutable address, and since my ISP wisely filters things like that, the
ICMP never makes it to the sender.

Am I doing something wrong, or is this a bug?

Thanks,

	-Taner

Re: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

Err, I should have mentioned:

 Linux 2.4.20-8 (RedHat 9.0)
 iptables v1.2.7a

(need anything else?)

	-Taner

On Wed, Apr 02, 2003 at 12:06:38AM -0800, Taner Halicioglu <taner@taner.net> wrote:

> Hi, I have a somewhat convoluted setup, so I'll try to describe it.
> 
> DSL provider gave me a /29 for my machines
> 	(say, 200.1.1.0/29)
> DSL provider also supplied a /30 to go between DSL modem and the DSLAM.
> 	(say, 201.1.1.0/30 - irrelevant here, really)
> I am using a random /30 to go between the DSL modem and my firewall
> 	(say, 10.1.1.0/30)
> 
> Here is the visual:
> 
>     [ISP]
>       |
>       | [201.1.1.0/30 - irrelevant]
>       |
> +------------+
> | DSL router |
> +------------+ = 10.1.1.2
>       |
>       | [10.1.1.0/30]
>       |
> +------------------+ eth1 = 10.1.1.1
> | Firewall machine |
> +------------------+ eth0 = 200.1.1.1
>       |
>       | [200.1.1.0/29]
>       |
>    [INSIDE]
> 
> 
> For right now, my firewall rules are basiclaly nothing - I pass everything
> thru the firewall machine.
> 
> I soon realised that since I'm using a non-routed address for the "outside"
> interface of the firewall, I run into issues trying to initiate any
> connection from the fw machine, so I added:
> 
>  iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1
> 
> This works for 99% of the traffic sourced on the firewall machine, it seems.
> 
> One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
> packets that are generated by the REJECT target.  These get sourced from the
> unroutable address, and since my ISP wisely filters things like that, the
> ICMP never makes it to the sender.
> 
> Am I doing something wrong, or is this a bug?
> 
> Thanks,
> 
> 	-Taner

Re: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Jozsef Kadlecsik]

Hi,

On Wed, 2 Apr 2003, Taner Halicioglu wrote:

> Hi, I have a somewhat convoluted setup, so I'll try to describe it.
>
> DSL provider gave me a /29 for my machines
> 	(say, 200.1.1.0/29)
> DSL provider also supplied a /30 to go between DSL modem and the DSLAM.
> 	(say, 201.1.1.0/30 - irrelevant here, really)
> I am using a random /30 to go between the DSL modem and my firewall
> 	(say, 10.1.1.0/30)
>
> Here is the visual:
>
>     [ISP]
>       |
>       | [201.1.1.0/30 - irrelevant]
>       |
> +------------+
> | DSL router |
> +------------+ = 10.1.1.2
>       |
>       | [10.1.1.0/30]
>       |
> +------------------+ eth1 = 10.1.1.1
> | Firewall machine |
> +------------------+ eth0 = 200.1.1.1
>       |
>       | [200.1.1.0/29]
>       |
>    [INSIDE]
>
>
> For right now, my firewall rules are basiclaly nothing - I pass everything
> thru the firewall machine.
>
> I soon realised that since I'm using a non-routed address for the "outside"
> interface of the firewall, I run into issues trying to initiate any
> connection from the fw machine, so I added:
>
>  iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1
>
> This works for 99% of the traffic sourced on the firewall machine, it seems.
>
> One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
> packets that are generated by the REJECT target.  These get sourced from the
> unroutable address, and since my ISP wisely filters things like that, the
> ICMP never makes it to the sender.

If I understand your setup and the problem correctly, you mean that you
REJECT requests targeted to the firewall itself and the reject packets
contain the private address of the firewall as source address.

But how packets can reach the private address of your firewall?

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: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

On Fri, Apr 11, 2003 at 09:55:49AM +0200, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:

> > Hi, I have a somewhat convoluted setup, so I'll try to describe it.
> >
> > DSL provider gave me a /29 for my machines
> > 	(say, 200.1.1.0/29)
> > DSL provider also supplied a /30 to go between DSL modem and the DSLAM.
> > 	(say, 201.1.1.0/30 - irrelevant here, really)
> > I am using a random /30 to go between the DSL modem and my firewall
> > 	(say, 10.1.1.0/30)
> > [...]
> > I soon realised that since I'm using a non-routed address for the "outside"
> > interface of the firewall, I run into issues trying to initiate any
> > connection from the fw machine, so I added:
> >
> >  iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1
> >
> > This works for 99% of the traffic sourced on the firewall machine, it seems.
> >
> > One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
> > packets that are generated by the REJECT target.  These get sourced from the
> > unroutable address, and since my ISP wisely filters things like that, the
> > ICMP never makes it to the sender.
> 
> If I understand your setup and the problem correctly, you mean that you
> REJECT requests targeted to the firewall itself and the reject packets
> contain the private address of the firewall as source address.
> 
> But how packets can reach the private address of your firewall?

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.

Is there any way around this?

	-T

Re: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Jozsef Kadlecsik]

On Fri, 11 Apr 2003, Taner Halicioglu wrote:

> > > I soon realised that since I'm using a non-routed address for the "outside"
> > > interface of the firewall, I run into issues trying to initiate any
> > > connection from the fw machine, so I added:
> > >
> > >  iptables -t nat -A POSTROUTING -o eth1 -s 10.1.1.1 -j SNAT --to-source 200.1.1.1
> > >
> > > This works for 99% of the traffic sourced on the firewall machine, it seems.
> > >
> > > One thing it DOES NOT work for, is the ICMP (and probably RST - didn't try)
> > > packets that are generated by the REJECT target.  These get sourced from the
> > > unroutable address, and since my ISP wisely filters things like that, the
> > > ICMP never makes it to the sender.
> >
> > If I understand your setup and the problem correctly, you mean that you
> > REJECT requests targeted to the firewall itself and the reject packets
> > contain the private address of the firewall as source address.
> >
> > But how packets can reach the private address of your firewall?
>
> 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.

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.

Which one is true? Both cannot be.

Show me the tcpdump of both the packets rejected and the reject packets
generated.

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: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

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

Re: Bug? ICMPs sent by REJECT are not getting SNAT'd...

[Taner Halicioglu]

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