09-25-2009 09:30 AM - edited 03-11-2019 09:19 AM
We have a switch in our DMZ at address 192.168.254.2. The DMZ interface of our ASA is 192.168.254.1. We use tacacs authentication on our network and the tacacs (CiscoSecureACS) server is located off of the Inside interface of the ASA at address 192.168.1.163. We need for the switch in the DMZ at 254.2 to authenticate using the tacacs server on the inside interface.
When I set up a capture on the DMZ interface of the ASA for the tacacs requests from the switch in the DMZ at 192.168.254.2, I see the requests from 254.2 bound for 192.168.1.163.
When I move the capture to the inside interface of the ASA, i never see the requests. Seems like the ASA is dropping them for some reason.
Their is a global PAT out of the DMZ. I also created a static (DMZ,inside) translation for the 192.168.254.2 address. So far none of this works.
Please help.
Solved! Go to Solution.
09-25-2009 09:42 AM
Try this..
static (inside,DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
You may also need to allow tacacs in an acl inbound on the dmz interface.
09-25-2009 09:42 AM
Try this..
static (inside,DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
You may also need to allow tacacs in an acl inbound on the dmz interface.
09-25-2009 10:14 AM
Your solution worked with respect to the static Xlate you provided. I actually saw this work then furthur qualified it so that the statement read "static (inside,DMZ) 192.168.1.163 192.168.1.163 netmask 255.255.255.255
What i dont understand is why I did not have to translate the 192.168.254.2 source address of the switch in the DMZ to the inside interface?.. I had used a statement of static (DMZ,inside) 192.168.254.2 192.168.254.2 netmask 255.255.255.0.
I obviously dont understand the translation rules as well as I need to.
Please help!
Thanks acomiskey
09-27-2009 02:45 PM
Kevin
Assuming you have not disabled NAT with the "no nat-control" command then for traffic to pass from a lower security interface to a higher security interface you need 2 things
1) a rule in an acl allowing the traffic
2) a NAT statement for the device on the higher security interface
What you don't need is a NAT statement for the device on the lower security interface.
In your case the lower security interface is the DMZ and the higher security interface is the inside. So you need a NAT statement for the TACACS+ server because it is on the higher security interface but not for the switch address because it is on the lower security interface.
A further example may help. You have a server on the DMZ with a private IP of 192.168.5.10 and you want to allow access from the Internet to this server. You have a spare public IP to use for this server -
static (dmz,outside) 195.17.17.1 192.168.5.10 netmask 255.255.255.255
so the server in this instance is on the higher security interface ie the DMZ and the internet clients will be coming in on the outside interface which has the lowest security level of all interfaces. This is a common setup.
You ask - "What i dont understand is why I did not have to translate the 192.168.254.2 source address of the switch in the DMZ to the inside interface?.."
Well using the example above that would mean you would need to have translations for all internet clients accessing your DMZ server. This would clearly be impractical as
a) you don't know which internet addresses would be accessing the server
and
b) there are way too many possible internet addresses to setup translations for
So that's why you only need translations for the devices on the higher security interface.
Final point - you can, if you want, translate the addresses coming in on the lower security interface, in your case the DMZ switch IP address. However this is not mandatory.
Jon
09-28-2009 10:55 AM
Jon
what an extremely thorough reply. I do appreciate your taking the time to write it. I want to carry this conversation a step furthur. This due to having resolved the issue that I currently posted about, but having another issue across the same Firewall.
The secondary ACS server (tacacs box) is located in another city and is out accross the WAN Interface on our ASA. The security levels on our ASA are set up as follows:
Inside 100
DMZ 50
WAN 30
Outside 0
The Secondary tacacs box resides at address 192.168.101.95. The route to this node exits the WAN interface on the ASA and heads out over an MPLS circuit to another site where the secondary tacacs server lives.
I need to have the same switch in the DMZ configured with the local tacacs server ( if you'll remember at 192.168.1.163) and also the remote at 192.168.101.95(in case of failure of the Primary tacacs box).
I wrote the following NAT statement earlier with no success:
static (WAN,DMZ) 192.168.101.95 192.168.101.95 netmask 255.255.255.255
We tried this because the statement we used at your advise last week was:
static (inside,DMZ) 192.168.1.163 192.168.1.163 netmask 255.255.255.255
but I think I see the err of my ways based on your explanations in your most recent response.
Would the appropriate statement be
"static (DMZ,WAN) 192.168.254.2 192.168.254.2 netmask 255.255.255.255"
to allow communication between the 192.168.101.95 address on the WAN interface to talk to the 192.168.254.2 address on the DMZ interface?
09-28-2009 12:38 PM
Kevin
"Would the appropriate statement be
"static (DMZ,WAN) 192.168.254.2 192.168.254.2 netmask 255.255.255.255"
to allow communication between the 192.168.101.95 address on the WAN interface to talk to the 192.168.254.2 address on the DMZ interface?"
Yes it would but there is a difference between this example and your previous one. Prepare for another thorough explanation :-)
Again assuming you have not turned off NAT by using the "no nat-control" command.
As stated in previous post for traffic to flow from a lower to higher security interface you need 2 things
1) an acl rule to allow the traffic
2) a NAT statement for the device on the higher security interface
Now for traffic to flow from a higher to a lower security interface as in your latest example you need just one thing
1) a NAT translation for the device on the higher security interface
Now to satisfy this requirement you can do one of three things
i) use a static statement as you have
ii) use a dynamic NAT/PAT statement
iii) use a nat exemption rule to bypass nat which is not quite the same as disabling nat with "no nat-control"
So for example if you are going out to the internet then you need to NAT/PAT your internal addressing to a public internet address - hence a common config you see on a pix/asa
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
which says PAT all inside addresses to the public IP address attached to your outside interface.
The above is an example of a dynamic PAT config ie. option ii) from above.
So your NAT statement will do fine but it's important to understand why you are doing it. It is not so the TACACS server can communicate with the DMZ switch. It is so the DMZ switch can communicate with the TACACS server.
Remember the all important thing with a stateful firewall is in which direction the original connection is initiated.
In your first example it was from a lower to higher security interface.
In this last example it is from a higher to lower security interface.
Jon
09-28-2009 12:57 PM
Once again, great response! I enjoy the conversation as much as I enjoy trying to fix this problem.
I double checked and nat control is configured on the ASA in question.
One thing I have always remembered with respect to the PIX/ ASA over the years is that anytime a connection is launched from a Higher security interface to a lower security interface, it is inherently allowed. Only when connection attempts are initiated from lower security interfaces to higher security interfaces is there the need to specifically allow the attempt. All that being said, I did not create any ACL rule to allow this because I did not beleive it was necessary.
I implemented the statement "static (DMZ,WAN) 192.168.254.2 192.168.254.2 netmask 255.255.255.255" but with no success".
When I set up a capture session to catch all 49 traffic to and from any, and run it on the DMZ interface, and then try to log on to the switch, I see it sends it tacacs request to 192.168.101.95. When I move the capture session to the WAN interface, I do not capture anything. Seems the ASA is dropping it.
I was thinking it might be a routing issue, but the ASA has a route for the 192.168.101.0 network, so i dont think it is that.
I am kinda stuck here.
09-28-2009 01:15 PM
Kevin
Your'e right, you do not need an acl rule as traffic is allowed by default from a higher to lower security interface. As a side note, just in case you ever end up working with the FWSM this rule does not apply to the FWSM.
Can you post the routing table from the ASA.
Do you have an acl on the DMZ interface ?. To allow tacacs to your inside TACACS+ server did you create an acl and if so what does that acl look like ? Remember there is a implicit "deny ip any any" at the end of every acl so you may need to allow tacacs out to the WAN.
Jon
09-29-2009 09:57 AM
I am attaching in notepads both the routing table as well as the ACL's in question....
Thanks for all your assistance.
Kevin
09-29-2009 09:59 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide