Pardon me if this is too often repeated but I'm not finding my answer.
My background: built the network for our local government (I'm the only IT guy) while learning. I got a CCNA while at it - so have some experience on command line - plus I administer some linux servers (web/email/file). Otherwise, a bit of a newb.
I'm moving from a watchguard to ASA5510. I configured the Watchguard without much problem, but cannot get the ASA right. What I'm trying to do:
Inside: has a few different subnets. I have a Cisco 3550 switch that has some ports set as routed for these different subnets (192.168.10.0, 10.10.3.0/24, 10.10.5.0/24, etc), then that switch is plugged into the main subnet switch (10.10.1.0/24). (I'm not using correct ip addresses). This all works with Watchguard.
DMZ: just the email/web server: one ip address for that server. No public ip address. Am using 10.10.2.0/24 network for that interface.
Outside: just connects directly to the ISP. Have static public ip address for that interface.
What I'm having trouble wrapping my head around is address pools/PAT. I've been reading various documentation that seems to give contradictory instruction. (must have a pool - can do it without a pool..)
Plus, I don't think I need NAT/PAT for local lan to translate to DMZ, would I? When I look at web/email logs, I like to see the local ip addresses that were accessing the services and see no need for NAT/PAT from Inside to DMZ, unless it is a big security risk I'm not aware of?
It seems like it should be easy, but I've tried several things and haven't been able to get outside from inside, or even ping the DMZ or outside interfaces. I tried setting up some access rules to allow that, but I'm ready to hit default settings and start over. (done that once or twice already). I did get it so outside could see our webserver.
What I'm looking for perhaps is just the NAT/PAT/static statements that should make it work, and a access rule or two - I can fill in the bulk if I can just get started. Or the best Cisco document link - I've looked at several examples and tried following them, but they all differed in significant ways.
ASA V. 7.0(4)12
ASDM V. 5.0(4)
Thanks for reading!! cheers, Jim
So first off for the ASA to get to all your inside networks you'll need some route statements as such:
route inside 192.168.10.0 255.255.255.0 10.10.1.x
route inside 10.10.3.0 255.255.255.0 10.10.1.x
route inside 10.10.5.0 255.255.255.0 10.10.1.x
where x is the IP address on the 3550 switch. Then if you want people on the inside to connect to the email/web server on the DMZ, without NAT, then do the following:
static (inside,dmz) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
static (inside,dmz) 10.10.3.0 10.10.3.0 netmask 255.255.255.0
static (inside,dmz) 10.10.5.0 10.10.5.0 netmask 255.255.255.0
static (inside,dmz) 10.10.1.0 10.10.1.0 netmask 255.255.255.0
This says that users on your 4 inside subnets will access the DMZ without being NAT'd (in reality they are NAT'd, but they're NAT'd to the same IP address).
Always remember that traffic flow from inside to dmz (and inside to outside, and dmz to outside) just needs some sort of nat statement, either a nat/global pair, or a static command. The above static commands will allow traffic to flow from inside to dmz freely.
Now, if you want these inside users to also get to the outside (Internet), then again, you need either a static or a nat/global pair between those two interfaces (the above statics are only for inside to dmz communication, NOT inside to outside). Since inside traffic has to be NAT'd to a global IP address when it goes outside, then you need to do PAT for this as such:
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
This says nat anything going FROM the inside TO the outside, to the interface IP address on the outside int. You don't have to have a pool of addresses, you can easily PAT everything to the one address as above.
Finally, if you want people on the outside to connect to your dmz web/email servers, then since that is considered "inbound" traffic (from a lower to higher security interface), you must have a static and an access-list. Something like the following will get you going:
access-list inbound permit tcp any interface outside eq 25
access-list inbound permit tcp any interface outside eq 80
access-list inbound permit tcp any interface outside eq 443
access-group inbound in interface outside
static (dmz,outside) tcp interface 25 10.10.2.x 25 netmask 255.255.255.255
static (dmz,outside) tcp interface 80 10.10.2.y 80 netmask 255.255.255.255
static (dmz,outside) tcp interface 443 10.10.2.y 443 netmask 255.255.255.255
This sets up static port translations for ports 25, 80 and 443 coming in on the outside IP address of the ASA. They will be translated through to your inside email and web server addresses on the dmz.
Also, be careful with testing all this with pings. The ASA does not by default open up holes to allow the return ICMP traffic, like it does with TCP/UDP based traffic. You should have a global inspection policy defined near the end of your config with a bunch of "inspect" statements in it, make sure you add "inspect icmp" to this, then the ASA will open up holes correctly and you should be able to ping through the device properly.
Hope that helps.
wow gfullage, you're an angel. I'll give these a shot and thanks for the ping info - hadn't read that yet in the manual.
Just tried another attempt earlier and outside sees the webserver fine but nothing yet from the inside - I get a:
Deny UDP src inside:10.10.1.3/4472 dst outside:x.x.x.x/53 by access-group "inside_access_in"
(as well as many other statements)
so that is our DNS server looking at ISP nameservers - so I haven't added a rule yet for that - maybe I'm closer than I think. I was using ASDM, but tomorrow given time will try it your way. Not being able to ping any interfaces made me think I was messed up - but given what you say - maybe I'm on the path. (I had created a rule for echo under security policy using icmp, but that didn't do it. I'll remove that.
I would ge rid of any inside ACL's, they just always seem to cause more trouble than they're worth and you will constantly be adding to it as people need to get to some other port/protocol on the dmz/outside. Unless you really think you need to limit what your inside users can connect to on the other interfaces, then don't have any ACL applied to the inside interface, that way all traffic from inside out is allowed by default.
Sorry to contradict, but I do recommend an outgoing ACL, to limit what your users can do and (hopefully) stop any trojan or backdoor stuff.
I've seen a site where someone hacked the mail server, then dragged the PIX to a halt by launching so many SSH port scans back out to the internet.
Once the PIX is in without an outgoing ACL, it's not easy to get one on. Get it on from day 1!
Thanks for that grant.maynard. I'll give that careful consideration - but first I want to get the unit working otherwise.
At this point, I'm able to browse our webserver from outside the network, I'm able to browse our webserver from the inside only by using the dmz subnet (our local dns server must point to the local dmz webserver ip address), but I cannot get from inside to outside.
Double checked the default gateway, the nat statements as given above and as entered, no inside access list, etc. Hopefully will find some time today to get some serious concentration in - yesterday was a crazy helpdesk type of day for me.
But if anything might be overlooked (by me) or missing from the setup given by gfullage above, please let me know.
cheers, and thanks again, Jim
this did the trick - I had made a small error or two and sorted 'em out - it works now.
So now I think I can sit back and go through more of the manual to try and fine tune things. I haven't gotten ping to work on the interfaces yet. I did this:
hostname(config)# class-map icmp-class
hostname(config-cmap)# match default-inspection-traffic
hostname(config)# policy-map icmp_policy
hostname(config-pmap)# class icmp-class
hostname(config-pmap-c)# inspect icmp
hostname(config)# service-policy icmp_policy interface outside
OK, a few more problems I haven't sorted yet. Hope you don't mind.
Our local DNS server 10.10.1.12 (fake) is being denied. Here's the message:
Deny inbound UDP from 10.10.1.12/53 to 10.10.10.13/1059 due to DNS response
Which prevents the subnets (happens with others such as the 192.168.1.0 network as well) from connecting to the outside internet.
The subnet 10.10.10.0/24 has a gateway of 10.10.1.1 (in the 3550 switch) and a static route saying such in the ASAfirewall. The 10.10.1.12/24 DNS server is on same network as inside interface on DNS server. So does this mean I need to set up ACL's anyway on the inside? I suppose that would mean I would have quite a list of permitted things from inside to inside interface, then I would also have to inclued inside to DMZ and to Outside as well?
I can try and understand all this when I get some time on the manuals but if someone spots a quick fix I would be most grateful.
This error message is the ASA dropping the DNS response from 10.10.10.13 to 10.10.1.12 as part of its DNS Guard feature. The DNS Guard says that there will be only one response to each query, so the ASA keeps track of all DNS requests and their matching responses. If a 2nd response comes back in for the same query, it is dropped.
This message is usually caused by the DNS server 10.10.10.13 being too slow to respond and the query has been answered by some other DNS server. It is not normally a cause of any problem because the query has already been responded to, the ASA is merely dropping all subsequent responses that it sees. ACL's will not resolve this, as it is not an access problem.
You need to fix up your DNS servers usually. It's still unclear what and where your DNS servers are, "10.10.1.12/24 DNS server is on same network as inside interface on DNS server" is difficult to understand at best. Plus how can the 10.10.10.0/24 network have a default gateway of 10.10.1.1, that's not right?
Sorry - hate it when I don't make sense. And thanks for your patience - I don't do this network admin enough to really understand it - I'm just the guy that was able to give it a try. If I can't sort this out via help such as yours, my own wits, etc - I will have to resort to flying someone in at about $600us plane ticket plus per diem/wages.
That statement "10.10.1.12/24 DNS server is on same network as inside interface on DNS server" should have ended "interface on ASA5510." Apologies.
I set up the DNS server on our lan for the purpose of resolving non-fully qualified domain names within our lan. Our ISP provides two nameservers for internet, but I think the lan DNS server (10.10.1.12) is also providing some of this? With DHCP, each host's dns is set for this local lan DNS server and it works.
In my current setup with the Watchguard, I have a router (not Cisco) that joins our 10.10.1.0/24 subnet up with the other subnets 10.10.10.0, 10.10.3.0, etc.On that router, if I point the DNS settings at the ISP nameservers, some hosts can't connect to our website, but can connect to other internet sites. If I point it at our local DNS server, they can connect to our website on the DMZ interface as well as internet.
That router plugs into a routed port on our Cisco 3550 switch. The 3550 also has a few more ports routing other networks/subnets. It's port 10.10.1.1 acts as gateway for these other networks/subnets and 10.10.1.1 plugs into a switch that has the inside interface of our firewall and the DNS server on it. Wish I could draw a picture.
One thing is for certain - the Watchguard (fairly old) is slowing things down a lot. I'm about to try setting up MRTG so don't yet have numbers, but when I do a download speedtest, by replacing the WG with the ASA, I get almost a 10 fold increase in speed. (So I am anxious to get the ASA deployed.)
I hope I was a bit more clear. Let me know which part you don't understand and I'll hopefully be able to clear it up. I really appreciate you guys' help.
I'll ponder my DNS setup, but if you have any suggestions, I'm all ears. cheers, Jim
I noticed I didn't answer the gateway question you asked previously. I wasn't clear before.
Maybe my topology will make more sense if I substitute x's for 10.10.
I have departments Bldg Maintenance on x.x.4.0/24, Emergency Services on x.x.5.0, and police on x.x.6.0. These plug into a router on inside interface x.x.6.1 which has an outside interface on x.x.10.13. This connects via a single wire over to City Hall into the 3550 switch/router on interface x.x.10.11. The 3550, on interface x.x.1.1 is the gateway for the x.x.10.0 subnet, as well as some other departments that plug in from other directions. That interface plugs into a switch on the City Hall x.x.1.0 subnet.
The local DNS server at City Hall is x.x.1.12. The inside interface of the ASA is x.x.1.20 (or whatever I may have said in previous messages.).
So you are saying that when that router at the police on x.x.10.13 is asking for DNS, then it is too slow and DNSGuard denies it. Or some other problem there. I'll study my DNS settings and see if anything jumps out. That router has primary and secondary DNS settings for its outside interface - and perhap's errantly I've put the x.x.1.12 DNS server as primary there and one of the ISP's as secondary. Both ISP nameservers cause these subnets from seeing our web/email server. Putting in the local DNS server fixes this. (With the WG, not with the ASA).
So that is pretty much it. It is hard to test the unit because the police are on pretty much 24/7 - but there's only a couple users there. I can pretty much test for short durations without too much anger.
I just tried another test and see that I get the same deny statement on segments connected directly to our 3550. (no other router between the 3550 and segment). Such our visitor center on x.x.3.0 plugs into a route-able port on the 3550.
If I do show run on the 3550, I have 3 name-servers configured: our local one and the two ISP nameservers. Perhaps I should remove the two ISP nameservers on the 3550 since our local DNS is handling internet connections as well.
I also made sure I cleared arp tables on the 3550 since the new ASA has the same inside IP address as the old WG.
: well, just tried it after removing all but the local dns server from the 3550. The visitor center is directly connected via the 3550. Two computers there - one worked and one wouldn't. The one that wouldn't couldn't even ping the dns server but could ping other hosts on that dns server subnet(segment?). I could ping the x.x.1.1 interface on the 3550, the x.x.1.20 inside interface of the ASA, but not the x.x.1.12 DNS server. Checked ipconfig on both computers and both the same. No host file or anything. ???? Hook the WG fw back up and everything is fine. I'm clueless.
Here's the deny statement for the failed ping from the .5.101 host:
Deny inbound icmp src inside:x.x.1.12 dst inside:x.x.5.101 (type 0, code 0)