firewall problem continued
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
Quoted 4 lines · 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
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.
Quoted 4 lines
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.
Quoted 2 lines
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?
Quoted 6 lines
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.
Signature · 10 lines
"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.Quoted 4 lines · Antony Stone
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
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 1 line
What Squid access controls do you have?
Nothing much, it is very simple.
acl designs src 192.168.0.0/255.255.0.0http_access allow designs
Quoted 1 line
What URL are you using to access the mail server from the LAN?
Direct IP. http://<public Ip>/mail
Quoted 2 lines
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
Review
Quoted 10 lines · Payal Rathod
Quoted 4 lines · Antony Stone
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?
(quoted diff) +0
-2-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 :)
Quoted 10 lines
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
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.
Signature · 7 lines
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.Quoted 4 lines · Antony Stone
Review
Quoted 2 lines
(quoted diff) +0
-2-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 MASQUERADEYes (so long as eth2 is your external interace :)
Yes.
Quoted 3 lines
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
Quoted 9 lines · Payal Rathod
Quoted 4 lines · Antony Stone
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.
Signature · 8 lines
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.Quoted 4 lines · Antony Stone
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
Quoted 4 lines · Antony Stone
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
Quoted 10 lines · Payal Rathod
Quoted 5 lines · Antony Stone
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.
Signature · 7 lines
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.Quoted 1 line · Antony Stone
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?
Quoted 4 lines
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
Quoted 5 lines · Payal Rathod
Quoted 1 line · Antony Stone
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.
Quoted 1 line
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.
Quoted 6 lines
Quoted 4 lines
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.
Signature · 5 lines
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.Quoted 6 lines · Antony Stone
Quoted 2 lines
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
Quoted 10 lines · Payal Rathod
Quoted 6 lines · Antony Stone
Quoted 2 lines
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.
Signature · 5 lines
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.Quoted 6 lines · Antony Stone
Quoted 4 lines
Quoted 1 line
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