cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1092
Views
0
Helpful
9
Replies

tacacs request not moving from DMZ to inside Interface

Kevin Melton
Level 2
Level 2

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.

1 Accepted Solution

Accepted Solutions

acomiskey
Level 10
Level 10

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.

View solution in original post

9 Replies 9

acomiskey
Level 10
Level 10

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.

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

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

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?

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

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.

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

I am attaching in notepads both the routing table as well as the ACL's in question....

Thanks for all your assistance.

Kevin

attachments

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: