Re: firewall problem continued

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 09 August 2004 11:39 am, Payal Rathod wrote:

> On Mon, Aug 09, 2004 at 09:32:13AM +0100, Antony Stone wrote:
> > I think you should specify the output interface in your MASQUERADE rules,
> > so that only packets going out of the Internet interface get SNATted -
> > otherwise packets going between your internal LAN and the DMZ are going
> > to get SNATted too, which is not really what you want.
>
> Does this look OK?
>
> -A POSTROUTING -s 192.168.0.0/255.255.0.0 -o eth2 -j MASQUERADE
> -A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth2 -j MASQUERADE

Yes (so long as eth2 is your external interace :)

> > This may be because you say you have a Squid proxy running on the
> > firewall itself.   If you were just doing standard HTTP, the ruleset you
> > have posted looks like you should have access to TCP dport 80 on the DMZ
> > from the LAN.
>
> Yes I do have squid running on firewall machine itself.
>
> > What URL are you using to access the mail server from the LAN?
>
> Direct IP. http://<public Ip>/mail

That is the problem then.

Squid is trying to connect to a public IP on the same box as Squid is running 
on, but that IP should be DNATted to a private IP somewhere else.

DNAT in PREROUTING only works for packets being routed through the machine.   
Squid is a local process sending packets out through OUTPUT, therefore you 
need to DNAT in the OUTPUT nat table to let Squid connect to this address.

> > There is a default ACCEPT policy, there are also some ACCEPT rules (and
> > no DROP rules), and the -m state rule is included twice....
>
> People here suggested to me that default ACCEPT policy was OK.

Yes.   I wasn't saying default ACCEPT is wrong - I was simply saying that if 
you have a default ACCEPT, there's no point in having extra ACCEPT rules with 
no DROP rules (so the only thing that can possibly happen to any packet is to 
be ACCEPTed).

A simple ruleset is easier to understand and easier to maintain, so don't put 
in rules which will never do anything useful.

Regards,

Antony.

-- 
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

                                                     Please reply to the list;
                                                           please don't CC me.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux