08-23-2012 10:26 AM - edited 02-21-2020 04:43 AM
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.
Solved! Go to Solution.
08-23-2012 11:24 AM
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
08-23-2012 11:32 AM
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
08-23-2012 10:45 AM
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.
08-23-2012 10:51 AM
An easy fix, is to write an ACL and apply it to the DMZ interface, inbound direction.
08-23-2012 11:06 AM
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
08-23-2012 11:09 AM
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.
08-23-2012 11:24 AM
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
08-23-2012 11:28 AM
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.
08-23-2012 11:32 AM
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
08-23-2012 11:43 AM
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.
08-23-2012 11:48 AM
Thank you
Sam
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