01-27-2014 03:54 AM - edited 03-11-2019 08:36 PM
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
Solved! Go to Solution.
01-27-2014 05:44 AM
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
01-27-2014 06:23 AM
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
01-27-2014 06:41 AM
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
01-28-2014 12:52 AM
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
01-28-2014 08:16 AM
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
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
01-27-2014 05:34 AM
added:
route outside 0.0.0.0 0.0.0.0 192.168.223.191 1
still no luck
01-27-2014 05:40 AM
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
01-27-2014 05:44 AM
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
01-27-2014 06:08 AM
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 )
01-27-2014 06:23 AM
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
01-27-2014 06:36 AM
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 -
01-27-2014 06:41 AM
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
01-27-2014 07:01 AM
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
01-27-2014 07:38 AM
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
01-28-2014 12:28 AM
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
01-28-2014 12:52 AM
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
01-28-2014 06:56 AM
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
01-28-2014 08:16 AM
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
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
01-29-2014 04:23 AM
Hi,
Excellent tips.Thank you very much. Probably will use non ACL tip on live deploy. Anyway. One more time BIG THANKS.
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: