firewall problem continued

firewall problem continued

[Payal Rathod]

Hi,
I am rephrasing my last question with better words and more information.
My firewall config (simple) is kept at,
http://payal.staticky.com/tables.txt

My problem is simple I have a DMZ machine where mail server is hosted.
Its apache (needed for webmail) can be accessed from outside world by
http://<ext IP>. But if I give http://<ext IP> from a LAN machine I cannot
access it. Upon further investigation I found that port 25 and 110 can be
accessed from LAN but not from the gateway (firewall) machine. Therefore,
since this machine is also a simple squid proxy to LAN, I cannot access
webmail thru' LAN. Now, if someone can help me in access those services 
from the firewall machine itself, it will be great.
I have blocked access to port 80 -d 0/0 from LAN and allow access
only through squid.

If you need more information, do tell.

Waiting eagerly for any inputs.
With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

On Monday 09 August 2004 9:12 am, Payal Rathod wrote:

> Hi,
> I am rephrasing my last question with better words and more information.
> My firewall config (simple) is kept at,
> http://payal.staticky.com/tables.txt

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.

> My problem is simple I have a DMZ machine where mail server is hosted.
> Its apache (needed for webmail) can be accessed from outside world by
> http://<ext IP>. But if I give http://<ext IP> from a LAN machine I cannot
> access it.

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.

> Upon further investigation I found that port 25 and 110 can be
> accessed from LAN but not from the gateway (firewall) machine.

Why would you need to access 25/110 from the firewall?   Surely it isn't 
acting as a mail client?

> Therefore,
> since this machine is also a simple squid proxy to LAN, I cannot access
> webmail thru' LAN. Now, if someone can help me in access those services
> from the firewall machine itself, it will be great.
> I have blocked access to port 80 -d 0/0 from LAN and allow access
> only through squid.

What Squid access controls do you have?
What URL are you using to access the mail server from the LAN?
If it's a hostname, what IP does this resolve to when Squid tries to connect?

You seem to have a rather confused OUTPUT ruleset, by the way.

There is a default ACCEPT policy, there are also some ACCEPT rules (and no 
DROP rules), and the -m state rule is included twice....

You also have the -m state rule duplicated in your INPUT and FORWARD rulesets.

Regards,

Antony.

-- 
"Note: Windows 98, Windows 98SE and Windows 95 are not affected by [MS
Blaster].   However, these products are no longer supported.   Users of these
products are strongly encouraged to upgrade to later versions."

(which *are* affected by MS Blaster...)

http://www.microsoft.com/security/security_bulletins/ms03-026.asp

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

Re: firewall problem continued

[Payal Rathod]

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

> 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.

> Why would you need to access 25/110 from the firewall?   Surely it isn't 
> acting as a mail client?

Right now I will keep it as they are if they are not harming much. I will
remove them a bit later.

> What Squid access controls do you have?

Nothing much, it is very simple.
acl designs src 192.168.0.0/255.255.0.0
http_access allow designs

> What URL are you using to access the mail server from the LAN?

Direct IP. http://<public Ip>/mail

> 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.
As I said earlier, I am unable to access DMZ's external IP from the
firewall machine. If I try 
telnet <external IP of DMZ> 80
I cannot reach it,
But I can reach the same with,
telnet 10.10.10.2 80

What do you think the problem is?
Thanks a lot for the help.

With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

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.

Re: firewall problem continued

[Payal Rathod]

On Mon, Aug 09, 2004 at 11:55:10AM +0100, Antony Stone wrote:
> > -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 :)

Yes.

> 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.

Ok. I never knew that. Can you please give an small example on how to
DNAT my scene in OUTPUT nat table ?

Eagerly watiing for inputs on this.
With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

On Monday 09 August 2004 12:19 pm, Payal Rathod wrote:

> On Mon, Aug 09, 2004 at 11:55:10AM +0100, Antony Stone wrote:
>
> > 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.
>
> Ok. I never knew that. Can you please give an small example on how to
> DNAT my scene in OUTPUT nat table ?

Exactly the same as your extisting PREROUTING rule, but you put it in the 
OUTPUT chain instead (still in the nat table):

iptables -A OUTPUT -t nat -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to 10.10.10.2 

Regards,

Antony.

-- 
You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.

 - Frank Skinner

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

Re: firewall problem continued

[Payal Rathod]

On Mon, Aug 09, 2004 at 12:31:33PM +0100, Antony Stone wrote:
> Exactly the same as your extisting PREROUTING rule, but you put it in the 
> OUTPUT chain instead (still in the nat table):
> 
> iptables -A OUTPUT -t nat -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to 10.10.10.2 
I am at home sick. But I did it remotely and tested it. It works. Thanks a lot
Anthony and all who helped.
I thought -t nat was never used in output chain.

Thanks a lot again and I cannot wait to get back to work to test it throughly.

With warm regards,
-Payal

Re: firewall problem continued

[Payal Rathod]

On Mon, Aug 09, 2004 at 12:31:33PM +0100, Antony Stone wrote:
> Exactly the same as your extisting PREROUTING rule, but you put it in the 
> OUTPUT chain instead (still in the nat table):
> 
> iptables -A OUTPUT -t nat -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to 10.10.10.2 

As I said earlier that now I can access the mail server at 10.10.10.2
from the firewall machine using its external IP. But now I need to access the 
mailserver from the same machine itself using the external IP.
How do I do it?

Thanks a lot for the help in advance.
With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

On Tuesday 10 August 2004 9:14 am, Payal Rathod wrote:

> On Mon, Aug 09, 2004 at 12:31:33PM +0100, Antony Stone wrote:
> > Exactly the same as your extisting PREROUTING rule, but you put it in the
> > OUTPUT chain instead (still in the nat table):
> >
> > iptables -A OUTPUT -t nat -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to
> > 10.10.10.2
>
> As I said earlier that now I can access the mail server at 10.10.10.2
> from the firewall machine using its external IP. But now I need to access
> the mailserver from the same machine itself using the external IP.

Why does the mail server need to refer to itself using the public IP?

Why can't it know its own private IP?

As an additional comment, you appear to be digging yourself further and 
further into a situation of "I wouldn't do it like that, but if you really 
need to...."

You should be cautious about doing too many things one after another which are 
simply needed as workarounds for a strange network setup, or a non-ideal DNS 
setup, and sooner or later you need to stop adding workarounds and change the 
underlying design.

Regards,

Antony.

-- 
It is also possible that putting the birds in a laboratory setting 
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

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

Re: firewall problem continued

[Payal Rathod]

On Tue, Aug 10, 2004 at 09:26:33AM +0100, Antony Stone wrote:
> Why does the mail server need to refer to itself using the public IP?

No idea. I thought that is recommended. I mean every machine should
be able to access itself using all its IPs. But if you say so, I don't
mind.
Will the same rule apply even when I using it as a database or webserver?

> You should be cautious about doing too many things one after another which are 
> simply needed as workarounds for a strange network setup, or a non-ideal DNS 
> setup, and sooner or later you need to stop adding workarounds and change the 
> underlying design.

Are you saying my setup is broken? Should I change my whole design?

With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

On Tuesday 10 August 2004 9:43 am, Payal Rathod wrote:

> On Tue, Aug 10, 2004 at 09:26:33AM +0100, Antony Stone wrote:
> > Why does the mail server need to refer to itself using the public IP?
>
> No idea. I thought that is recommended. I mean every machine should
> be able to access itself using all its IPs.

That would mean "all IPs on all interfaces of the machine".   It doesn't 
include arbitrary IPs which some other machine may choose to translate to an 
IP on this machine's interface.

> Will the same rule apply even when I using it as a database or webserver?

If you can find a good reason why a machine needs to refer to itself using an 
IP which is not on one of its interfaces (ie: an address which gets 
translated elsewhere), then we can try to think of a way to enable that.

However, until the problem arises, don't worry about it.

> > You should be cautious about doing too many things one after another
> > which are simply needed as workarounds for a strange network setup, or a
> > non-ideal DNS setup, and sooner or later you need to stop adding
> > workarounds and change the underlying design.
>
> Are you saying my setup is broken? Should I change my whole design?

Since you do not apparently have a need for the mail server to reach itself on 
the public IP address, then no, the design may be perfectly okay.   I thought 
there was some need for this, which suggested to me that maybe it was the 
wrong way to go about doing it.

So long as the system is working as it is, however, the design is probably 
okay.

Regards,

Antony.

-- 
Normal people think "If it ain't broke, don't fix it".
Engineers think "If it ain't broke, it doesn't have enough features yet".

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

Re: firewall problem continued

[Payal Rathod]

On Tue, Aug 10, 2004 at 10:14:22AM +0100, Antony Stone wrote:
> > No idea. I thought that is recommended. I mean every machine should
> > be able to access itself using all its IPs.
> 
> That would mean "all IPs on all interfaces of the machine".   It doesn't 
> include arbitrary IPs which some other machine may choose to translate to an 
> IP on this machine's interface.

Let me rephrase it. A mail server needs to connect to any IP in the world
so why cannot it connect to an IP which is in its subnet.

Thanks a lot for the info.
With warm regards,
-Payal

Re: firewall problem continued

[Antony Stone]

On Tuesday 10 August 2004 12:46 pm, Payal Rathod wrote:

> On Tue, Aug 10, 2004 at 10:14:22AM +0100, Antony Stone wrote:
> > > No idea. I thought that is recommended. I mean every machine should
> > > be able to access itself using all its IPs.
> >
> > That would mean "all IPs on all interfaces of the machine".   It doesn't
> > include arbitrary IPs which some other machine may choose to translate to
> > an IP on this machine's interface.
>
> Let me rephrase it. A mail server needs to connect to any IP in the world
> so why cannot it connect to an IP which is in its subnet.

Because the public IP is not in its own subnet.

Your mail server's real address is 10.10.10.2, with a /8 netmask.

Its public IP (as far as the firewall is concerned) is 1.2.3.4.

Those are different subnets.

Regards,

Antony.

-- 
Never automate fully anything that does not have a manual override capability. 
Never design anything that cannot work under degraded conditions in emergency.

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

Re: firewall problem continued

[Payal Rathod]

On Tue, Aug 10, 2004 at 07:45:46PM +0100, Antony Stone wrote:
> > > an IP on this machine's interface.
> >
> > Let me rephrase it. A mail server needs to connect to any IP in the world
> > so why cannot it connect to an IP which is in its subnet.
> 
> Because the public IP is not in its own subnet.

Ok still the public IP is like a normal internet IP for it, right? If it can
connect to other IPs like that of yahoo.com, rediffmail.com  there seems to be no
reason why it shouldn't connect to this.

Thanks a lot for the help.
With warm regards,
-Payal