cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3479
Views
0
Helpful
14
Replies

cisco asa 5505 issues ( ROUTING AND PAT)

ziggyrosalsky
Level 1
Level 1

I have some issues with my cisco asa 5505 config. Please see details below:

NETWORK SETUP:

gateway( 192.168.223.191)   - cisco asa 5505 ( outside - 192.168.223.200 , inside - 192.168.2.253, DMZ - 172.16.3.253 )  -

ISSUES:

1)

no route from DMZ to outside

example:

ping from 172.16.3201 to the gateway

6          Jan 27 2014          11:15:33                    172.16.3.201          39728                              Failed to locate egress interface for ICMP from outside:172.16.3.201/39728 to 172.16.3.253/0

2)

not working access from external to DMZ AT ALL

ASA DETAILS:

cisco asa5505

Device license          Base

Maximum Physical Interfaces          8          perpetual

VLANs          3      DMZ Restricted

Inside Hosts          Unlimited          perpetual

configuration:

firewall200(config)# show run

: Saved

:

ASA Version 9.1(3)

!

hostname firewall200

domain-name test1.com

enable password xxxxxxxxxxx encrypted

xlate per-session deny tcp any4 any4

xlate per-session deny tcp any4 any6

xlate per-session deny tcp any6 any4

xlate per-session deny tcp any6 any6

xlate per-session deny udp any4 any4 eq domain

xlate per-session deny udp any4 any6 eq domain

xlate per-session deny udp any6 any4 eq domain

xlate per-session deny udp any6 any6 eq domain

passwd XXXXXXXXXXX encrypted

names

!

interface Ethernet0/0

switchport access vlan 100

!

interface Ethernet0/1

switchport access vlan 200

!

interface Ethernet0/2

switchport access vlan 200

!

interface Ethernet0/3

switchport access vlan 200

!

interface Ethernet0/4

switchport access vlan 300

!

interface Ethernet0/5

switchport access vlan 300

!

interface Ethernet0/6

switchport access vlan 300

!

interface Ethernet0/7

switchport access vlan 300

!

interface Vlan100

nameif outside

security-level 0

ip address 192.168.223.200 255.255.255.0

!

interface Vlan200

mac-address 001b.539c.597e

nameif inside

security-level 100

ip address 172.16.2.253 255.255.255.0

!

interface Vlan300

no forward interface Vlan200

nameif DMZ

security-level 50

ip address 172.16.3.253 255.255.255.0

!

boot system disk0:/asa913-k8.bin

boot config disk0:/startup-config.cfg

ftp mode passive

clock timezone GMT/BST 0

clock summer-time GMT/BDT recurring last Sun Mar 1:00 last Sun Oct 2:00

dns server-group DefaultDNS

domain-name test1.com

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

object network office1-int

host 172.16.2.1

object network firewall-dmz-gateway

host 172.16.3.253

object network firewall-internal-gateway

host 172.16.2.253

object network com1

host 192.168.223.227

object network web2-ext

host 192.168.223.201

object network web2-int

host 172.16.3.201

object network gateway

host 192.168.223.191

object network office1-int

host 172.16.2.1

object-group network DMZ_SUBNET

network-object 172.16.3.0 255.255.255.0

object-group service www tcp

port-object eq www

port-object eq https

access-list DMZ_access_in extended permit icmp any any

access-list DMZ_access_in extended permit ip any any

access-list outside_access_in extended permit tcp any object web2-ext eq www

pager lines 24

logging enable

logging asdm informational

mtu outside 1500

mtu inside 1500

mtu DMZ 1500 

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-714.bin

no asdm history enable

arp DMZ 172.16.4.199 001b.539c.597e alias

arp DMZ 172.16.3.199 001b.539c.597e alias

arp timeout 14400

no arp permit-nonconnected

!

object network web2-int

nat (DMZ,outside) static web2-ext service tcp www www

access-group outside_access_in in interface outside

access-group DMZ_access_in in interface DMZ

route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

route inside 172.168.3.0 255.255.255.0 192.168.223.191 1

timeout xlate 3:00:00

timeout pat-xlate 0:00:30

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

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

aaa authentication ssh console LOCAL

http server enable

http 192.168.223.227 255.255.255.255 outside

http 172.163.2.5 255.255.255.255 outside

http 172.163.2.5 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec security-association pmtu-aging infinite

crypto ca trustpool policy

telnet timeout 5

ssh 192.168.223.227 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 inside

ssh timeout 60

ssh key-exchange group dh-group1-sha1

console timeout 0

dhcpd address 172.16.2.10-172.16.2.10 inside

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

ntp server 176.58.109.199 source outside prefer

ntp server 81.150.197.169 source outside

ntp server 82.113.154.206

username xxxx password xxxxxxxxx encrypted

!

class-map DMZ-class

match any

!

!

policy-map global_policy

policy-map DMZ-policy

class DMZ-class

  inspect icmp

!

service-policy DMZ-policy interface DMZ

prompt hostname context

no call-home reporting anonymous

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:9c73fa27927822d24c75c49f09c67c24

: end

5 Accepted Solutions

Accepted Solutions

Also,

The ACL for the external inteface is using the wrong destination.

With the new ASA software the NAT is done before ACL so you will actually have to allow the traffic to the real/local IP address rather then the NAT IP address

You would need this rule

access-list outside_access_in extended permit tcp any object web2-int eq www

- Jouni

View solution in original post

Hi,

You seem to have both networks directly connected to the ASA. Therefore the ASA sees them directly in its routing table and doesnt need any additional routes configured for the networks. You only need the default route. No routes are needed for the directly connected networks.

You can confirm the rule from the external network with this command for example

packet-tracer input outside tcp 1.1.1.1 12345 192.168.223.201 80

This should tell if there is some problems with the ASA configurations or if the problem is perhaps somewhere else.

I would also suggest checking the ARP table of the ASA. As the DMZ server network is directly connected to the ASA this means that the ASA should see the server directly if its connected behind the DMZ interface.

show arp

Share the output of both commands here

- Jouni

View solution in original post

Hi,

You dont need the routes since they are directly connected networks and the ASA wont use them. Furthermore they cant work since they are pointing to an invalid gateway IP address.

So you can remove the routes you mentioned

no route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

no route DMZ 172.168.3.0 255.255.255.0 192.168.223.191 1

Seems that the ASA can see the DMZ servers local IP address/MAC correctly. Though you could still check with ICMP from the ASA to the DMZ host for which you are attempting connections

ping 172.16.3.201

You can also test the port on the host

ping tcp 172.16.3.201 80

You seem to have some problems with the ACL for some reason. Your configuration must have changed from the original one posted since this shows it being blocked. Seems that the ACL might not be attached to the "outside" interface anymore.

EDIT: Actually the routes above seem to be for different networks than the connected ones. Just looking that they start with 172.168. instead of 172.16. Those routes are actually for public networks since they dont fit to the private IP address range. Though the fact still remains that they can not be valid routes when they are pointing to an IP address that is not in that interfaces subnet.

- Jouni

Message was edited by: Jouni Forss

View solution in original post

Hi,

How will the setup change when you move it to a live network?

Are you going to place this ASA on the edge of the network and use public IP addresses on the ASAs "outside" interface or will the ASA be behind another NAT device?

Just wondering as you at the moment have Static NAT configured for your host but rest of your internal LAN and DMZ networks hosts done have any NAT configured. In other words if you connected this to some network the traffic from "inside" and "dmz" would show up with their original IP address to any device in front of the ASA. (while the single server would show up with the Static NAT IP)

Currently it seems to me that you have allowed all traffic from LAN and DMZ to the WAN (external network). Connections from DMZ to LAN are naturally denied do to the limitation of the license and the "no forward interface vlan200" command.

The settings you have for the SSH management of the ASA seem a bit wierd also

ssh 192.168.223.227 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 outside

ssh 172.16.3.253 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 inside

The first command makes sense as it contains as source address an IP address from the connected network. The second command looks like it has a typo perhaps as it contains an address 172.163.2.5? The third command also seems to be wrong as it contains an IP address located behind "dmz" but the command has been set to allow SSH management from this IP address from behind "outside" interface. The last command makes sense as it contains an IP address from "inside" interface.

Hope this helps

Please so remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed.

- Jouni

View solution in original post

Hi,

I was asking about the actual live setup just to confirm what is needed for the NAT. As you mention that the device is going to be at the edge of the network, notice that the device will need a Dynamic PAT configuration that provides the internal hosts (which dont have Static NAT) their public IP address for Internet connectivity.

I would suggest adding this configuration

object-group network PAT-SOURCE

description Dynamic PAT Source Networks

network-object 172.16.2.0 255.255.255.0

network-object 172.16.3.0 255.255.255.0

nat (any,outside) after-auto source dynamic PAT-SOURCE interface

This configuration will essentially define the source networks on the LAN/DMZ for the Dynamic PAT translation inside "object-group" and will then use the "object-group" in the actual "nat" command. This should handle Dynamic PAT for both the LAN and DMZ so any host there will have a translation on the firewall.

With regards to your ACL rules you will have to notice that you are missing one essential service/port from that list (IF you are not permitting all traffic). This is DNS which uses UDP/53.

I would perhaps consider allowing traffic/connections more freely from the LAN network behind "inside" interface and perhaps limiting the "DMZ" networks outbound connections. Notice that you will not have to take into account the DMZ to LAN traffic in the DMZ ACL since that traffic is already otherwise blocked as I mentioned before.

Notice also that both of your ACLs have the same source network which is the DMZ network. Your "inside" interfaces ACL should naturally have the network 172.16.2.0/24 as the source. Also both ACLs allow traffic to interface "outside". This does NOT mean that the traffic will be allowed to any network behind the "outside" interface. You need to allow the traffic to destination "any".

access-list DMZ_access_in extended permit icmp any any 

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq ssh

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq www

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq https

access-list DMZ_access_in extended permit udp 172.16.3.0 255.255.255.0 any eq domain

access-list inside_access_in extended permit icmp any any 

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq ssh

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq www

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq https

access-list inside_access_in extended permit udp 172.16.2.0 255.255.255.0 any eq domain

But as I said, I would consider allow traffic more freely from behind the "inside" interface. You might be using other services too like FTP or SMTP and others that would get blocked with the above ACLs.

If youre requirement was just as simple as allowing traffic the following way

  • LAN -> DMZ
  • LAN -> WAN
  • DMZ -> WAN

Then you could simply leave "inside" and "DMZ" without ACLs and just use the "outside" interface ACL to allow traffic to your servers for the services you require. Leaving the mentioned ACLs off would mean that the "security-level" value would determine where connections could form. As its from higher to lower that would mean the above requirements would be filled. If you need to deny some services but allow the rest then you naturally require ACLs.

With the ASDM allowing configuration there is still a typo there

http 172.163.3.200 255.255.255.255 DMZ

Notice that the source address is wrong. Its 172.163.3.200 when its supposed to be 172.16.3.200

- Jouni

View solution in original post

14 Replies 14

ziggyrosalsky
Level 1
Level 1

added:

route outside 0.0.0.0 0.0.0.0 192.168.223.191 1

still no luck

Hi,

Lets look at your interface configuration

interface Vlan100

nameif outside

security-level 0

ip address 192.168.223.200 255.255.255.0

!

interface Vlan200

mac-address 001b.539c.597e

nameif inside

security-level 100

ip address 172.16.2.253 255.255.255.0

!

interface Vlan300

no forward interface Vlan200

nameif DMZ

security-level 50

ip address 172.16.3.253 255.255.255.0

As you can see the networks 172.16.2.0/24 and 172.16.3.0/24 are directly connected.

What are these routes supposed to be?

route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

route inside 172.168.3.0 255.255.255.0 192.168.223.191 1

They are routes for networks which are both directly connected (and dont need static routes) and routed towards interface with a default gateway IP address that does not belong to that interface (belongs to "outside" interface)?

Also you should not see the ICMP coming from the "outside" interface if your host is connected to the DMZ Vlan of 300 and is trying to send ICMP to its ASA gateway interface IP address of 172.16.3.253.

- Jouni

Also,

The ACL for the external inteface is using the wrong destination.

With the new ASA software the NAT is done before ACL so you will actually have to allow the traffic to the real/local IP address rather then the NAT IP address

You would need this rule

access-list outside_access_in extended permit tcp any object web2-int eq www

- Jouni

Thanks for the quick respond.

I wanted to create 3 vlans - external internal and dmz  . simple pat to dmz ( ssh,web ) , internal to lan,dmz (ssh,web) , no access from dmz to internal of course ( licence restriction ) .that's it.

I was thinking that by adding those routes will achieve acccess from internal and dmz threw outside (192.168.223.200) to external gateway 192.168.223.191

route outside 0.0.0.0 0.0.0.0 192.168.223.191 1

route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

route DMZ 172.168.3.0 255.255.255.0 192.168.223.191 1

about nat I updated it and now have :

access-list outside_access_in extended permit tcp any object web2-int eq www

access-list outside_access_in extended permit tcp any object web2-int eq ssh

(still can't access web2-int from com1 - neither www nor ssh )

Hi,

You seem to have both networks directly connected to the ASA. Therefore the ASA sees them directly in its routing table and doesnt need any additional routes configured for the networks. You only need the default route. No routes are needed for the directly connected networks.

You can confirm the rule from the external network with this command for example

packet-tracer input outside tcp 1.1.1.1 12345 192.168.223.201 80

This should tell if there is some problems with the ASA configurations or if the problem is perhaps somewhere else.

I would also suggest checking the ARP table of the ASA. As the DMZ server network is directly connected to the ASA this means that the ASA should see the server directly if its connected behind the DMZ interface.

show arp

Share the output of both commands here

- Jouni

so from what you're saying i should do:

remove those :

no route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

no route DMZ 172.168.3.0 255.255.255.0 192.168.223.191 1

and leave only :

route outside 0.0.0.0 0.0.0.0 192.168.223.191 1

yes?

packet-tracer input outside tcp 1.1.1.1 12345 192.168.223$

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network web2-int

nat (DMZ,outside) static web2-ext net-to-net

Additional Information:

NAT divert to egress interface DMZ

Untranslate 192.168.223.201/80 to 172.16.3.201/80

Phase: 2

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: DMZ

output-status: up

output-line-status: up

Action: drop

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

show arp         

outside 192.168.223.191 001d.aaaa.66b0 40

outside 192.168.223.227 10dd.b1b6.2a96 288

DMZ 172.16.3.201 000c.2916.5432 8048

DMZ 172.16.4.199 001b.539c.597e alias -

DMZ 172.16.3.199 001b.539c.597e alias -

Hi,

You dont need the routes since they are directly connected networks and the ASA wont use them. Furthermore they cant work since they are pointing to an invalid gateway IP address.

So you can remove the routes you mentioned

no route inside 172.168.2.0 255.255.255.0 192.168.223.191 1

no route DMZ 172.168.3.0 255.255.255.0 192.168.223.191 1

Seems that the ASA can see the DMZ servers local IP address/MAC correctly. Though you could still check with ICMP from the ASA to the DMZ host for which you are attempting connections

ping 172.16.3.201

You can also test the port on the host

ping tcp 172.16.3.201 80

You seem to have some problems with the ACL for some reason. Your configuration must have changed from the original one posted since this shows it being blocked. Seems that the ACL might not be attached to the "outside" interface anymore.

EDIT: Actually the routes above seem to be for different networks than the connected ones. Just looking that they start with 172.168. instead of 172.16. Those routes are actually for public networks since they dont fit to the private IP address range. Though the fact still remains that they can not be valid routes when they are pointing to an IP address that is not in that interfaces subnet.

- Jouni

Message was edited by: Jouni Forss

you're right !!!.managed to lost

access-group outside_access_in in interface outside

readded

sorry for confusion:

here are updated results

packet-tracer input outside tcp 1.1.1.1 12345 192.168.223.201 80

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network web2-int

nat (DMZ,outside) static web2-ext net-to-net

Additional Information:

NAT divert to egress interface DMZ

Untranslate 192.168.223.201/80 to 172.16.3.201/80

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside_access_in in interface outside

access-list outside_access_in extended permit tcp any object web2-int eq www

Additional Information:

Phase: 3

Type: NAT

Subtype: per-session

Result: ALLOW

Config:      

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

class-map DMZ-class

match any

policy-map DMZ-policy

class DMZ-class

  inspect icmp

service-policy DMZ-policy interface DMZ

Additional Information:

Phase: 6

Type: NAT    

Subtype: rpf-check

Result: ALLOW

Config:

object network web2-int

nat (DMZ,outside) static web2-ext net-to-net

Additional Information:

Phase: 7

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:     

Result: ALLOW

Config:

Additional Information:

New flow created with id 484, packet dispatched to next module

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: DMZ

output-status: up

output-line-status: up

Action: allow

firewall200(config)# ping tcp 172.16.3.201 80             

Type escape sequence to abort.

No source specified. Pinging from identity interface.

Sending 5 TCP SYN requests to 172.16.3.201 port 80

from 172.16.3.253, timeout is 2 seconds:

?!???

Success rate is 20 percent (1/5), round-trip min/avg/max = 1/1/1 ms

firewall200(config)# ping 172.16.3.201

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.3.201, timeout is 2 seconds:

?!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms


Hi,

The "packet-tracer" test seems to indicate that the ASA configuration are ok.

Its however wierd that your server only replys to one TCP SYN and also partly to the ICMP

You should check the servers connectivity to the network. This doesnt seem to be a problem with the ASA configurations.

- Jouni

Thank you one more time for everthing. It is workingin indeed

Reason why maybe sometimes I had some 'weird' results was because I had all devices connected to the same switch.Separtated all networks to a different switches helped.Anyway if you could take a look one last time to my configuration and let me know if it's good enough to deploy it on live ( only www for all , ssh restricted from outside, lan to dmz) .Thanks one more time.

show run

: Saved

:

ASA Version 9.1(3)

!

hostname firewall200

domain-name test1.com

enable password xxxxxxxxxx encrypted

xlate per-session deny tcp any4 any4

xlate per-session deny tcp any4 any6

xlate per-session deny tcp any6 any4

xlate per-session deny tcp any6 any6

xlate per-session deny udp any4 any4 eq domain

xlate per-session deny udp any4 any6 eq domain

xlate per-session deny udp any6 any4 eq domain

xlate per-session deny udp any6 any6 eq domain

passwd xxxxxxxxxxxx encrypted

names

!

interface Ethernet0/0

switchport access vlan 100

!

interface Ethernet0/1

switchport access vlan 200

!

interface Ethernet0/2

switchport access vlan 200

!

interface Ethernet0/3

switchport access vlan 200

!

interface Ethernet0/4

switchport access vlan 300

!

interface Ethernet0/5

switchport access vlan 300

!

interface Ethernet0/6

switchport access vlan 300

!

interface Ethernet0/7

switchport access vlan 300

!

interface Vlan100

nameif outside

security-level 0

ip address 192.168.223.200 255.255.255.0

!

interface Vlan200

mac-address 001b.539c.597e

nameif inside

security-level 100

ip address 172.16.2.253 255.255.255.0

!

interface Vlan300

no forward interface Vlan200

nameif DMZ

security-level 50

ip address 172.16.3.253 255.255.255.0

!

boot system disk0:/asa913-k8.bin

boot config disk0:/startup-config.cfg

ftp mode passive

clock timezone GMT/BST 0

clock summer-time GMT/BDT recurring last Sun Mar 1:00 last Sun Oct 2:00

dns domain-lookup inside

dns domain-lookup DMZ

dns server-group DefaultDNS

name-server 8.8.8.8

name-server 8.8.4.4

domain-name test1.com

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

object network firewall-dmz-gateway

host 172.16.3.253

object network firewall-internal-gateway

host 172.16.2.253

object network com1

host 192.168.223.227

object network web2-ext

host 192.168.223.201

object network web2-int

host 172.16.3.201

object network gateway

host 192.168.223.191

object network office1-int

host 172.16.2.1

object-group network DMZ_SUBNET

network-object 172.16.3.0 255.255.255.0

object-group service www tcp

port-object eq www

port-object eq https

access-list DMZ_access_in extended permit icmp any any

access-list DMZ_access_in extended permit ip any any

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq ssh

access-list outside_access_in extended permit tcp any object web2-int eq www

access-list outside_access_in extended permit tcp any object web2-int eq ssh

pager lines 24

logging enable

logging asdm informational

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

icmp unreachable rate-limit 1 burst-size 1

icmp permit any inside

icmp permit any DMZ

asdm image disk0:/asdm-714.bin

no asdm history enable

arp DMZ 172.16.4.199 001b.539c.597e alias

arp DMZ 172.16.3.199 001b.539c.597e alias

arp timeout 14400

no arp permit-nonconnected

!

object network web2-int

nat (DMZ,outside) static web2-ext net-to-net

access-group outside_access_in in interface outside

access-group DMZ_access_in in interface DMZ

route outside 0.0.0.0 0.0.0.0 192.168.223.191 1

timeout xlate 3:00:00

timeout pat-xlate 0:00:30

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

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

aaa authentication ssh console LOCAL

http server enable

http 192.168.223.227 255.255.255.255 outside

http 172.163.2.5 255.255.255.255 outside

http 172.163.2.5 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec security-association pmtu-aging infinite

crypto ca trustpool policy

telnet timeout 5

ssh 192.168.223.227 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 outside

ssh 172.16.3.253 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 inside

ssh timeout 60

ssh key-exchange group dh-group1-sha1

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

ntp server 176.58.109.199 source outside prefer

ntp server 81.150.197.169 source outside

ntp server 82.113.154.206

username xxxxx password xxxxxxxxx encrypted

!

class-map DMZ-class

match any

!

!

policy-map global_policy

policy-map DMZ-policy

class DMZ-class

  inspect icmp

!

service-policy DMZ-policy interface DMZ

prompt hostname context

no call-home reporting anonymous

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:f264c94bb8c0dd206385a6b72afe9e5b

: end

Hi,

How will the setup change when you move it to a live network?

Are you going to place this ASA on the edge of the network and use public IP addresses on the ASAs "outside" interface or will the ASA be behind another NAT device?

Just wondering as you at the moment have Static NAT configured for your host but rest of your internal LAN and DMZ networks hosts done have any NAT configured. In other words if you connected this to some network the traffic from "inside" and "dmz" would show up with their original IP address to any device in front of the ASA. (while the single server would show up with the Static NAT IP)

Currently it seems to me that you have allowed all traffic from LAN and DMZ to the WAN (external network). Connections from DMZ to LAN are naturally denied do to the limitation of the license and the "no forward interface vlan200" command.

The settings you have for the SSH management of the ASA seem a bit wierd also

ssh 192.168.223.227 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 outside

ssh 172.16.3.253 255.255.255.255 outside

ssh 172.163.2.5 255.255.255.255 inside

The first command makes sense as it contains as source address an IP address from the connected network. The second command looks like it has a typo perhaps as it contains an address 172.163.2.5? The third command also seems to be wrong as it contains an IP address located behind "dmz" but the command has been set to allow SSH management from this IP address from behind "outside" interface. The last command makes sense as it contains an IP address from "inside" interface.

Hope this helps

Please so remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed.

- Jouni

Hi,

yeap it will be put on the edge of the internet with public IP for a firewall and

31 other public ip addresses to use in PAT rules (most of them will be used in DMZ, few in inside zone)

I’ll multiple this nat rule to achieve that:

object network web2-int

nat (DMZ,outside) static web2-ext net-to-net

About the traffic from inside and DMZ I was thinking about removing

access-list DMZ_access_in extended permit ip any any

and leave:

access-list DMZ_access_in extended permit icmp any any 

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq ssh

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq www

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq https

INSIDE:

access-list inside_access_in extended permit icmp any any 

access-list inside_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq ssh

access-list inside_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq www

access-list inside_access_in extended permit tcp 172.16.3.0 255.255.255.0 interface outside eq https

it should allow only ssh, http, https and ping isn’t?

Thanks for spotting the mess in ssh access area it’s sorted out now

ps

I have some weird issue with ASDM from DMZ

have this rule but it still keep blocking it

http 172.163.3.200 255.255.255.255 DMZ

ssh access is OK

ssh 172.16.3.200 255.255.255.255 DMZ

Hi,

I was asking about the actual live setup just to confirm what is needed for the NAT. As you mention that the device is going to be at the edge of the network, notice that the device will need a Dynamic PAT configuration that provides the internal hosts (which dont have Static NAT) their public IP address for Internet connectivity.

I would suggest adding this configuration

object-group network PAT-SOURCE

description Dynamic PAT Source Networks

network-object 172.16.2.0 255.255.255.0

network-object 172.16.3.0 255.255.255.0

nat (any,outside) after-auto source dynamic PAT-SOURCE interface

This configuration will essentially define the source networks on the LAN/DMZ for the Dynamic PAT translation inside "object-group" and will then use the "object-group" in the actual "nat" command. This should handle Dynamic PAT for both the LAN and DMZ so any host there will have a translation on the firewall.

With regards to your ACL rules you will have to notice that you are missing one essential service/port from that list (IF you are not permitting all traffic). This is DNS which uses UDP/53.

I would perhaps consider allowing traffic/connections more freely from the LAN network behind "inside" interface and perhaps limiting the "DMZ" networks outbound connections. Notice that you will not have to take into account the DMZ to LAN traffic in the DMZ ACL since that traffic is already otherwise blocked as I mentioned before.

Notice also that both of your ACLs have the same source network which is the DMZ network. Your "inside" interfaces ACL should naturally have the network 172.16.2.0/24 as the source. Also both ACLs allow traffic to interface "outside". This does NOT mean that the traffic will be allowed to any network behind the "outside" interface. You need to allow the traffic to destination "any".

access-list DMZ_access_in extended permit icmp any any 

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq ssh

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq www

access-list DMZ_access_in extended permit tcp 172.16.3.0 255.255.255.0 any eq https

access-list DMZ_access_in extended permit udp 172.16.3.0 255.255.255.0 any eq domain

access-list inside_access_in extended permit icmp any any 

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq ssh

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq www

access-list inside_access_in extended permit tcp 172.16.2.0 255.255.255.0 any eq https

access-list inside_access_in extended permit udp 172.16.2.0 255.255.255.0 any eq domain

But as I said, I would consider allow traffic more freely from behind the "inside" interface. You might be using other services too like FTP or SMTP and others that would get blocked with the above ACLs.

If youre requirement was just as simple as allowing traffic the following way

  • LAN -> DMZ
  • LAN -> WAN
  • DMZ -> WAN

Then you could simply leave "inside" and "DMZ" without ACLs and just use the "outside" interface ACL to allow traffic to your servers for the services you require. Leaving the mentioned ACLs off would mean that the "security-level" value would determine where connections could form. As its from higher to lower that would mean the above requirements would be filled. If you need to deny some services but allow the rest then you naturally require ACLs.

With the ASDM allowing configuration there is still a typo there

http 172.163.3.200 255.255.255.255 DMZ

Notice that the source address is wrong. Its 172.163.3.200 when its supposed to be 172.16.3.200

- Jouni

Hi,

Excellent tips.Thank you very much. Probably will use non ACL tip on live deploy. Anyway. One more time BIG THANKS.

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:

Review Cisco Networking products for a $25 gift card