doing prerouting/postrouting/output logfile problems

doing prerouting/postrouting/output logfile problems

[Sander Sneekes]

Hi,

I got a firewall (redhat 7.2/iptables) with behind it a couple of
servers running apache/mail etc.

Now i have 36 public ip's and for the outside it seems like the
server are running public ip's i do that as followed :

firewall
eth0 = x.x.x.x (public ip)
eth1 = 192.168.2.1 (internal ip)

webserver

eth0 = 192.168.2.2

 ${IPTABLES} -t nat -A PREROUTING -p tcp -d x.x.x.x --dport 80 -j DNAT
--to-destination 192.168.2.2
        
 ${IPTABLES} -t nat -A POSTROUTING -p tcp -d 192.168.2.2 --dport 80 -j
SNAT --to-source 192.168.2.1
        
 ${IPTABLES} -t nat -A OUTPUT -p tcp -d x.x.x.x --dport 80 -j DNAT
--to-destination 192.168.2.2

This work perfect people from the outside using x.x.x.x are getting a
nice website. And also people inside the network using x.x.x.x also
getting a nice site.

But now here is my problem because in the logfile's of the site I get
all entry's coming from 192.168.2.1 instead off when a client viset
our site their ip. How can i solve it.? 

I also use these lines for do mail traffic and I had some problems with
open Relaying. Also because 192.168.2.1 was allowed to mail.

thanks for you help.

Cheers
Sander

Re: doing prerouting/postrouting/output logfile problems

[Antony Stone]

On Monday 21 October 2002 2:57 pm, Sander Sneekes wrote:

> Hi,
>
> I got a firewall (redhat 7.2/iptables) with behind it a couple of
> servers running apache/mail etc.
>
> Now i have 36 public ip's and for the outside it seems like the
> server are running public ip's i do that as followed :

You have 36 public IPs ???   Seems like a very strange number - 32 I could 
understand, but 36 ?   Oh well....

> firewall
> eth0 = x.x.x.x (public ip)
> eth1 = 192.168.2.1 (internal ip)
>
> webserver
>
> eth0 = 192.168.2.2
>
>  ${IPTABLES} -t nat -A PREROUTING -p tcp -d x.x.x.x --dport 80 -j DNAT
> --to-destination 192.168.2.2

Looks good.   This will change the destination address of packets coming in 
to your public IP so they reach the internal privately-addressed server.

>  ${IPTABLES} -t nat -A POSTROUTING -p tcp -d 192.168.2.2 --dport 80 -j
> SNAT --to-source 192.168.2.1

Why are you doing this ?   This will destroy the source address on packets 
going to your internal server so everything looks like its coming from the 
Firewall.   Most strange.


>  ${IPTABLES} -t nat -A OUTPUT -p tcp -d x.x.x.x --dport 80 -j DNAT
> --to-destination 192.168.2.2

You do realise that the OUTPUT chain is only for packets originating on the 
Firewall itself ?   This rule will change the destination address of any 
packets created on the Firewall, going to the public IP, so that they go to 
the private IP instead.   Why not just send them to the private IP in the 
first place ?   This rule has nothing to do with packets being forwarded 
through the Firewall.

> This work perfect people from the outside using x.x.x.x are getting a
> nice website. And also people inside the network using x.x.x.x also
> getting a nice site.

Ah.   That explains then why you are having to do the SNAT....

> But now here is my problem because in the logfile's of the site I get
> all entry's coming from 192.168.2.1 instead off when a client viset
> our site their ip. How can i solve it.?

If you remove the SNAT rule from the POSTROUTING chain you will get correct 
entries in your webserver logfile.   However this will then break your 
internal clients being able to access the public IP of the webserver (because 
the reply will come back from the private IP and the client will not be 
happy).

I suggest you modify the SNAT rule so that it only applies to packets from 
your local network:

${IPTABLES} -t nat -A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.2 
--dport 80 -j SNAT --to-source 192.168.2.1

The you will see correct public IPs in your webserver logifle for extenal 
visitors, and 192.168.2.1 for all internal accesses - presumably you'd be 
happy with this ?

> I also use these lines for do mail traffic and I had some problems with
> open Relaying.

Open Relaying is (a) a very bad thing to do, (b) nothing to do with netfilter 
rules, and (c) quite likely to get your mail server blocked by various 
anti-spam databases.   I suggest you correct your mail server configuration 
file so that it is not an open relay.

> Also because 192.168.2.1 was allowed to mail.

Not sure what you mean by this, but I expect once you've sorted out the Open 
Relay problem this will go away too.

Antony.

-- 

Perfection in design is achieved not when there is nothing left to add,
but rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

Re: doing prerouting/postrouting/output logfile problems

[Sander Sneekes]

Antony,

You were right i have 32 public ip. I think was not watching
my typing very well.

is working perfect know by changing the things you sayed

thanks for the help.

Cheers
Sander



----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 21, 2002 5:09 PM
Subject: Re: doing prerouting/postrouting/output logfile problems


> On Monday 21 October 2002 2:57 pm, Sander Sneekes wrote:
>
> > Hi,
> >
> > I got a firewall (redhat 7.2/iptables) with behind it a couple of
> > servers running apache/mail etc.
> >
> > Now i have 36 public ip's and for the outside it seems like the
> > server are running public ip's i do that as followed :
>
> You have 36 public IPs ???   Seems like a very strange number - 32 I could
> understand, but 36 ?   Oh well....
>
> > firewall
> > eth0 = x.x.x.x (public ip)
> > eth1 = 192.168.2.1 (internal ip)
> >
> > webserver
> >
> > eth0 = 192.168.2.2
> >
> >  ${IPTABLES} -t nat -A PREROUTING -p tcp -d x.x.x.x --dport 80 -j DNAT
> > --to-destination 192.168.2.2
>
> Looks good.   This will change the destination address of packets coming
in
> to your public IP so they reach the internal privately-addressed server.
>
> >  ${IPTABLES} -t nat -A POSTROUTING -p tcp -d 192.168.2.2 --dport 80 -j
> > SNAT --to-source 192.168.2.1
>
> Why are you doing this ?   This will destroy the source address on packets
> going to your internal server so everything looks like its coming from the
> Firewall.   Most strange.
>
>
> >  ${IPTABLES} -t nat -A OUTPUT -p tcp -d x.x.x.x --dport 80 -j DNAT
> > --to-destination 192.168.2.2
>
> You do realise that the OUTPUT chain is only for packets originating on
the
> Firewall itself ?   This rule will change the destination address of any
> packets created on the Firewall, going to the public IP, so that they go
to
> the private IP instead.   Why not just send them to the private IP in the
> first place ?   This rule has nothing to do with packets being forwarded
> through the Firewall.
>
> > This work perfect people from the outside using x.x.x.x are getting a
> > nice website. And also people inside the network using x.x.x.x also
> > getting a nice site.
>
> Ah.   That explains then why you are having to do the SNAT....
>
> > But now here is my problem because in the logfile's of the site I get
> > all entry's coming from 192.168.2.1 instead off when a client viset
> > our site their ip. How can i solve it.?
>
> If you remove the SNAT rule from the POSTROUTING chain you will get
correct
> entries in your webserver logfile.   However this will then break your
> internal clients being able to access the public IP of the webserver
(because
> the reply will come back from the private IP and the client will not be
> happy).
>
> I suggest you modify the SNAT rule so that it only applies to packets from
> your local network:
>
> ${IPTABLES} -t nat -A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.2
> --dport 80 -j SNAT --to-source 192.168.2.1
>
> The you will see correct public IPs in your webserver logifle for extenal
> visitors, and 192.168.2.1 for all internal accesses - presumably you'd be
> happy with this ?
>
> > I also use these lines for do mail traffic and I had some problems with
> > open Relaying.
>
> Open Relaying is (a) a very bad thing to do, (b) nothing to do with
netfilter
> rules, and (c) quite likely to get your mail server blocked by various
> anti-spam databases.   I suggest you correct your mail server
configuration
> file so that it is not an open relay.
>
> > Also because 192.168.2.1 was allowed to mail.
>
> Not sure what you mean by this, but I expect once you've sorted out the
Open
> Relay problem this will go away too.
>
> Antony.
>
> --
>
> Perfection in design is achieved not when there is nothing left to add,
> but rather when there is nothing left to take away.
>
>  - Antoine de Saint-Exupery
>
>

Re: doing prerouting/postrouting/output logfile problems

[Alistair Tonner]

> > firewall
> > eth0 = x.x.x.x (public ip)
> > eth1 = 192.168.2.1 (internal ip)
> >
> > webserver
> >
> > eth0 = 192.168.2.2
> >
> >  ${IPTABLES} -t nat -A PREROUTING -p tcp -d x.x.x.x --dport 80 -j
> DNAT
> > --to-destination 192.168.2.2
> 
> 
> >  ${IPTABLES} -t nat -A POSTROUTING -p tcp -d 192.168.2.2 --dport 80
> -j
> > SNAT --to-source 192.168.2.1
> 
> >  ${IPTABLES} -t nat -A OUTPUT -p tcp -d x.x.x.x --dport 80 -j DNAT
> > --to-destination 192.168.2.2
> 
> If you remove the SNAT rule from the POSTROUTING chain you will get
> correct
> entries in your webserver logfile.   However this will then break your
> 
> internal clients being able to access the public IP of the webserver
> (because
> the reply will come back from the private IP and the client will not
> be
> happy).
> 
> I suggest you modify the SNAT rule so that it only applies to packets
> from
> your local network:
> 
> ${IPTABLES} -t nat -A POSTROUTING -p tcp -s 192.168.2.0/24 -d
> 192.168.2.2
> --dport 80 -j SNAT --to-source 192.168.2.1
> 
> The you will see correct public IPs in your webserver logifle for
> extenal
> visitors, and 192.168.2.1 for all internal accesses - presumably you'd
> be
> happy with this ?
> 
> > I also use these lines for do mail traffic and I had some problems
> with
> > open Relaying.
> 
> Open Relaying is (a) a very bad thing to do, (b) nothing to do with
> netfilter
> rules, and (c) quite likely to get your mail server blocked by various
> 
> anti-spam databases.   I suggest you correct your mail server
> configuration
> file so that it is not an open relay.
> 
> > Also because 192.168.2.1 was allowed to mail.

	Presumably he was SNATting all packets originally... if he 
happened to be
	SNATting stuff through port25, the mailserver wouldn't know to 
block mail
	from outside.... since ... everything looked like it was inside 
... or at least
	the firewall...
	 
	Alistair