ASA 5510 DMZ - 2 Private lans 1 public 1dmz

[mscha2000]

I have an ASA connected to:

2 private LANS - 1 for my hq (where the asa physically resides) call this 10.1.1.0 vlan 1 - Interface inside security level 100

    and 1 for the MPLS connection call this 10.1.2.1 vlan 2. - Interface Outside security level 100

1 Interface connected to the public access here at my hq with 184.x.x.1 - security level 50

1 Interface connected to the DMZ which I am setting up - 192.168.x.1 - security level 50

Currently all traffic is flowing through the Firewall but I am not scanning anything (notice under class inspection default there is no tcp entry)(meaning I am not inspecting as I did not want to disrupt traffic) however, I do not want to connect the public interface to the internet until inspection is on due to fear that this leaves the corporate network vulnerable.

My question(s) are as follows:

1. How do I turn tcp inspection back on? Is it just getting into the class map and adding inspect tcp?

2. I've been collecting the traffic flows in anticipation of doing this for 6 months.(if I need to do a deeper analysis once I notice traffic is disrupted) but is there something I need to add to my acl to ensure no disruption?

Traffic Flow:

I want to allow hosts to hit the public interface at 184.x.x.1 for a specific type of traffic - call it http for simplicity of example. Then I want that traffic forwarded to the host on the dmz which will service those requests - 192.168.1.2.  I'm sure there is nat or pat needed here I'm just not sure how to configure it.

Then I need that traffic from the dmz host to be able to get to the server on my mpls over the same port : from 192.168 host to 10.1.1.x host - also needs nat and or pat and acl?

Thanks for any help.

ciscoasa# sho run
: Saved
:
ASA Version 8.4(1)
!
hostname ciscoasa
domain-name marcjacobs.lvmh
enable password wrblOSAyPeeKhvhL encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
dns-guard
!
interface Ethernet0/0
nameif outside
security-level 100
ip address 10.1.2.2 255.255.255.240
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.1.1.2 255.255.254.0
!
interface Ethernet0/2
shutdown
nameif public
security-level 0
ip address 184.x.x.1 255.255.255.240
!
interface Ethernet0/3
shutdown
nameif DMZ
security-level 50
ip address 192.168.x.1 255.255.255.0
!
interface Management0/0
nameif management
security-level 100
ip address 192.168.x.x 255.255.255.0
management-only
!
boot system disk0:/asa841.bin
ftp mode passive
dns server-group DefaultDNS
domain-name xxx.local
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

object network DMZ
range 192.168.x.1 192.168.x.254

object network public
host 184.x.x.1

object network traveler
host 192.168.x.25

access-list 101 extended permit ip any any
access-list 101 extended permit icmp any any
access-list 101 extended permit udp any any
access-list 101 extended permit tcp any any
access-list 101 extended permit gre any any
access-list 101 extended permit esp any any
access-list 101 extended permit tcp any any eq smtp
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu public 1500
mtu DMZ 1500
mtu management 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-641.bin
no asdm history enable
arp timeout 14400
!
object network DMZ
nat (DMZ,outside) dynamic interface

object network traveler
nat (DMZ,public) static 184.x.x.2 dns

access-group 101 in interface outside
route outside 0.0.0.0 0.0.0.0 10.1.2.1 1
route outside 10.1.0.x 255.255.255.255 10.1.2.1 1
route inside 10.1.6.0 255.255.255.0 10.1.1.6 1

timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.x.x 255.255.255.0 management

no snmp-server location
no snmp-server contact
snmp-server community *****
snmp-server enable traps snmp authentication linkup linkdown coldstart
snmp-server enable traps syslog
snmp-server enable traps entity config-change fru-insert fru-remove
snmp-server enable traps remote-access session-threshold-exceeded

telnet timeout 100
ssh scopy enable
ssh timeout 60
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
username   encrypted
username  encrypted privilege 15
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect ip-options
!
service-policy global_policy global
prompt hostname context
call-home
profile CiscoTAC-1
  no active
  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
  destination address email callhome@cisco.com
  destination transport-method http
  subscribe-to-alert-group diagnostic
  subscribe-to-alert-group environment
  subscribe-to-alert-group inventory periodic monthly
  subscribe-to-alert-group configuration periodic monthly
  subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:01223e26a049ddaa1998dbf732f52db5
: end
ciscoasa#

[Julio Carvajal · Accepted solution]

Hello Mscha2000,

First of all the ASA is a security device that provides stateful inspection (layer 3 and 4) with deep packet inspection  (layer 5 to 7) so by default its statefully inspecting TCP and UDP protocols, there is no such a command to inspect tcp.

On the ACL you are allowing all traffic from the outside to the inside, so communications innitiated on the untrusted zone to any inside host will be allowed.

One thing I noticed is that the DMZ has a security level of 50 while the outside ( witch is usually the less trusted interface) has a security level of 100 so if you want to allow communication from the dmz to the outside you will need to create a static (outside,dmz) and then an ACL on the DMZ interface.

Lets work on the following task:

Outside user trying to access DMZ host 192.168.x.15 to the public IP 184.x.x.1 on port HTTP (HTTP server on the DMZ):

Object network DMZ_http_Server

host 192.168.x.15

Object network Natted_Outside_Http_Server

host 184.x.x.1

nat (dmz,outside) source static DMZ_http_Server Natted_Outside_Http_Server

As the outside interface has a security level of 100 you do not need an ACL to go to a lower security level.

Please rate helpful posts.

Julio

[mscha2000]

Julio,

     thank you for your guidance.

What I was refering to by tcp inspection is the "no threat detection statistics tcp intercept" command that was entered while troubleshooting at some point.  im just concerned that id be opening the corp net to public threats.

since we have 2 "trusted" networks and one of them was named outside, I chose "public" to represent the untrusted. seems a bit counter intuitive I know but i inherited the config as it is.

I know traffic from outside to dmz is allowed by the security settings but I am concerned with traffic from the dmz to the outside interface.  that needs an acl on the dmz interface out? that acl defines the exact traffic i want to allow correct? the nat for this is covered by the statement "nat (dmz,outside)dynamic interface" correct?

once again,thank you very much, I am going to give top rating,

-Mike

[Julio Carvajal]

Hello Mike,

First of all thanks for the rating.

Now lets talk about this particular command: -no threat detection statistics tcp intercept

You have entered this command, so you are letting the ASA know : Do not generate statistics when the TCP intercept feature is being used. You did not take out the TCP intercept feature, all you did wast to disable generating a statistics table with the TCP intercept data.

If you would like to put it back all you just add the command:

     -threat detection statistics tcp intercept

Ok, got it, I did not check the public one.

So the communication will be from the DMZ to the outside, in order to accomplish that communication you will need:

1-Static translation from the outside to the DMZ: nat (outside,dmz) source static xxxxx yyyyy

2-Access-list on the DMZ inbound direction (access-group xxxx in interface dmz) permiting traffic to the outside interface ( the one you want to allow)

Let me know if you have any other question

Please rate helpful posts.

Julio

[mscha2000]

Julio,

Ok so I'm honing in on the remaining elements of this config. I have

a question that is related to information that I did not make very clear

but as this comes together I'm understanding it more thoroughly and finding

the issues.

The DMZ interface on the firewall is the only connection that is connected

to the public internet. The ip on this interface is 184.x.x.15 let's say.

I have pointed my external url https://function.company.com to this

address. Here's the question: do I need to assign a public range ip

(184.x.x.16) to the server which needs to be reachable via that link?

For example: if someone from the public internet types in that url they

need to hit the web server not the firewall. So the nat I need to set up

stays the same, correct?

Since I don't want ALL traffic coming into the public ip of the firewall

dmz port at 184.x.x.15 to be translated to the web server at 192.168.x.25 I

need to assign an IP that only lives on the firewall specifically for that

translation

(i.e. 184.x.x.16 -->192.168.x.25) correct?

That takes care of the public. Then from the dmz web server to the mpls

network everything gets translated into the ip of the firewall's port on

the "outside"(mpls) connected interface - 10.1.1.2 (i.e. 192.168.x.x

-->10.1.1.2) I need to know because I don't control the firewall on the

other side of the mpls connection so I need to tell them the source and

destination (I'm thinking the source is the firewalls mpls ip and the

destination is the internal server ip that the web server needs to

communicate to). is that correct? where does the acl for this traffic go?

And what would a statement look like?

access-list 100 extended permit host 192.168.x.25 https host 10.1.2.5 eq

443??

Thanks for your help thus far and thank you in advance for any continued

guidance!

-Mike

On Tue, Dec 13, 2011 at 8:13 PM, jcarvaja <

[Julio Carvajal]

Hello Mike,

do I need to assign a public range ip (184.x.x.16) to the server which needs to be reachable via that link?

No, you can have the private ip address on the server and then nat that Ip address on the outside to 184.x.x.16, that in fact my friend is the whole point of using nat ( keeping  the same desing of our internal network an will provide security to our devices because no one else knows what the private ip address of that server is except for the firewall).

Of course from the outside you will need to hit the routable ip address (Public one=184.xx.xx.xx)

I need to know because I don't control the firewall on the other side of the mpls connection so I need to tell them the source and destination (I'm thinking the source is the firewalls mpls ip and the destination is the internal server ip that the web server needs to communicate to). is that correct

Correct, if there is a firewall on the other side you got to be able to let them know the source (ip address of the server on the outside interface NATED) and destination ( host on the other side)

where does the acl for this traffic go?

Same way than the previously configured,= access-group xxxx in interface dmz)

Access-list xxxx extended permit tcp host 192.168.x.25 (DMZ SERVER)   host 10.1.2.5 (Other side host) eq xx

Please rate helpful posts,

Julio

[mscha2000]

Julio,

I used most of what we worked on together and put it in place on the

firewall. However, it would not take the commands I expected it to take.

Here is the breakdown:

For access to the public access to the web server from the internet:

I setup static object network nat with port translation because I may need

to use the same public IP for several different purposes. One thing to note

is that the asa would not let me use it's own "public" interface IP.

Interface name - public - ip= 184.x.x.194

I had to use an alternate address for the translation to the webserver on

the dmz = 184.x.x.196

object network public

host 184.x.x.196

object network websvr

host 192.168.x.26

object network dmz_range

range 192.168.x.1 192.168.x.254

object network websvr

nat (DMZ,public) static 184.x.x.196 service tcp https https

For access to the "outside" interface which is my mpls (not really

untrusted):

I tried to setup static nat for anything on the dmz range (192.168.x.0) to

be translated into the outside interface ip - 10.x.x.2 and no matter what

combination I tried this in it would not take the commands.

I thought it would be:

object network DMZ

nat (dmz,outside) source static 192.168.x.0 (or dmz_range) 10.x.x.2 - This

would not work. Am I doing it in the wrong place? Do I need another object

network statement?

Then the access lists:

1. for allowing the traffic to the dmz from the public as such:

access-list 100 extended permit ip any host 184.x.x.196 tcp eq 443 - is

this correct? then apply this on the dmz interface outbound?

2. for allowing the traffic from the dmz to the "outside" (or mpls

interface) as such

access-list 102 extended permit ip host 192.168.x.26(webserver dmz ip)

10.x.x.45(internal app server) eq 1xxx - is that correct? and then apply it

to the "outside" interface outbound?

I'm sure for you this would be much simpler than I'm making it but some

things did not work as expected and I'm at a loss. I have a support

contract but it is a long arduous task to renew it and they are in the

process.

Thank you very much for your continued support!

-Mike

On Wed, Dec 14, 2011 at 6:10 PM, jcarvaja <

[mscha2000]

I left out that I need an access list applied to the "public" interface

inbound as such:

access-list 99 extended permit any host 184.x.x.196 eq 443 - correct?

[Julio Carvajal]

Hello Mike,

1-For access to the public access to the web server from the internet:

I setup static object network nat with port translation because I may need

to use the same public IP for several different purposes. One thing to note

is that the asa would not let me use it's own "public" interface IP.

Interface name - public - ip= 184.x.x.194

I had to use an alternate address for the translation to the webserver on

the dmz?

R/ You could have use the keyword interface.

2-For access to the "outside" interface which is my mpls (not really

untrusted):

I tried to setup static nat for anything on the dmz range (192.168.x.0) to

be translated into the outside interface ip - 10.x.x.2 and no matter what

combination I tried this in it would not take the commands.

I thought it would be:

object network DMZ

nat (dmz,outside) source static 192.168.x.0 (or dmz_range) 10.x.x.2 - This

would not work. Am I doing it in the wrong place? Do I need another object

network statement?

R/ Remember that the higher security level is the outside interface so what you need to do is to allow communication from the lower security level to the higher (unless there is a biderectional nat and an ACL you will not be able to start the communication from the DMZ). So you did it backwards. You need to nat the outside subnet into the DMZ network.

Object network OUTSIDE

subnet 10.1.2.0 255.255.255.0

nat (outside,dmz) source static OUTSIDE OUTSIDE

Access-list test permit ip any 10.1.2.0 255.255.255.0

access-group dmz_in interface dmz.

3-for allowing the traffic to the dmz from the public as such:

access-list 100 extended permit ip any host 184.x.x.196 tcp eq 443 - is

this correct? then apply this on the dmz interface outbound?

R/ The acl structure is okay, the problem is with the Access-group because the ASA will analize the packet for the first time on the public interface ( where the packet will be received) so you should put it inbound on that interface.

4-for allowing the traffic from the dmz to the "outside" (or mpls

interface) as such

access-list 102 extended permit ip host 192.168.x.26(webserver dmz ip)

10.x.x.45(internal app server) eq 1xxx - is that correct? and then apply it

to the "outside" interface outbound

R/ Same answer as before, needs to be applied to the DMZ interface inbound direction.

5-I left out that I need an access list applied to the "public" interface

inbound as such:

access-list 99 extended permit any host 184.x.x.196 eq 443 - correct?

R/No, the ACL would be on the DMZ again.

Please do rate helpful posts.

Julio

Cisco Tac

[mscha2000]

Julio,

First of all, thank you.

As for the traffic between the dmz and outside: the traffic will originate from the dmz. So, perhaps I need to setup bidirectional nat?

The flow is this: request comes from the internet to a url which is pointed at the 184.x.x.194(the public interface ip) address > the firewall translates the public ip to something the dmz can reach(192.168.x.26)> and forwards the request to the webserver.> The webserver checks> the database on the internal application server (at outside interface)(10.x.1.2) and then --> returns the requested application page to the requester on the public internet.

Is that clear ? Am I doing this correctly?

Sent from my Verizon Wireless BlackBerry

[Julio Carvajal]

Hello,

Yes, got to be biderectional, The previous answers are going to work on this.

Regards,