NAT control issue - traffic with and w/o nat allowed

mitchrussell42 · ‎09-26-2011

Inside, outside, and two discrete DMZs. Inside 100, outside 0, DMZ1 50, DMZ2 40. DMZ1 -> 192.168.7.0/24. DMZ2 -> 192.168.8.0/24.

Wireless APs on DMZ2 - using public DNS, want to hit FTP server on DMZ1 with public address:

nat (DMZ2,DMZ1) source static WAPs WAPs destination static ftp.contres.com criftp service ftp-service ftp-service

criftp is 192.168.7.130.

I'm bench testing this config to replace a PIX. New ASA 5520s with 8.4(2).

I can ftp from 192.168.8.32 to 174.76.57.40 and see the connection on the FTP server.

I can also ftp from 192.168.8.32 to 192.168.7.130 and see the connection on the same FTP server.

Packet trace does not show this to be possible.

But, it is real. There are no bypass paths in my config, the connections show on the firewall for each test case.

HELP!

brquinn · ‎09-27-2011

We still don't know all the IP addressing. Can you tell us how the WAPs object and the ftp.contres.com object are defined? It is always best when troubleshooting these issues to get the full 'show nat detail output'. This will tell us if any other rules are being matched prior the the rule in question.

Thanks,

Brendan

mitchrussell42 · ‎09-27-2011

I'm just going to open a ticket on this item. I'd rather not put too much information on a public forum.

brquinn · ‎09-27-2011

I understand. For your own troubleshooting, the 'show nat detail' command is your friend. Go through the Source pool for each nat entry and try and locate each hit for the Source IP address you are testing. Then check the destination and make sure it matches what is being received in the packets.

Remember, the Manual Nat statements are processed in order. So make sure there are no Manual Nat entries above the entry you wish to use that match the traffic in question.

Good luck!

Thanks,

Brendan

mitchrussell42 · ‎09-28-2011

OK, here is an instance with all fake info:

PC3 <--> ASA <--> PC2

PC3 is 5.5.5.2, WinXP, gw 5.5.5.1

PC2 is 192.168.200.100, Ubuntu, gw 192.168.200.1

ASA is 5.5.5.1 outside, 192.168.200.1 inside.

From PC3, I can connect to the NAT of PC2 at 5.5.5.50 with ftp.

Also, from PC3, I can connect to the real address of PC2 at 192.168.200.100 with ftp.

I need to use this style of NAT so I can map three outside IPs with three different services to the same real server.

Isn't this a bug for the private addresses to be exposed to the outside? I know that these are normally routed over the Internet, but routing tables can be manipulated.

Config:

interface Ethernet0/0

switchport access vlan 2

!

interface Ethernet0/1

!

interface Ethernet0/2

!

interface Ethernet0/3

!

interface Ethernet0/4

!

interface Ethernet0/5

!

interface Ethernet0/6

!

interface Ethernet0/7

!

interface Vlan1

nameif inside

security-level 100

ip address 192.168.200.1 255.255.255.0

!

interface Vlan2

nameif outside

security-level 0

ip address 5.5.5.1 255.255.255.0

!

boot system disk0:/asa842-k8.bin

ftp mode passive

object network obj_any

subnet 0.0.0.0 0.0.0.0

object network public-web

host 5.5.5.55

object network public-ftp

host 5.5.5.50

object network private-server

host 192.168.200.100

object service ftp-obj

service tcp destination eq ftp

access-list outside_access_in extended permit tcp any object private-server eq ftp

access-list outside_access_in extended deny ip any any

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-645.bin

no asdm history enable

arp timeout 14400

nat (outside,inside) source static any any destination static public-ftp private-server service ftp-obj ftp-obj

!

object network obj_any

nat (inside,outside) dynamic interface

access-group outside_access_in in interface outside

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 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

http server enable

http 192.168.1.0 255.255.255.0 inside

http 192.168.200.0 255.255.255.0 inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

telnet timeout 5

ssh timeout 5

console timeout 0

dhcpd auto_config outside

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

webvpn

mitchrussell42 · ‎09-28-2011

Workaround - black hole technique

If you packet trace both scenarios, you find the 5.5.5.50 access does a translation, but no translation is attempted for 192.168.200.100. Both then match the ACL.

So, put a dummy translation into the NAT statements. I used:

nat (outside,inside) source static any any destination static private-server black-hole service ftp-obj ftp-obj

object network black-hole

host 172.32.254.254

Now the access to the private address of the server gets translated to a bad address, and dies the death it deserves.

I still contend that allowing access w/o NAT is an unwanted feature on Cisco's part.