cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
915
Views
5
Helpful
6
Replies

A few questions about ASA5510 NAT, PAT, and passing traffic

gwhuang5398
Level 2
Level 2

I installed a new Internet router and ASA5510 cluster as the following, if looking from ISP:

ISP -- router -- ASA5510 -- edge 6509

router Loopback: 10.1.1.4

router LAN port: 99.100.100.1

router sends 99.100.100.0/24 to ISP

ASA management: 10.1.1.2

ASA outside: 99.100.100.2

ASA inside: 10.10.10.2

ASA DMZ: 192.168.1.1 (DMZ subnet 192.168.1.0/24)

6509 management: 10.1.1.1

6509 has 10.10.10.1 talking with ASA inside

I have verified routing between router, ASA, and 6509 is fine, and ASA clustering is fine too.

This is brand new ASA, so except for interface and routing configurations, everything else is still the default with a new box.

Issue 1: can't ping or telnet from 6509 to any router IP, or ASA outside and DMZ IP.

6509 has correct routes to outside IP's. Do I need to configure ACL to ASA outside interface and DMZ interface, to allow ICMP, Telnet, SSH, etc coming into ASA inside? Does this have anything to do with IP Inspection also?

Issue 2: can't telnet or ssh from ASA

I can ping from ASA to any of those addresses, but seems ASA does not accept telnet or ssh command when doing it from itself. Is this true?

Issue 3: NAT and PAT from DMZ to outside

I want to static NAT some DMZ hosts and PAT everything else, such as:

static (DMZ, outside) 99.100.100.20 192.168.1.20

static (DMZ, outside) 99.100.100.21 192.168.1.21

global (outside) 1 99.100.100.250

nat (inside) 1 192.168.1.0 255.255.255.0

Do I need to have an ACL to exclude the statically NATTed address from PAT?

Issue 4: prevent PAT for traffic going through IPSec tunnel

This is from inside to outside. All internal users are PATTed when going to Internet, but some traffic going from internal to clients needs to go through IPSec tunnel. So I should block those traffic from being PATTed. Is that right?

access-list IPSec-traffic extended permit ip any 172.20.20.0 255.255.255.0

access-list IPSec-traffic extended permit ip any 172.26.20.0 255.255.255.0

nat (inside) 0 access-list IPSec-traffic

global (outside) 2 interface

nat (inside) 2 0.0.0.0 0.0.0.0

The same access-list IPSec-traffic is used to crypto-map on the outside interface to activate IPSec tunnel.

Is this the right configuration?

Thanks a lot for any help

6 Replies 6

JORGE RODRIGUEZ
Level 10
Level 10

Hi, you have few things going.. read the links provided.

Issue 1: can't ping or telnet from 6509 to any router IP, or ASA outside and DMZ IP.

You can allow ICMP either by acl or icmp inspection in your ASA.

policy-map global_policy

class inspection_default

inspect icmp

AS for pinging the DMZ interface from your inside interface is not posible as this is normal behaviour, you should however be able to ping DMZ interface from within DMZ network or ping hosts in the DMZ from hosts coming from your inside interface if your NATing is all configured.

handling icmps and trace routes with ASA's

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

If you want to telnet to asa from outside internet to ASA management interface it needs to be done through vpn connection either throught RA VPN or L2L VPN then you can telnet to the asa management interface ..for this you will need statement in asa management-

access management provided you have defined the management interface as only management.

See SSH and Telnet implementation

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008069bf1b.shtml#telnet

Issue 2: can't telnet or ssh from ASA

I can ping from ASA to any of those addresses, but seems ASA does not accept telnet or ssh command when doing it from itself. Is this true?

That is TRUE, you cannot from the ASA or PIX itself initiate a ssh/telnet session to another device..

Traceroutes is feasable from within the PIX/ASA if running code 7.x or above , in PIX code 6.x or bellow you could trace route from it.

Issue 3: NAT and PAT from DMZ to outside

Your static NAT is fine

your PAT is not quite right but almost there.

you have this nat (inside) 1 192.168.1.0 255.255.255.0, not right, you need to either replace the IP network with 10.10.10.0/24 pertaining to inside interface or your interface name from inside to DMZ as 192.168.1.0 is your DMZ network.

this should be if you want to PAT everything in the 10.10.10.0 network

nat (inside) 1 10.10.10.0

this would be for PATing DMZ network with global ID 1

nat (dmz) 1 192.168.1.0 255.255.255.0

Issue 4: prevent PAT for traffic going through IPSec tunnel

nat 0 statement (inside) 0 access-list IPSec-traffic is enough for your l2l tunnel..you don't need global (outside) 2 interface nor nat (inside) 2 0 0

your nonat exempt acl should be: if you are allowing far end to access hosts in the 10.10.10.0 net.

access-list IPSec-traffic extended permit ip 10.10.10.0 255.255.255.0 172.20.20.0 255.255.255.0

access-list IPSec-traffic extended permit ip 10.10.10.0 255.255.255.0 172.26.20.0 255.255.255.0

Internal internet traffic will be PATed with your global (outside) 1 99.100.100.250 and nat (inside) 1 192.168.1.0 255.255.255.0

nat 0 is the first to process in nat order , so your ipsec traffci between your asa and far end should be fine and again internal users will go out internet not through the tunnel but normal means.

Regards

Jorge Rodriguez

Hi Thanks much for the help.

So if nat 0, static NAT, and PAT are all configured between inside and outside interfaces, nat 0 is the first to be processed, and PAT is the last?

If ASA has operations of "ACL in" on the inside interface, NAT/PAT, IPSec, routing, what's the processing sequence on the ASA? especially between NAT and IPSec. I was wondering if IPSec is checking native IP or NATTed IP for activating nogotiation and peering.

I have tried inbound ACL on the outside and DMZ interface to allow traffic coming to inside, as following:

access-list Outside-In extended permit ip 99.100.100.0 255.255.255.0 any

access-list Outside-In extended permit ip any 99.100.100.0 255.255.255.0

access-list Outside-In extended permit ip 10.1.1.0 255.255.255.0 any

(first line allows ping and telnet from router LAN interface. Second line allows Internet traffic to NATTed and PATTed addresses in 99.100.100.0/24. The 3rd line allows ping from WAN router loopback to come in).

access-list DMZ-In extended permit ip 192.168.1.0 255.255.255.0 any

(allows any DMZ initiated traffic to come to inside).

First, do the ACL look right?

I can now ping and telnet from internal to WAN router loopback, but I still can't ping from internal to the DMZ switch (192.168.1.3), which is connected to ASA DMZ interface and default gateway to DMZ interface.

I have not tried icmp inspection yet. The outside ACL and DMZ ACL are the same manner. But don't know why ping from internal host to DMZ host still not working.

Thanks again

1. access-list Outside-In extended permit ip 10.1.1.0 255.255.255.0 any

I am not sure what the purpose of the above line is. This acl seems to be applied on the internet facing the internet but, the source IP address belongs to the private address space. Just FYI.

2. As to why you are unable to ping from the inside to the dmz switch. I am not sure. Do you have an acl tied to the inside interface? Is that allowing ICMP through? The replies from the DMZ to the inside will be allowed with the acl that you have listed

access-list DMZ-In extended permit ip 192.168.1.0 255.255.255.0 any

Can you ping the dmz switch from the ASA?

Are the inside hosts initiating icmp live behind the 6509? If so, does the 6509 have a route to the 192.168.1.0/24 network?

Try to issue a ping to the dmz switch from an inside host, preferably in the same subnet as the inside interface with a -t option (continuous ping) and watch the logs in the ASA.

conf t

logging on

logging buffered 7

sh logg | i x.x.x.x

where x.x.x.x is the ip address of the inside host.

3. Yes, nat 0 will be processed first.

You can read about the order of operation here:

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/cfgnat.html#wp1042696

Thanks much for the help.

1. access-list Outside-In extended permit ip 10.1.1.0 255.255.255.0 any

The reason I had it to the outside interface is the WAN routers have loopback0 in 10.1.1.0/24 for management access. So I thought if I ping or telnet to WAN router's loopback from inside, the ACL can allow return traffic back into inside. Does it sound right?

2. I don't have any ACL tied to the inside interface. Should I have one? I'm not sure about it since inside interface has the highest security level.

3. I can ping the dmz switch from the ASA and vise versa. For the inside hosts behind 6509, the 6509 have routes to ASA outside, and DMZ subnets. I have OSPF running among WAN routers, ASA, and 6509.

Another way to reach DMZ from inside may be to NAT DMZ addresses to inside addresses, but I prefer to use real addresses when going between inside and DMZ.

Is there any tricks to have traffic flow between inside and DMZ?

Thanks again

1. Makes sense. Thanks for explaining.

2. There is no need for an ACL on the inside interface with a 100 level sec. High to low is automatically allowed in the PIX/ASA platform

3. If you do a trace from the inside host destined to the DMZ does it take the FW path to get there? The best thing to do is to collect captures on the inside and dmz interface on the ASA and watch the logs.

conf t

loggin on

loggin buffered 7

sh logg | i x.x.x.x

where x.x.x.x is the ip address of the inside host.

There is no need to translate the dmz host to look like the inside ip address. We do not translate from low to high usually. The inside hosts should look like themselves when going to the DMZ I hope you have static identity translation for that.

example:

static (inside,dmz) 10.10.10.0 10.10.10.0 net 255.255.255.0

where 10.10.10.0/24 is the inside subnet

As far as captures you can read here in this link below:

http://analysisandreview.com/cisco/how-to-configure-a-packet-capture-in-the-cisco-asa/

Thanks again for the explanation.

I don't have identity translation configured when going from inside to DMZ. I wasn't aware I needed to. I wondered how ASA responded to traffic from inside to DMZ when there wasn't any sort of translation configured at all.

I'll try this tomorrow at work:

static (inside,dmz) 10.10.10.0 10.10.10.0 net 255.255.255.0

Thanks a lot.

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: