ASA 5510 NAT Question

Answered Question
Aug 23rd, 2012

Just upgraded my ASA 5510 from 8.2(1) to 8.4(4)1.  Everything appeared to work just fine with one big exception.

The NAT statements I had previously remained in effect and even appeared to replicate in some instances.

My issue now is I have set up a DMZ interface (security 50) and need a couple servers to connect back to the inside interface (security 100).  I set up the necessary NAT statements within the ASDM to allow the DMZ servers to connect to a single inside server.  However, all the DMZ servers can still ping and connect to ALL inside servers.

Any easy way to limit this?  Am trying to limit the number of servers in the Inside network that the DMZ can access, but it looks like the DMZ has free reign at the present time.

Am happy to post my configs. I would open a TAC case, but this firewall is still so new, the support contract has not yet been processed by Cisco.

Thanks in advance.

I have this problem too.
0 votes
Correct Answer by spetrescu about 1 year 7 months ago

First rule "access-list dmz_access_in extended permit ip any any" will permit traffic to outbound and inside, is ovewriting second rule

Thank you

Sam

Correct Answer by spetrescu about 1 year 7 months ago

I will look, when arrive home, but this is a fast answer.

If 192.168.1.0/24 is DNZ and 10.1.1.0/24 is inside

!---  allow only host 192.168.1.40 from DMZ to aceess host 10.1.1.25 inside network
access-list dmz_access_in permit ip host 192.168.1.40 host 10.1.1.25
!--- deny everthing else to inside network
access-list dmz_access_in deny ip 192.168.1.0 255.255.255.255 10.1.1.0 255.255.255.0
!--- allow access from DNZ to the internet
access-list dmz_access_in permit ip 192.168.1.0 255.255.255.255 any

Samuel Petrescu

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
kerryjcox Thu, 08/23/2012 - 10:45

Just a followup: when I set the Access Rule on the DMZ interface to be the implict rule, i.e. P"ermit all traffic to less secure networks", I am unable to connect to the Inside network, but can get out on on the Internet.  So far, so good.  This is what I expect.  I can ping outside IP addresses and route, etc.

However, when I create a default access rule on the dmz interface on the ASDM, i.e. source any, destination any, and service ip, and permit, then I can connect all dmz servers back into the inside network.  Not my desired action. 

I guess I am at a loss to know why the default implicit rule overrides my static rule.  Is there a NAT statement someplace I am missing?

Thanks in advance.

spetrescu Thu, 08/23/2012 - 10:51

An easy fix, is to write an ACL and apply it to the DMZ interface, inbound direction.

kerryjcox Thu, 08/23/2012 - 11:06

Good answer, and I attempted that on the ASDM. I can probably do it better on the CLI, but I am used to the ASDM.  Apologies.

I added a static access rule on the DMZ interface stating ANY, ANY service IP PERMIT.

And then followed that up with an ANY, inside-network service IP DENY.  I can still ssh and ping the inside network from any DMZ server. 

Odd.  I am feeling very dumb..... Thanks.

Here's the packet-tracer output:

# packet-tracer input dmz tcp 192.168.1.40 ssh 10.1.1.25 ssh

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   internal-network 255.255.255.0   inside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group dmz_access_in in interface dmz

access-list dmz_access_in extended permit ip any any

access-list dmz_access_in remark == deny dmz traffic to inside network ==

Additional Information:

Phase: 4     

Type: IP-OPTIONS

Subtype:     

Result: ALLOW

Config:      

Additional Information:

Phase: 5     

Type: NAT    

Subtype:     

Result: ALLOW

Config:      

nat (dmz,inside) source static dmz-webapps dmz-webapps destination static proddb.wjbradley.local proddb.wjbradley.local description == nat dmz webapp servers to proddb ==

Additional Information:

Static translate 192.168.1.40/22 to 192.168.1.40/22

Phase: 6     

Type: IP-OPTIONS

Subtype:     

Result: ALLOW

Config:      

Additional Information:

Phase: 7     

Type: FLOW-CREATION

Subtype:     

Result: ALLOW

Config:      

Additional Information:

New flow created with id 1643882, packet dispatched to next module

Result:      

input-interface: dmz

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

kerryjcox Thu, 08/23/2012 - 11:09

Granted, I do have a rule allowing 192.168.1.40 access to the 10.1.1.25 server on the inside network.

So, here is a packet-trace to an inside box that the dmz servers should NOT be able to access:

slcvw# packet-tracer input dmz tcp 192.168.1.40 ssh 10.1.1.55 ssh

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   internal-network 255.255.255.0   inside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group dmz_access_in in interface dmz

access-list dmz_access_in extended permit ip any any

access-list dmz_access_in remark == deny dmz traffic to inside network ==

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 1645593, packet dispatched to next module

Result:

input-interface: dmz

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Do I simply have the ACLs out of order? Thanks.

Correct Answer
spetrescu Thu, 08/23/2012 - 11:24

I will look, when arrive home, but this is a fast answer.

If 192.168.1.0/24 is DNZ and 10.1.1.0/24 is inside

!---  allow only host 192.168.1.40 from DMZ to aceess host 10.1.1.25 inside network
access-list dmz_access_in permit ip host 192.168.1.40 host 10.1.1.25
!--- deny everthing else to inside network
access-list dmz_access_in deny ip 192.168.1.0 255.255.255.255 10.1.1.0 255.255.255.0
!--- allow access from DNZ to the internet
access-list dmz_access_in permit ip 192.168.1.0 255.255.255.255 any

Samuel Petrescu

kerryjcox Thu, 08/23/2012 - 11:28

CLI rule that is causing confusion:

access-list dmz_access_in remark == permit all dmz traffic outbound ==

access-list dmz_access_in extended permit ip any any

access-list dmz_access_in remark == deny dmz traffic to inside network ==

access-list dmz_access_in extended deny ip any object inside-network

access-group outside_access_in in interface outside

access-group dmz_access_in in interface dmz

Thanks.

Correct Answer
spetrescu Thu, 08/23/2012 - 11:32

First rule "access-list dmz_access_in extended permit ip any any" will permit traffic to outbound and inside, is ovewriting second rule

Thank you

Sam

kerryjcox Thu, 08/23/2012 - 11:43

Man, I feel like a fool. I see the logic now.  I have the following in place and have confirmed it works just like I want it to:

access-list dmz_access_in remark == permit webapps ip access to web03 ==

access-list dmz_access_in extended permit ip object 192.168.1.40 host 10.1.1.16

access-list dmz_access_in remark == permit webapps ip access to proddb ==

access-list dmz_access_in extended permit ip object 192.168.1.40 host 10.1.1.25

access-list dmz_access_in remark == deny dmz traffic to inside network ==

access-list dmz_access_in extended deny ip any object inside-network

access-list dmz_access_in remark == permit all dmz traffic outbound ==

access-list dmz_access_in extended permit ip any any

So the first two (2) rules state my dmz server can access those two (2) inside boxes, and then the 3rd rule states everything else is denied to the inside network from the dmz.  Then the 4th and last rule states the dmz network can get out to the Internet.

Excellent!  Tested and confirmed this is working the way I want it to. I can further refine from here.  Much appreciated.

Actions

Login or Register to take actions

This Discussion

Posted August 23, 2012 at 10:26 AM
Stats:
Replies:9 Avg. Rating:5
Views:1022 Votes:0
Shares:0
Tags: nat, asa, 5510, asa_5510
+

Related Content

Discussions Leaderboard