Results 1 to 4 of 4
Hi friends,
I have configured squid proxy server & shared th e internet connection to 10 systems.Out of 10 systems 4 pc's are developer machines.from their machines Mails are not ...
- 03-08-2010 #1Just Joined!
- Join Date
- May 2009
- Posts
- 1
Reg:Mails from localsystem not going outside
Hi friends,
I have configured squid proxy server & shared th e internet connection to 10 systems.Out of 10 systems 4 pc's are developer machines.from their machines Mails are not going outside from their localsystem.I have firewall enabled & iptables.Eventhough i have written rule to allow port 25,but it is not getting done.
Iptables file is shown below
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 3128 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 465 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 995 -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -i eth0 -j ACCEPT
Please check the file & help me in solving this problem.
Thanks in advance,
Satish.
- 03-08-2010 #2Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
How do you have sendmail configured?
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 03-10-2010 #3Banned
- Join Date
- Dec 2002
- Location
- Texas
- Posts
- 242
You are running SMTP services on their machines?
Which SMTP application are you using? Sendmail?
Do you see the email building up in a mail queue?
This is an entry that allows incoming SMTP connections.
It has nothing to do with the machine's ability to send
outgoing email. By default, outgoing ports are all open.
- 03-10-2010 #4
I'll let the other comment on the SMTP stuff. I'll just inform you about your firewall.
Since you did not post the complete /etc/sysconfig/iptables file I'm only going to assume things here. Bad idea I know.
If the top of the above file is as follows:
and these are all the rules in the file then your firewall is useless. Why? Because you are not dropping anything anywhere so everything is going to be allowed.Code:*filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0]
I, myself, do not like what RedHat is trying to do here and wish they would stop. It is not helpful to young sysadmins trying to learn linux using their system as most on-line information doesn't follow what RedHat is doing. But that is for another fight.
Case in point, your rules. You added INPUT rules instead of placing them into RH-Firewall-1-INPUT chain which is what the first INPUT rule point the firewall to. I would have to know what the whole file looks like to say one way or the other if these rules would work or not.
Rules are read from top to bottom and executed in the order they are placed. In other words if you have a rule that drops a connection before the rule that accepts the connection, the connection is never going to be allowed because the drop is seen first.
Lets take a look at the FORWARD rules.
Let say there is a connection coming in on port 23 (telnet) to one of the systems on the inside of your firewall.
Since this is for an inside system this packet is a FORWARD packet.
-A INPUT -j RH-Firewall-1-INPUT
doesn't match because it is an INPUT rule
-A FORWARD -j RH-Firewall-1-INPUT
Ah!! A match. Lets execute what it tells us to do
This rule tell the firewall to jump to the chain for RH-Firewall-1-INPUT.
So the firewall starts looking at the rules in RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
this doesn't match port 23 so it is skipped.
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
this is a new connection so this rule is skipped.
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 3128 -j ACCEPT
this is a new connection but the port 23 does not match this rule so it is skipped.
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 25 -j ACCEPT
this is a new connection but the port 23 does not match this rule so it is skipped.
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 465 -j ACCEPT
this is a new connection but the port 23 does not match this rule so it is skipped.
-A RH-Firewall-1-INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 995 -j ACCEPT
this is a new connection but the port 23 does not match this rule so it is skipped.
Now that the firewall has reached the end of the chain and nothing matched it returns to the point where it was told to jump to this chain
Since -A FORWARD -j RH-Firewall-1-INPUT was the starting point it now starts looking down at the rest of the rules looking for a match
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -i eth0 -j ACCEPT
This is a packet to be forwarded so this rule doesn't match.
Now that the firewall has reached the last rule it now defaults to what every the policy is for the function it is trying to preform so it looks at the policy for FORWARD and see
:FORWARD ACCEPT [0:0]
This rule matches so the packet is sent on it's way.
This is why I set my policies to DROP and at the end of every chain a '-j DROP' to ensure that I don't miss dropping everything I have not set to be allowed in. Would be nice if RH would do something simular with INPUT and FORWARD at least. I know they default to setting a rule to reject everything at the end of the RH-Firewall-1-INPUT chain but it only take one mistake and removing this line to open your system up to everyone.


Reply With Quote
