On 03/01/2008, at 3:34 PM, Robert Moskowitz wrote:
Christopher Chan wrote:
I spent much of the past 24 hours trying to find out how to set up
iptables for firewall routing WITHOUT NATing. Could not find
anything.
Eh? You just need to enable ip forwarding to enable routing. After
that, it is put up the firewall rules as is necessary, build the
appropriate routing tables on the firewall box and the boxes on the
intranet(s).
iptables does not handle routing.
No, but iptables controls what is allowed to route,
I think this is where you are getting confused and causing yourself
issues. iptables has ZERO effect on what is allowed to route. It is a
simple YES or NO as to if it should be allowed to pass or be filtered.
or it seems when you read the tutorials on iptables. I know about
routing, Comer taught me, and I reviewed Stevens book. I know about
firewalls; Belovin and I go back quite a ways. But configuring
software to do what **I** want, well that is were the car hits the
brick wall. As Belovin would say, "Here be Dragons."
Those little words, "put up the firewall rules as necessary" are
equivalent to "and magic happens here."
It's actually not magical at all... Work with the mindset of "I want
to allow X, Y, and Z, then deny everything else". This translates
easily into iptables rules -j ACCEPT and then your last rule (or
policy) should be a deny/drop/reject.
I tried it. I had everything open. Then I blocked everything. Then I
set up a rule to allow SSH in to eth0 and out eth1 (and the other
way). At least I thought that was what the rules said, but no SSH
connectivity through the firewall. That was when I realized that I
had not found the necessary incantation, and I had already shot most
of tuesday.
Again, you are using the wrong mindset here... You rule would
translate to:
iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
iptables -A FORWARD -i eth0 -d my.ssh.server.ip.here -p tcp -m state --
state NEW -m tcp --dport 22 -j ACCEPT
iptables -A FORWARD -j DROP
This allows you to put PER HOST restrictions on what you want to do.
If you want to do it on a per interface basis, then you will have the
same rules for every host in your subnet. Easy, but not ideal.
To break down that rule into bitesized chunks for learning:
-A FORWARD = adds this rule to the forwarding chain - as this will
pass through us.
-i eth0 = if the traffic comes in on eth0
-d my.ssh.server.ip.here = the destination of where the traffic will
end up
-p tcp = this rule only applies to the tcp protocol
-m state --state NEW = We'll allow the SYN packet so that the rest
will be accepted by a RELATED,ESTABLISHED rule.
-m tcp = part of the stateful matching off the top of my head
--dport = this rule only applies to things heading to port 22 (our
earlier TCP flag will make sure we only act on tcp/22 traffic).
-j ACCEPT = allow the traffic to pass.
As an exercise for the reader, write down a rule that would accept
traffic from eth0, and destined for a web server on 1.2.3.4. You
should notice that the rules will be pretty much identical. You would
insert this rule somewhere after the related/established, and
somewhere before the -j DROP rule.
Now keep in mind that iptables is a VERY simple beast and will apply
the first rule that matches! Consider the following:
iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
iptables -A FORWARD -i eth0 -p tcp -d 1.2.3.4 -m state --state NEW -m
tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 22 -j DROP
What would happen here, is that an incoming request for ssh to 1.2.3.4
would be accepted by rule #2, but the rule inspection would never make
it to rule #3 to be dropped - so take care in the ordering of your
rules.
Up and running. I can understand what shorewall rules are saying.
And I can see the results.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
--
Steven Haigh
Email: netwiz@xxxxxxxxx
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
