Hi Everyone, I've come across something very odd in my lab setup. I'm setting up a ASA frontend and ISA backend (using Back Firewall Template). The setup looks like this:
Internet | | NAT | ASA | 192.168.1.1 | 192.168.1.x | | | 192.168.1.100 ISA | 192.168.2.1 | 192.168.2.x | | | 192.168.2.2 PC
I've allowed HTTPS & HTTP to External from Internal, and going out via SecureNAT for now. I set the PC for the ISA as the Default Gateway, and set ISA to ROUTE to ASA. But for some reason that doesn't work. So I tried NAT from ISA to ASA, and for some reason that works. I thought if I'm going from Private to Private that I should ROUTE.
Did I set this up incorrectly? Why does NAT work and ROUTE doesn't. I just find it kind of weird doing a double NAT.
From: New Jersey
I just finished creating a front/back ISA config in my lab, with a private address perimeter. I'm using a Route relationship on the Back ISA, and NAT on the front. There's no (obvious) reason that it won't work.
Can you put a computer in the perimeter for testing? Can you get from Perimeter to External via ASA from that system? Can you ping the test system from the PC (enable a Ping rule on ISA) when you're in Route mode?
Oh - and - very important... Is the ASA aware of the networks behind the ISA, and is it routing to them via the ISA??? In NAT mode, the ASA simply replies to the ISA, which is directly connected. In Route mode, the ASA needs to know that it must forward packets to the ISA for any host BEHIND the ISA.
From: United Kingdom
I agree with Glenn, the normal missing element is adding route statements to send internal traffic back through the ISA as the incoming gateway for ASA.
I don;t think there is anything wrong with double NAT-ing but with this configuration you will never see the "real" IP address behind ISA which can sometimes be handy for controlling outbound access at the ASA for unique internal hosts.
You may also need to add static NAT entries on the ASA to make sure traffic destined for the internet has a valid return route.
Glenn, After reading your posts, I did put a switch between ASA and ISA, and attached a test Linux box. I allowed PING and TELNET from Internal to External on ISA. When PING or TELNET the IP address of the Linux box, ROUTE for some reason doesn't work, but NAT does. I don't know what I missed, but I know I'm not hitting the ASA to get to the Linux box. Any ideas on this?
Just for my information as I'm really not quite sure how this works, but with ROUTE what needs to be configured on ISA and ASA (both incoming and outgoing) in order for PCs behind ISA to access the Internet and the DMZ segment on ASA, where I want to use web proxy or firewall client on ISA to control outgoing access to these networks. Also, I want to have reverse-proxy to Exchange for OWA on ISA. Will ROUTE still make this possible.
From: New Jersey
Here's a few tests to perform to verify/validate your configuration. They assume that your test system is still in the perimeter. For the purpose of discussion, we'll refer to the Perimeter Host as "PH" with an IP address of 192.168.1.200. We'll also refer to an Iinternal Host as "IH" with an IP of 192.168.2.2. It also assumes that your ISA server is configured to permit Ping from anywhere to anywhere for this test.
From ASA: Ping an Internet address - should succeed because the ASA's default route is to the internet. Ping PH - should respond because the host is on a directly connected network, regardless of the DG setting in PH. Ping ISA (1.100) - should respond for the same reason as above. Ping IH. If it fails, it could be due to the fact that ASA is unaware of the 2.x network. You'll need a route statement similar to route add 192.168.2.0 mask 255.255.255.0 192.168.1.100 This will tell the ASA to forward packets for the 2.0 network to the ISA interface. My IOS skills are rusty, so translate the route statement accordingly. ;)
From PH PH should use the ASA as its Default Gateway. It will need the same route as above, so packets for the internal network are forwarded to the ISA directly. Without the route, packets will be forwarded to ASA, which should forward them based on its routing table to the ISA, resulting in an extra hop. Works, but inelegant. Ping ASA and ISA (1.100) - both should succeed because they are directly connected. Ping an internet addres - should succeed if ASA permits it and the gateway is correctly pointing to the ASA. Ping IH - should succeed if the route is defined properly, otherwise will fail. NOTE - if this test fails, check the ISA logs to be sure it is not blocking pings. If you see Denied messages in ISA, the routing is correct, and ISA rules are preventing the ping.
From ISA Since ISA is directly connected to every network, and (I assume) uses the ASA as its default gateway, it should be able to ping ASA, PH, IH, and an internet host without issue.
From IH Ping ISA (2.1) - succeeds because it is directly connected Ping PH - should succeed because ISA is the DG for this host, and ISA is directly connected to PH's network. Ping ASA - should succeed if the ASA knows the route back to the internal network. Ping internet host - same expected result as above.
I'm pretty sure that the issue is simply that the ASA is not "aware" of the network on the other side of the ISA. Once you verify/add the route to the ASA to forward the 192.168.2.0 network to the ISA, you should be fine.
This is a classic "network behind network" issue discussed several times on this site.
Hi Glenn, What you provided makes sense. Therefore, I created a static route like you said using "route add" for 192.168.1.0/24 192.168.2.1. Do I create static route for 192.168.2.0/24 192.168.1.100 on the External Interface?
After creating the static route I finally see the traffic hitting the ISA firewall, but I'm getting denied PING to the LINUX box sitting on the 192.168.1.x network. I do have a firewall rule that's allowing PING from Internal to External for All Users. I remember seeing a post where someone was experiencing the same thing. They didn't get a resolution. Do you know what could be causing the problem?
Created backend firewall using Back Firewall Template, set Internal using the Internal NIC (192.168.2.0-192.168.2.255), and set it using Block All.
Created an Access Policy Rule (PING - Int to Ext) to PING (PING, ICMP Information Request, ICMP Timestamp) from Internal to External for All Users, 24x7.
ISA can ping itself, the 192.168.2.2 PC, the 192.168.1.50 Linux box, and the ASA NIC (192.168.1.1).
Tried to PING from 192.168.2.2 PC to 192.168.1.50 Linux box, I get request time out. I can PING the ISA External NIC 192.168.1.100 from the 192.168.2.2 PC, though. The weird thing is that I can PING the Internal NIC of the ASA with a response. Also, I can also PING the IP Address for Google.com (22.214.171.124), and I do get a response.
The Logging shows that the rule PING - Int to Ext has initiated the connection with Result Code 0x0 ERROR_SUCCESS, then later 0x80074e20 FWX_E_GRACEFUL_SHUTDOWN. Doesn't show any deny messages.
Any idea why I cannot PING the Linux box, but can PING ASA and the Internet? Is this problem outside of ISA (e.g. routing tables)? The Event Logs don't show anything.
From: New Jersey
None of your systems need two route statements. Your ASA needs one route statement to know to forward packets for the network behind the ISA to the ISA. The route to the 192.168.1 network is not needed (and is improperly defined) because the ASA is directly connected to that network. The Linux system does not NEED a route if it uses the ASA as it's default gateway, however, it would be more efficient to make it aware of the back network as well - same route statement as the ASA. You should only see the difference in a traceroute. The ISA is directly connected to all subnets and does not need any static routes.
Please, for my sanity (especially in my pre-caffienated state), describe your tests as "Ping HOST from HOST: pass/fail". Also, referencing the hosts by name lets us quickly identify where it is without having to keep referring to a chart of your network - "PHOST" tells me immediately that it's a perimeter host. :)
So - brass tacks..
Clear any static routes you added.
Add a route on the ASA: 192.168.2.0/24 192.168.1.100
Insure the PHOST uses ASA as its gateway - add a static route just like the one above so it reaches the internal network efficiently.
Run through the tests I outlined earlier and report the results of each ping test. Be sure to identify the source/destination so there's no ambiguity.
From: New Jersey
That's what we've been saying all along. The purpose of the exercise being discussed was to illustrate to the O.P. how the routes work and to better understand fundamental troubleshooting process.
In the middle of all this was the addition of a computer in the perimeter. The second route could go on that machine so it doesn't have to bounce off of the ASA to go inside, but this isn't a strict requirement.
From: United Kingdom
Why exactly should we be using NAT on ISA as opposed to routing?
By hiding everything behind ISA's external interface we lose any ability to configure ASA ACLs based upon original host source IP address.
IMHO a route relationship provides the most secure solution as it exposes control for both ISA *AND* ASA which means both tiers of the model are able to filter traffic properly. A good example here is if the ASA is ever used for site-to-site VPN termination and we require ACLs for the VPN.
I am not sure we should be using NAT just because it is easier to configure...
< Message edited by Jason Jones -- 19.Jun.2008 5:56:46 AM >
From: Taylorville, IL
I admit I have never considered using a routing relationship on the back side of a back-to-back DMZ and would have always thought of it as a bad thing. But what you are saying makes sense, I never thought of it like that.
Hi Jason, Good to see you again. Although I would like that ROUTE approach too, for some reason I'm having a difficult time using it. When the network set to NAT everything works. I've setup the ISA and ASA according to what Glenn proposed, but I'm still having trouble pinging the Perimeter Host (PH - Linux box), and vice versa if ROUTE is supposed to be bidirectional.
Maybe I have setup the Network wrong. I changed the default Internet network rule from NAT to ROUTE for Internal/VPN Client/Quarantine to External. Is this correct? Should I have left this as NAT and created another Network rule to ROUTE to the perimeter?