> -----Original Message----- > From: Michael Bitow [mailto:mbitowat_private] > Sent: Tuesday, 8 February 2000 9:27 AM > To: 'firewall-wizardsat_private' > Subject: Cisco configuration question > > > Hi, > > I am currently working out a small problem that I can't > seem to get past. > I'm trying to get our mail server, an Exchange box, out of > the DMZ, and > behind a Cisco 3640. Right now, it looks like this: [text diagram of what looks like an elephant and two giraffes in sexual congress snipped] If it looks like _that_ no wonder you have problems! ;) > > One interface the Exchange and one on the 3640 have public > addresses, the > rest of the network is private. The problem I am having is > mail connections > were getting rejected . I had the router doing NAT, allowing all > connections. I figured I would tighten it up one I got it > working. The DSL > is a bridge only, no routing. Seems fair. > Is there a way to have the mail server behind the router > when doing NAT? Yep. > The > configuration I > tried was: Looks like you got most of the basic stuff right. I can't be sure what the exact problem is, but here are some comments: > > interface FastEthernet0/0 > description connected LAN > ip address 10.1.1.1 255.255.255.0 > no ip directed-broadcast > ip nat inside > > interface FastEthernet2/0 > description connected to Internet > ip address 1.2.3.4 255.255.255.0 > no ip directed-broadcast > ip nat outside > > ip nat inside source list 1 interface FastEthernet2/0 overload > ip classless > > ip route 0.0.0.0 0.0.0.0 FastEthernet2/0 This is probably going to cause you problems. When dealing with Ethernet interfaces, best practice is actually to point at another IP address as your default gateway. The problem is that with this config, the Cisco just drops the packet on the wire and hopes that there is a box on that segment that can do something smart with it. Sometimes this will work (the other box is prepared to answer ARP requests for the remote destination), but don't rely on it. Try: ip route 0.0.0.0 0.0.0.0 <ip address of your internet link> > ip route 10.1.1.0 255.255.255.0 10.1.1.1 This is redundant. Get rid of it. That network is directly connected, so creating a static route is not required. Cisco routers actually look at directly connected as more important than static, unless the static route is more specific, so this entry will probably be ignored anyway. > > access-list 1 permit 10.1.1.0 0.0.0.255 I normally use extended or named ACLs here, but yours should work. Named ACLs make the config easier to read: ip access-list extended NAT-these-hosts permit 10.1.1.0 0.0.0.255 any > access-list 101 permit tcp any 1.2.3.0 0.0.0.255 established > access-list 101 permit tcp any host 10.1.1.2 eq smtp This is not applied anywhere in the config snippet, so it's not doing anything. Which is not a problem - best to do all basic debugging with ACLs off anyway. You know that for an access list to work you need to apply it? This is done like this: interface fa2/0 ip access-group 101 in (check _incoming_ packets against access-list 101) Also, it's a good thing it's _not_ applied, because it won't do what you (probably) want, for a couple of reasons. Remember that once you NAT a packet, the response from the remote destination is going to come back to the IP address you NAT'ed to. In your case, 1.2.3.4 Access lists get checked BEFORE ANYTHING ELSE. Try this one: ip access-list extended incoming-filter permit tcp any host 1.2.3.4 established permit tcp any host 1.2.3.4 eq smtp permit udp any eq 53 host <ip address of your DNS server> permit udp any host <ip address of DNS server> eq 53 It's not the most secure. Some people like to firm up the DNS ACLs using reflexive access-lists or more specific IP addresses for permitted DNS responders. Exercise for the reader. ;) > Ultimately, I would like to use one outside address, have > all the traffic > go through the router, with the Exchange box behind the router. Oh, and make sure that the Exchange box is listening on port 25 for incoming connections. You never know. > > Any ideas on how I was mucking it up? Strictly speaking, this is OT, so please contact me or any other responders out of band for followup... > > Thanks > > Michael Bitow Cheers! -- Ben Nagy Network Consultant, CPM&S Group of Companies PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:03:02 PDT