cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
906
Views
0
Helpful
3
Replies

ASA VPN (NAT issue?)

Nick Currie
Level 1
Level 1

Hi folks, I was hoping sopmeone on these forums might be able to help. I have a bit of an issue with a config for our ASA5510, its running 8.2(1)

I have setup a VPN tunnel to an offsite vyatta firewall. The tunnel is up.

ABN-FW3-CISCO-ASA5510# show crypto ipsec sa
interface: outside
Crypto map tag: VPN_Zettagrid_Map, seq num: 10, local addr: 116.212.X.X
access-list VPN_cryptomap permit ip 192.9.0.0 255.255.0.0 192.168.11.0 255.255.255.0
local ident (addr/mask/prot/port): (192.9.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.11.0/255.255.255.0/0/0)
current_peer: 119.252.X.X
#pkts encaps: 14, #pkts encrypt: 14, #pkts digest: 14
#pkts decaps: 16, #pkts decrypt: 16, #pkts verify: 16
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 14, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 116.212.X.X, remote crypto endpt.: 119.252.X.X
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: 670F3BF5

Now I can pass information from the vyatta 119.252.X.X to our internal networks (192.9.0.0/16) (yeah I know these are a public range, but this is the environment I have inherited, I am underway with a project to put private network addresses in place but its not finished quite yet.)

The problem seems to be passing info from the ASA to the internal network behind the vyatta - 192.168.11.0/24.

When I check my syslog I get the following error: (this example was an attempted mstsc connection)
: Inbound TCP connection denied from 192.9.216.190/60660 to 192.168.11.101/3389 flags SYN on interface inside

Now Im guessing this SYN message means that the ASA is attempting to NAT my outgoing packets.. which is strange because I have setup a nonat rule. But when I do a show nat this is the result:

ABN-FW3-CISCO-ASA5510# show nat inside
match ip inside 192.9.0.0 255.255.0.0 outside 192.168.11.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 37 (this value is not changing)

Here is my config for the NAT


access-list Inside_nat0_outbound extended permit ip 192.9.0.0 255.255.0.0 192.168.11.0 255.255.255.0
access-list Inside_nat0_outbound extended permit ip 10.0.0.0 255.255.255.0 192.168.11.0 255.255.255.0
access-list Inside_nat0_outbound extended permit ip 192.10.201.0 255.255.255.0 192.168.11.0 255.255.255.0

(I have a seperate ACL for interesting traffic)

access-list VPN_cryptomap extended permit ip 192.9.0.0 255.255.0.0 192.168.11.0 255.255.255.0

access-list VPN_cryptomap extended permit ip 10.0.0.0 255.0.0.0 192.168.11.0 255.255.255.0

access-list VPN_cryptomap extended permit ip 192.10.201.0 255.255.255.0 192.168.11.0 255.255.255.0

global (outside) 1 interface
nat (inside) 0 access-list Inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 172.30.3.0 255.255.255.0
nat (management) 1 192.10.201.0 255.255.255.0
nat (dmz2) 1 172.30.2.0 255.255.255.0
static (inside,dmz) 192.9.0.0 192.9.0.0 netmask 255.255.0.0

Im guessing that one of these rules is conflicting? Does the nat (inside) 0 access-list Inside_nat0_outbound take precedence over nat (inside) 1 0.0.0.0 0.0.0.0 ?

I can post more config if required, any help at this stage would be much appreciated

1 Accepted Solution

Accepted Solutions

ajay chauhan
Level 7
Level 7

Humm looks like you are initiating traffic from 192.9.0.0 to 192.168.11.0 that seems to be blocked by ACL on inside interface .

Please paste ACL config or see if thats blocking this traffic.

Thanks

Ajay

View solution in original post

3 Replies 3

ajay chauhan
Level 7
Level 7

Humm looks like you are initiating traffic from 192.9.0.0 to 192.168.11.0 that seems to be blocked by ACL on inside interface .

Please paste ACL config or see if thats blocking this traffic.

Thanks

Ajay

Mr_Helpful
Level 1
Level 1

I agree with Ajay that your NAT-config looks fine, and the error seems to point to some kind of ACL/firewall issue.

And to answer your question: yes, the nat (inside) 0 takes precedence over the nat (inside) 1 statement.

The funny detail is that your tunnel has non-zero values for #pkts encaps/decaps, so there is definitely some traffic going through it in both directions; which does not necessarily mean there is bi-directional traffic, unfortunately.

Ok it was a config error on the PIX. I had made an error on the static route:

I had route inside 192.168.11.0 255.255.255.0 119.252.X.X 1

where I needed

route outside 192.168.11.0 255.255.255.0 119.252.X.X 1

I discovered this when I enabled intra-interface traffic and checked the syslog, I could see it was attempting to route the traffic back OUT of the inside interface.

Thanks for your help guys!

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: