Re Ray,
Have you been doing your homework? Check out http://netfilter.samba.org
I have read all the docs there, compiled my own firewall script (several times) and it is now 250 lines (with comments).
<Foot in mouth> Excuse me, please.
I'm trying to setup my network as follows:
+----------------+ | Internet | +-------+--------+ | +-------+--------+ | | DMZ +----------------+ | Firewall +-----+ 192.168.1.0/24 | | | +----------------+ +-------+--------+ | +-------+--------+ | 10.0.0.0/24 | <- Internal network +-------+--------+ | +-------+--------+ | LAN Users | +----------------+
Here's the situation:
In the DMZ there are web servers that need to be browsed from the internet for ftp, http, tomcat (21,80,8080)
You need to configure destination NAT to do that. See
http://netfilter.samba.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc- 6.
html. For the FTP control channel, HTTP and TCP 8080 you need:
iptables -t nat -A PREROUTING -p tcp --dport 21 -i <outside interface> -j DNAT --to 192.168.1.<FTP> iptables -t nat -A PREROUTING -p tcp --dport 80 -i <outside interface> -j DNAT --to 192.168.1.<HTTP> iptables -t nat -A PREROUTING -p tcp --dport 8080 -i <outside interface> -j DNAT --to 192.168.1.<Tomcat>
Done.
You need to load the ip_nat_ftp.o module, which should automagically take care of the FTP data channels.
Done.
Furthermore, you need to set up forwarding and perhaps postrouting rules to allow (at least) the above (and block anything you don't allow). Note that you'll need to allow for some other traffic as well, such as DNS and some ICMP, unless you want to take your network down. Don't open up the filter too much, though. Hey, who ever said that firewalling was easy?
Uhuh, the POSTROUTING is what was missing. The web servers and ftp were trying to reply directly to the clients, instead of via the firewall.
Hmm, no, that's OK of them. They need to have the firewall as their default gateway (and no other routing, except local, perhaps not even that, but then all the host routes quickly become a hassle) and should send anything that's not destined to the subnet directly attached to the firewall. I meant that you need to *allow* post-routing. I ran into that trap a while back, went and configured default deny's on all chains and nothing passed the firewall. It took a while until I discovered that the order of traversal is PREROUTING -> FORWARD -> POSTROUTING. Could be that INPUT and OUTPUT come into play as soon as DNAT or SNAT are used, I don't remember exactly. Anyhow, my default deny on pre- and postrouting was killing all packets traversing the 'firewall', even those that weren't supposed to be NATted.
In the Internal Network there is a mail server with a private ip of 10.0.0.3 that needs to accept pop3 and smtp from the internet and send smtp to the internet.
Ugh.. Why not put a mail-relay host into the DMZ, if you've got one already?
Umm... do I need a smtp and pop3 'proxy' on the firewall to do that?
No, they're in the DMZ. You don't need two boxes for that, either, they're just two logically distinct components, though separation does have security merits. You should put a Web proxy for the internal users in a DMZ as well, IMHO. I try to do all firewalling I can with Application Layer Gateways (ALG), they give you the greatest amount of control, and often more security than packet filters, stateful or not.
The internal network must be able to browse, ftp via a transparent proxy on the firewall.
Ugh, why make the proxy transparent? I have a definite dislike for any attempts at transparent proxying, they're bound to fail, since only 95% of the web sites out there listen on port 80. That's no problem with an explicit proxy, but muchos problemas with a transparent one.
The transparent proxy is just a convenience for the (l)users who don't know what a proxy is. Most users will be configured with fixed proxy settings or via a proxy config script from a web server.
So use that and set up a web proxy in a DMZ, perhaps using a different physical network than the one you've already got for public access. I like to separate DMZs for inbound, public access and those for outbound, private use, since the public access DMZ is much more prone to attack and break-in. Coming back to the proxy transparency issue, your lusers will immediately notice when they haven't got the proxy configured, as they simply won't be able to surf the web. Then you tell them to set the proxy thingy to automagic and it works. You write up a simple three-page document with screen shots detailing the process. And you set the proxy settings in every new machine that is set up.
Well, what's the specific problem?
I have issues when the mail server tries to send out smtp messages (maybe due to the DNAT / SNAT stuff above)
* Does it resolve the MX record of the destination host and its IP address or the mail forwarder's IP address correctly? * Does it know to send packets to those computers to the firewall (i.e. is routing configured OK)? * Does the firewall handle them correctly, i.e. does it pass them and are they source NATted to its outside address? * Does the target host exist and is it up?
I also have issues with the POP3 clients authentication with the mail server.
What sort of issues? Can they connect at all? Do you see the TCP three-way-handshake being established if you run tcpdump on the firewall? If so, the firewall is not the problem. Cheers, Tobias