cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1191
Views
3
Helpful
13
Replies

Cisco ASA Bridged DMZ

iroccorp.com
Level 1
Level 1

Hi,

I am trying to setup a Cisco ASA 5510 (with plus) to act as our main firewall as well as offer us DMZ services, for webserver/SSL Concentrators (Citrix and Cisco CVPN3015). What we would like to do is a dual homed DMZ, where one link is for the inside-DMZ and one link is for the outside-DMZ, where the SSL concentrators and webservers can act as their own gateways. The problem is on the outside / public DMZ, we would like to have this setup as a bridged network, between the outside interface and the outside-dmz interface. We still want to be able to filter on the outside-dmz interface, for security reasons.

Is there a way to do this? Do i need to setup a virtual outside interface to which the outside-DMZ interface is bridged?

The problem is, when reading the documentation on transparent firewalling, it seems to apply to the entire ASA, thus could be causing some problems since we are nat'ing the inside network to the outside and utilizing the CSC-SSM module for some data filtering for the inside network.

Actually we are using PAT as defined on the asa, not like ios router with nat overload statement. If someone knows a better way to do nat like in ios on a ASA , where we nat many inside addresses to one outside address, please let me know.

So anyone have any suggestions on implementing a bridged DMZ?

13 Replies 13

andrew.burns
Level 7
Level 7

Hi,

You can only have inside and outside interfaces in transparent mode, and NAT isn't allowed, so it sounds like transparent mode won't work for you:

http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_chapter09186a00806370bb.html#wp1201980

If you need to offer DMZ services, NAT, etc, than I'd stick with normal (routed) mode.

HTH

Andrew.

Hi Andrew,

This is the conclusion i have come to aswell. I am trying to figure out how to get the routed mode to work right now and it seems there is something i am doing wrong, as data just wont route across the interfaces, even when setting the access lists.

See the post:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Security&topic=Firewalling&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1ddebeb0

Any hints?

From you other post you said you

"be able to let network traffic, between the inside network and the inside DMZ to pass freely ."

For that you should need something like this

static (inside,INSIDE-DMZ) 192.168.100.0 192.168.100.0 netmask 255.255.255.0

does that help?

also, to initiate from the INSIDE-DMZ to the inside you would need to have an acl in interface INSIDE-DMZ

You also want...

" to be able to route the public address space across the ASA, between the E0 and E1 interfaces"

try this...

static (OUTSIDE-DMZ,outside) 72.13.113.0 72.13.113.0 netmask 255.255.255.128

does the static command mean access list permissions / routing permissions, or does it have something to do with NAT. I don't want to use NAT on the DMZ ..

thanks

It has to do with nat, but when it's written how it, it will not nat. There needs to be a translation in the ASA for communication from higher to lower security interface. You could also do this...

access-list nonatdmz extended permit ip any 192.168.50.0 255.255.255.0

nat (inside) 0 access-list nonatdmz

Does that make sense?

Also just noticed that your security levels for inside and inside-dmz are both 100. You will need this command as well for communication between same security level interfaces OR change the security level on inside-dmz to something between 100 and 10.

same-security-traffic permit inter-interface

I can ping from the inside interface to the inside DMZ interface now, but can't do it in reverse. the same-security-traffic permit inter-interface didn't seem to help anything ..

Can you post a clean config? Is your outside-dmz working as you wish?

Also, should the inside-dmz really be the same security level? I would assume it is less secure than your inside. I would recommend to lower the security on it. Leave the existing static (inside,inside-dmz)... then write an access-list that applies in interface inside-dmz to allow that traffic into your inside network.

seem to be having a issue with pinging anything outside (aka ICMP traffic seems to be denied right now). Anyways, here we go. PS: we also are using OSPF on the inside network.

ASA Version 7.1(2)

!

hostname firewall

domain-name example.com

names

!

interface Ethernet0/0

nameif outside

security-level 0

ip address 72.13.113.129 255.255.255.240

!

interface Ethernet0/1

description DMZ Outside Interface

nameif dmz-outside

security-level 10

ip address 72.13.113.1 255.255.255.128

!

interface Ethernet0/2

description DMZ Inside Interface

nameif dmz-inside

security-level 100

ip address 192.168.50.1 255.255.255.0

ospf network point-to-point non-broadcast

!

interface Ethernet0/3

nameif inside

security-level 100

ip address 192.168.100.1 255.255.255.0

ospf network point-to-point non-broadcast

ospf message-digest-key 1 md5

ospf authentication message-digest

!

interface Management0/0

shutdown

no nameif

no security-level

no ip address

!

ftp mode passive

clock timezone MST -7

clock summer-time MDT recurring

dns domain-lookup outside

dns server-group DefaultDNS

name-server xxx.xxx.xxx.xxx

domain-name example.com

same-security-traffic permit inter-interface

access-list nonatdmz extended permit ip any 192.168.50.0 255.255.255.0

pager lines 24

mtu outside 1500

mtu dmz-outside 1500

mtu dmz-inside 1500

mtu inside 1500

no failover

asdm image disk0:/asdm512-k8.bin

asdm history enable

arp timeout 14400

nat-control

global (outside) 10 interface

nat (inside) 0 access-list nonatdmz

nat (inside) 10 0.0.0.0 0.0.0.0

static (inside,dmz-inside) 192.168.100.0 192.168.100.0 netmask 255.255.255.0

static (dmz-outside,outside) 72.13.113.0 72.13.113.0 netmask 255.255.255.128

route outside 0.0.0.0 0.0.0.0 72.13.113.129 1

!

router ospf 1

network 192.168.50.0 255.255.255.0 area 0

network 192.168.100.0 255.255.255.0 area 0

area 0 authentication message-digest

log-adj-changes

!

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

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

http server enable

http 0.0.0.0 0.0.0.0 inside

no snmp-server location

no snmp-server contact

linkup linkdown coldstart

telnet 0.0.0.0 0.0.0.0 inside

telnet timeout 5

ssh scopy enable

ssh 0.0.0.0 0.0.0.0 outside

ssh 0.0.0.0 0.0.0.0 inside

ssh timeout 10

console timeout 0

dhcpd address 192.168.100.25-192.168.100.35 inside

dhcpd dns 192.168.100.25

dhcpd wins 192.168.100.25

dhcpd lease 3600

dhcpd ping_timeout 50

dhcpd domain example.com

dhcpd auto_config inside

dhcpd enable inside

!

class-map HTTP

match port tcp eq www

class-map inspection_default

match default-inspection-traffic

class-map outside-class

match access-list outside_mpc_in

!

!

policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect h323 h225

inspect h323 ras

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect esmtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

policy-map outside-policy

class outside-class

csc fail-open

policy-map inside-policy

class HTTP

csc fail-open

!

service-policy global_policy global

service-policy outside-policy interface outside

service-policy inside-policy interface inside

Thanks

I added to my last post above in case you didn't see it.

You don't need both of these, you can get rid of one or the other.

static (inside,dmz-inside) 192.168.100.0 192.168.100.0 netmask 255.255.255.0

access-list nonatdmz extended permit ip any 192.168.50.0 255.255.255.0

nat (inside) 0 access-list nonatdmz

To allow ping in from outside,

access-list outside_access_in extended permit icmp any any

access-group outside_access_in in interface outside

This seems to work for the pings. Thanks.

What would the access-list / group look like to allow for traffic from the dmz-inside to the inside interface ?

It depends on what you wanted to allow but it would look like this, what you are doing here is writing statements to allow traffic from dmz-inside to inside, then you are denying everything else from dmz-inside to inside, then you are allowing the dmz-inside to go everywhere else(outside).

access-list insidedmz_to_inside extended permit

access-list insidedmz_to_inside extended permit

access-list insidedmz_to_inside extended permit

...

access-list insidedmz_to_inside extended deny ip any 192.168.100.0 255.255.255.0

access-list insidedmz_to_inside extended permit ip any any

access-group insidedmz_to_inside in interface dmz-inside

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: