Solved: https access from DMZ to Inside on ASA 5505

Peters · ‎01-06-2012

We have an ASA5505 UL bundel, updated with this license "L-ASA5505-SEC-PL=" to enable traffic from DMZ to Inside. No NAT or rules deployed for that yet.

On the Inside we have Exchange 2007 in a single server installation. The public url for smtp, ActiveSync, OWA and Outlook Anywhere is mail.company.se. There is a static NAT for outside traffic to access above mentioned services on inside. Now, on DMZ there is the WLAN for guests to access the Internet. How ever, our Smart Phones with WLAN turned on, cannot sync to the Exchange Server on the Inside! The DMZ gets IP-addressen from ASA on DMZ Interface with external DNS configured.

How can I configure the ASA to achieve the function of ActiveSync from DMZ to Inside with the public URL from the phones?

Thanks in advace

/Peter

varrao · ‎01-07-2012

Hey that gr8

You can mark the thread as answered, if it is resolved.

Thanks,

Varun

Thanks,
Varun Rao

View solution in original post

varrao · ‎01-06-2012

Hi Peter,

You would need to create a static nat for the DMZ to inside traffic as well, something like this:

static (Inside,DMZ)

you would also need to permit the traffic on dmz interface:

access-list dmz_access_in permit tcp any host

Hope that helps,

Thanks,

Varun

Thanks,
Varun Rao

Peters · ‎01-07-2012

It workt like dream! Thanks alot.

/Peter

varrao · ‎01-07-2012

Hey that gr8

You can mark the thread as answered, if it is resolved.

Thanks,

Varun

Thanks,
Varun Rao

netdood · ‎02-08-2013

I'm trying to do the same thing.

Wireless clients on a lower privileged "Public Wireless" interface need to access email server on inside interface.

Config,

static (inside,Public_Wireless) Public_email_server Private_email_server netmask 255.255.255.255

nat (Public_Wireless) 1 0.0.0.0 0.0.0.0

access-group Public_Wireless_access_in in interface Public_Wireless

I allowed ping, http, https, and smtp but cannot do any of those from the public wireless client

Packet tracer says,

Phase: 8

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

static (inside,Public_Wireless) PUBLIC PRIVATE netmask 255.255.255.255

nat-control

match ip inside host PRIVATE Public_Wireless any

static translation to PUBLIC

translate_hits = 0, untranslate_hits = 34

Additional Information:

Forward Flow based lookup yields rule:

out id=0x72ff74b8, priority=5, domain=nat-reverse, deny=false

hits=3, user_data=0x71f2a038, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=PRIVATE, mask=255.255.255.255, port=0, dscp=0x0

Result:

input-interface: Public_Wireless

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

What am I missing?

Jouni Forss · ‎02-08-2013

Hi,

There might be some conflicting NAT rule perhaps

Can you share you whole NAT configuration.

In cases like the orignal post in this topic the solution might even be configuring the "dns" parameter to the actual "inside" to "outside" Static NAT configurations. But this requires that the servers public IP address has an attached DNS name in the public DNS servers and hosts on the DMZ are using public DNS.

- Jouni

netdood · ‎02-08-2013

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0

nat (2nd_ISP) 1 0.0.0.0 0.0.0.0

nat (Public_Wireless) 1 0.0.0.0 0.0.0.0

Email works from the outside interface,

static (inside,outside) tcp PUBLIC smtp EMAIL_SERVER smtp netmask 255.255.255.255

static (inside,outside) tcp PUBLIC https EMAIL_SERVER https netmask 255.255.255.255

static (inside,outside) tcp PUBLIC www EMAIL_SERVER www netmask 255.255.255.255

static (inside,Public_Wireless) PUBLIC PRIVATE_EMAIL_SERVER netmask 255.255.255.255

Let me know if you need to see any more config.

Jouni Forss · ‎02-08-2013

Hi,

At least need to know the configuration of the ACL "inside_nat0_outbound" and what the networks contained there are.

- Jouni

netdood · ‎02-08-2013

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.252.0 192.168.255.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.0.0 192.168.255.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 192.168.255.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip object-group DM_INLINE_NETWORK_1 10.16.0.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip object-group DM_INLINE_NETWORK_2 10.17.0.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip object-group VPN1 object-group VPN1_INSIDE

access-list inside_nat0_outbound extended permit ip object-group VPN2 object-group VPN2_INSIDE

access-list inside_nat0_outbound extended permit ip object-group VPN3 object-group VPN3_INSIDE

! public wireless network is 10.0.168.0 /21

Jouni Forss · ‎02-08-2013

Hi,

Does any of the "object-group" contain this network?

The ACL seems a bit messy. There are alot of really big networks used (whole private ranges)

In some cases these might cause problems with the operation of NAT.

I personally try to keep the NAT as specific as possible.

- Jouni

netdood · ‎02-08-2013

Yah almost all of the object-groups contain the big 10.0 network,

object-group network DM_INLINE_NETWORK_2

network-object 10.0.0.0 255.255.0.0

network-object 10.10.0.0 255.255.0.0

network-object 10.11.0.0 255.255.0.0

network-object 10.12.0.0 255.255.0.0

network-object 10.13.0.0 255.255.0.0

network-object 10.15.0.0 255.255.0.0

network-object 10.16.0.0 255.255.254.0

network-object 172.16.0.0 255.255.0.0

network-object 192.168.0.0 255.255.252.0

The config was there before I got here, I'd also like to make it more specific but if I alter the object groups, the vpn tunnels will come down. It is messy.

Jouni Forss · ‎02-08-2013

I think the NAT0 might be messing with the NAT configuration you have added since "packet-tracer" fails when doing rpf-check.

Can you copy/paste the whole "packet-tracer" command and its output here.

The NAT0 rules should be pretty easy to clean up but ofcourse the more VPN connections and networks you have, the more configurations are needed.

- Jouni

netdood · ‎02-08-2013

MC-FW# packet-tracer input Public_Wireless icmp WIRELESS_CLIENT 0 8 INSIDE_EMAIL_SERVER d$

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in id=0x71c2de08, priority=1, domain=permit, deny=false

hits=325666775, user_data=0x0, cs_id=0x0, l3_type=0x8

src mac=0000.0000.0000, mask=0000.0000.0000

dst mac=0000.0000.0000, mask=0100.0000.0000

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.0.0 255.255.252.0 inside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Public_Wireless_access_in in interface Public_Wireless

access-list Public_Wireless_access_in extended permit object-group DM_INLINE_SERVICE_2 any host INSIDE_EMAIL_IP

object-group service DM_INLINE_SERVICE_2

service-object icmp

service-object tcp eq www

service-object tcp eq https

service-object tcp eq smtp

Additional Information:

Forward Flow based lookup yields rule:

in id=0x72517f40, priority=12, domain=permit, deny=false

hits=2, user_data=0x6d447d00, cs_id=0x0, flags=0x0, protocol=1

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=INSIDE_EMAIL_IP, mask=255.255.255.255, port=0, dscp=0x0

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x71c2ea80, priority=0, domain=inspect-ip-options, deny=true

hits=17052497, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x71c2e950, priority=66, domain=inspect-icmp-error, deny=false

hits=817139, user_data=0x71534348, cs_id=0x0, use_real_addr, flags=0x0, protocol=1

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 6

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0x74427260, priority=17, domain=flow-export, deny=false

hits=5343930, user_data=0x72c59c00, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (Public_Wireless) 1 0.0.0.0 0.0.0.0

nat-control

match ip Public_Wireless any outside any

dynamic translation to pool 1 (OUTSIDE_IP [Interface PAT])

translate_hits = 17445576, untranslate_hits = 2434626

Additional Information:

Forward Flow based lookup yields rule:

in id=0x71c8e4d0, priority=1, domain=host, deny=false

hits=18502567, user_data=0x71c8e0b8, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

static (inside,Public_Wireless) OUTSIDE_EMAIL_IP INSIDE_EMAIL_IP netmask 255.255.255.255

nat-control

match ip inside host INSIDE_EMAIL_IP Public_Wireless any

static translation to OUTSIDE_EMAIL_IP

translate_hits = 0, untranslate_hits = 363

Additional Information:

Forward Flow based lookup yields rule:

out id=0x72ff74b8, priority=5, domain=nat-reverse, deny=false

hits=4, user_data=0x71f2a038, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=INSIDE_EMAIL_IP, mask=255.255.255.255, port=0, dscp=0x0

Result:

input-interface: Public_Wireless

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Jouni Forss · ‎02-08-2013

Hmm,

Just to make sure, you are using the the PUBLIC IP ADDRESS as the destination IP address of the "packet-tracer" command right? NOT the actual local IP address of the server.

- Jouni

netdood · ‎02-11-2013

I was using the local ip address for the server. When I use the public ip of the server the packet is denied

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in id=0x71c2de08, priority=1, domain=permit, deny=false

hits=327503290, user_data=0x0, cs_id=0x0, l3_type=0x8

src mac=0000.0000.0000, mask=0000.0000.0000

dst mac=0000.0000.0000, mask=0100.0000.0000

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (inside,Public_Wireless) PUBLIC_SERVER_IP PRIVATE_SERVER_IP netmask 255.255.255.255

nat-control

match ip inside host PRIVATE_SERVER_IP Public_Wireless any

static translation to PUBLIC_SERVER_IP

translate_hits = 0, untranslate_hits = 2397

Additional Information:

NAT divert to egress interface inside

Untranslate PUBLIC_SERVER_IP/0 to PRIVATE_SERVER_IP/0 using netmask 255.255.255.255

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in id=0x729aab00, priority=11, domain=permit, deny=true

hits=1894218, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:

input-interface: Public_Wireless

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule