> I'm trying to configure a backup/replacement of a Sonicwall firewall > which sits between our company LAN and an ADSL router. We have been > allocated a range of IP addresses.... > > 212.107.213.9 (the adsl modem) > 212.107.213.10 (firewall WAN interface) > 212.107.213.11 (incoming email comes to this address) > 212.107.213.12 (DMZ - not used yet) > > We run MS Exchange on the LAN server (192.168.175.1) - there is a > 'one-to-one NAT' entry in the (old) firewall which lets incoming mail > through to the mail server (directs incoming traffic 212.107.213.11 >> > 192.168.175.1) > > I've sucessfully got the Dachstein LEAF Firewall (floppy disk) running > and browsing pages across a test network with the external and internal > interfaces set the same as the Sonicwall (213.107.212.10 and > 192.168.175.9 respectively). > > BUT, I'm struggling to find how I can set a rule which would direct > mail arriving at 212.107.213.11 to the mail server at 192.168.175.1. > > I've searched and read a fair bit, and this page sounds the most > promising.....? > http://sourceforge.net/docman/display_doc.php?docid=10418&group_id=13751 > > Can anyone tell me if I'm on the right track? I don't have alot of > experience with Linux or firewalls yet - any help would be appreciated.
You're on the right track. You first need to allow e-mail traffic through the firewall filters with the following: EXTERN_TCP_PORT0="0/0 smtp 212.107.213.11" Then, port-forward the traffic to your exchange server: INTERN_SERVERS="tcp_212.107.213.11_smtp_192.168.175.1_smtp" Of course, you also have to have the extra IP's assigned to the external interface for this to work: eth0_IP_EXTRA_ADDRS="212.107.213.11 212.107.213.12" Note you need to use the "enhanced" versions of port-forwarding and opening external ports (which let you specify an external IP), since you're not using the firewall's primary external IP address. ALTERNATIVES: With your network details, I'd probably setup either a static-NAT or proxy-arp (preferred) DMZ to make use of the extra IP addresses. This requires three NIC's in your firewall, and slightly different configuration (don't assign the extra IP's to eth0, and use the DMZ variables to control access to the DMZ systems...of course, you'd have to move your exchange box (or at least your in-bound mail RX) to the DMZ...see below). *WARNING* This is *NOT* exactly the same as the previous 'one-to-one NAT' entry provided by the sonicwall. A NAT entry essentially translates *ALL* traffic (tcp <any port>, udp <any port>, as well as all other protocols), while the above *ONLY* forwards TCP port 25 (smtp) traffic to the exchange box. IMHO, this is actually better, but be aware that there is a difference, in case anything breaks (ie you might need pop, imap, ident, or other traffic port-forwarded as well). *WARNING 2* I don't suggest running a publicly visible mail server (ESPECIALLY a M$ product) on your internal network. The general rule of thumb when running public servers, is to presume they WILL be compromised (even linux/unix boxes!), and to structure your network so that the compromised box can do the least amount of damage. That's the reasoning behind a DMZ network...your public servers live on the DMZ, so when they get hacked, there's still a firewall between the compromised system and your internal LAN. If at all possible, I would put the exchange server on the DMZ (could be tricky...M$ likes to design protocols that don't happily traverse routers and that can be next to impossible to firewall with a packet-filtering router w/o leaving security holes so big you might as well not have a firewall), or if you really need to keep the exchange box on your internal LAN, put an e-mail "proxy" on the DMZ (ie a mail server configured to just receive mail and forward it to the exchange box on the internal LAN...or better yet, have it store the e-mail, and get the exchange box to "pull" the mail off the DMZ box periodically, then a compromised mail server has *NO* access to your internal exchange box, limiting the worst-case damage of a ). NOTE: I'm not a M$ admin, and am extremely unfamiliar with exchange...you might want to check with some more Microsoft oriented folks about how to properly secure an exchange install, especially if you plan on leaving it connected to the internet and running on your internal LAN...the suggestions above are simply what I'd do with any server/service of questionable security. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
