Cisco ASA Bridged DMZ

Unanswered Question
Jun 4th, 2007
User Badges:


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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
andrew.burns Fri, 06/08/2007 - 08:59
User Badges:
  • Gold, 750 points or more


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:

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


Andrew. Fri, 06/08/2007 - 09:08
User Badges:

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:

Any hints?

acomiskey Fri, 06/08/2007 - 09:17
User Badges:
  • Green, 3000 points or more

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) netmask

does that help?

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

acomiskey Fri, 06/08/2007 - 09:21
User Badges:
  • Green, 3000 points or more

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) netmask Fri, 06/08/2007 - 09:29
User Badges:

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 ..


acomiskey Fri, 06/08/2007 - 09:32
User Badges:
  • Green, 3000 points or more

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

nat (inside) 0 access-list nonatdmz

Does that make sense?

acomiskey Fri, 06/08/2007 - 09:45
User Badges:
  • Green, 3000 points or more

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 Fri, 06/08/2007 - 12:20
User Badges:

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 ..

acomiskey Fri, 06/08/2007 - 12:24
User Badges:
  • Green, 3000 points or more

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. Fri, 06/08/2007 - 12:36
User Badges:

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




interface Ethernet0/0

nameif outside

security-level 0

ip address


interface Ethernet0/1

description DMZ Outside Interface

nameif dmz-outside

security-level 10

ip address


interface Ethernet0/2

description DMZ Inside Interface

nameif dmz-inside

security-level 100

ip address

ospf network point-to-point non-broadcast


interface Ethernet0/3

nameif inside

security-level 100

ip address

ospf network point-to-point non-broadcast

ospf message-digest-key 1 md5

ospf authentication message-digest


interface Management0/0


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



same-security-traffic permit inter-interface

access-list nonatdmz extended permit ip any

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


global (outside) 10 interface

nat (inside) 0 access-list nonatdmz

nat (inside) 10

static (inside,dmz-inside) netmask

static (dmz-outside,outside) netmask

route outside 1


router ospf 1

network area 0

network area 0

area 0 authentication message-digest



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 inside

no snmp-server location

no snmp-server contact

linkup linkdown coldstart

telnet inside

telnet timeout 5

ssh scopy enable

ssh outside

ssh inside

ssh timeout 10

console timeout 0

dhcpd address inside

dhcpd dns

dhcpd wins

dhcpd lease 3600

dhcpd ping_timeout 50

dhcpd domain

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


acomiskey Fri, 06/08/2007 - 12:40
User Badges:
  • Green, 3000 points or more

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) netmask

access-list nonatdmz extended permit ip any

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 Fri, 06/08/2007 - 12:54
User Badges:

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 ?

acomiskey Fri, 06/08/2007 - 14:13
User Badges:
  • Green, 3000 points or more

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

access-list insidedmz_to_inside extended permit ip any any

access-group insidedmz_to_inside in interface dmz-inside


This Discussion