Help with Site to Site VPN on ASA5505

Steven Williams · ‎11-03-2011

Hey guys,

Hope all is well on netpro, I really need some help. I have been trying to work on a site to site VPN for almost a full two weeks now and can't seem to get any further than I am now. I am hoping someone can take a look at the thread below and help me out. I have started over about 100 times and always come to the same place...I can get the VPN connection active, but cannot pass traffic at all or correctly.

https://learningnetwork.cisco.com/thread/36319?tstart=0

Here is my latest configuration for my ASA:

: Saved
:
ASA Version 7.2(2)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Vlan1
nameif inside
security-level 100
ip address 10.5.12.251 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 1.1.1.2 255.255.255.252
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
shutdown
!
interface Ethernet0/3
shutdown
!
interface Ethernet0/4
shutdown
!
interface Ethernet0/5
shutdown
!
interface Ethernet0/6
shutdown
!
interface Ethernet0/7
shutdown
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
access-list OUTSIDE_CRYPTOMAP extended permit ip 192.168.133.0 255.255.255.0 192.168.134.0 255.255.255.0
access-list POLICY_NAT extended permit ip 10.5.12.0 255.255.255.0 192.168.134.0 255.255.255.0
access-list INSIDE_NAT_STATIC extended permit ip 192.168.134.0 255.255.255.0 10.0.0.0 255.255.255.0
pager lines 24
mtu inside 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-524.bin
no asdm history enable
arp timeout 14400
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) 192.168.133.0 access-list POLICY_NAT
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
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 uauth 0:05:00 absolute
http server enable
http 10.5.12.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ASA_VPN_TO_SONIC esp-3des esp-md5-hmac
crypto map OUTSIDE_MAP 20 match address OUTSIDE_CRYPTOMAP
crypto map OUTSIDE_MAP 20 set pfs
crypto map OUTSIDE_MAP 20 set peer 2.2.2.2
crypto map OUTSIDE_MAP 20 set transform-set ASA_VPN_TO_SONIC
crypto map OUTSIDE_MAP interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 100
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
pre-shared-key *
telnet timeout 5
ssh timeout 5
console timeout 0

!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:6830d2eaae271ea805d9357910b5dcdf
: end

The real internal IP address range behind the ASA is 10.5.12.0/24 and that should be natted to 192.168.133.0/24 when leaving the ASA to cross the tunnel.

The remote internal address range is a combination of 10.x.0.0/16 addresses and those need to be natted to 192.168.134.0/24 when leaving the remote Sonicwall firewall. So to make that simple I want to just NAT the entire 10.0.0.0/8 subnet.

I can't wrap my head around how the ASA knows to use the tunnel for all 10.0.0.0/8 traffic when itself is connected to a 10.5.12.0/24 subnet. I assume routing.

Please let me know anymore info that is needed.

ajay chauhan · ‎11-03-2011

Hi,

frist of all i would suggest to remove pfs both side and try also verify remote side ACL.

Also from your end you can run this and paste the output here .

# packet-tracer input inside tcp 10.5.12.1 1025 192.168.134.1 80

This will show you where the packet is getting stuck.

Thanks

Ajay

Steven Williams · ‎11-03-2011

ciscoasa# packet-tracer input inside tcp 10.5.12.1 1025 192.168.134.1 80

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.134.0 access-list POLICY_NAT
match ip inside 10.5.12.0 255.255.255.0 outside 10.0.0.0 255.0.0.0
static translation to 192.168.134.0
translate_hits = 136, untranslate_hits = 0
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: DROP
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
match ip inside any outside any
dynamic translation to pool 1 (No matching global)
translate_hits = 552, untranslate_hits = 0
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ajay chauhan · ‎11-03-2011

Just give it a try .

Remove -

nat (inside) 1 0.0.0.0 0.0.0.0

Since this is no where matching after removing the output of packet tracer please.

Thanks

Ajay

Steven Williams · ‎11-03-2011

Ok so that seemed to work....well everything says allow now...so does that mean the ASA is working correctly?

ciscoasa# packet-tracer input inside tcp 10.5.12.1 1025 192.168.134.1 80

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.134.0 access-list POLICY_NAT
match ip inside 10.5.12.0 255.255.255.0 outside 10.0.0.0 255.0.0.0
static translation to 192.168.134.0
translate_hits = 194, untranslate_hits = 0
Additional Information:

Phase: 5
Type: HOST-LIMIT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 777, packet dispatched to next module

Phase: 8
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 173.167.173.210 using egress ifc outside
adjacency Active
next-hop mac address 78cd.8e65.a4a2 hits 511

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Steven Williams · ‎11-03-2011

So how does the ASA know that if it needs to ping, lets say 10.101.1.1 that it needs to use the VPN tunnel to get there?

acomiskey · ‎11-03-2011

It doesnt know. You have told it that traffic to 192.168.134.0 is to be encrypted. This is the issue you will have in my opinion. The remote end would have to translate that destination address back to 10.101.1.1. Then when the remote end replied, your ASA would have to translate the destination of 192.168.133.x back to 10.5.12.x. In my opinion, if there is no 10.5.12.0/24 network on the remote end, I would remove the policy nat and just send the source of 10.5.12.x over the vpn and use the destination of 10.101.x.x.

Steven Williams · ‎11-03-2011

Well this is where the problem lies. My remote network does not have a 10.5.12.0/24 network, but it has:

10.101.0.0

10.102.0.0

10.103.0.0

10.110.0.0

10.111.0.0

10.113.0.0

10.118.0.0

So that being said I want to just sum these all up by using 10.0.0.0/8 which the 10.5.12.0/24 network belongs too.

acomiskey · ‎11-03-2011

Steven, I assume you have a similar static policy nat configuration on the sonicwall end as well?

acomiskey · ‎11-03-2011

I think I may finally understand this myself.

With this config

access-list POLICY_NAT extended permit ip 10.5.12.0 255.255.255.0 192.168.134.0 255.255.255.0

static (inside,outside) 192.168.133.0 access-list POLICY_NAT

You are translating your source address of 10.5.12.x to 192.168.133.x when going to 192.168.134.y.

Lets say the sonicwall side was configured like so.

access-list POLICY_NAT extended permit ip 10.0.0.0 255.0.0.0 192.168.133.0 255.255.255.0

static (inside,outside) 192.168.134.0 access-list POLICY_NAT

When it arrives at the sonicwall, it should translate only the network bits of the address. So my guess is it would translate the destination to 10.168.134.y. Which obviously won't work. Try this.

ASA

access-list POLICY_NAT extended permit ip 10.5.12.0 255.255.255.0 192.0.0.0 255.0.0.0

static (inside,outside) 192.168.133.0 access-list POLICY_NAT

Sonicwall equivalent.

access-list POLICY_NAT extended permit ip 10.0.0.0 255.0.0.0 192.168.133.0 255.255.255.0

static (inside,outside) 192.0.0.0 access-list POLICY_NAT

Now if you initinate from 10.5.12.x to 192.101.x.y, the source will be translated to 192.168.133.x. At sonicwall the destination will be translated to 10.101.x.y.

The reply from 10.101.x.y will be translated to 192.101.x.y. At ASA the destination will be translated back from 192.168.133.x to 10.5.12.x.

I will try to test this tomorrow, I could very well be completely full of it.

Steven Williams · ‎11-04-2011

any luck on this?

Steven Williams · ‎11-04-2011

acomiskey wrote:
I think I may finally understand this myself. 
With this config
access-list POLICY_NAT extended permit ip 10.5.12.0 255.255.255.0 192.168.134.0 255.255.255.0
static (inside,outside) 192.168.133.0 access-list POLICY_NAT
You are translating your source address of 10.5.12.x to 192.168.133.x when going to 192.168.134.y.
Lets say the sonicwall side was configured like so.
access-list POLICY_NAT extended permit ip 10.0.0.0 255.0.0.0 192.168.133.0 255.255.255.0
static (inside,outside) 192.168.134.0 access-list POLICY_NAT
When it arrives at the sonicwall, it should translate only the network bits of the address. So my guess is it would translate the destination to 10.168.134.y. Which obviously won't work. Try this.
ASA
access-list POLICY_NAT extended permit ip 10.5.12.0 255.255.255.0 192.0.0.0 255.0.0.0
static (inside,outside) 192.168.133.0 access-list POLICY_NAT
Sonicwall equivalent.
access-list POLICY_NAT extended permit ip 10.0.0.0 255.0.0.0 192.168.133.0 255.255.255.0
static (inside,outside) 192.0.0.0 access-list POLICY_NAT
Now if you initinate from 10.5.12.x to 192.101.x.y, the source will be translated to 192.168.133.x. At sonicwall the destination will be translated to 10.101.x.y.
The reply from 10.101.x.y will be translated to 192.101.x.y. At ASA the destination will be translated back from 192.168.133.x to 10.5.12.x.
I will try to test this tomorrow, I could very well be completely full of it.

When it arrives at the sonicwall, it should translate only the network bits of the address. So my guess is it would translate the destination to 10.168.134.y. Which obviously won't work. Try this.

I assume you meant 192.168.134.y......why wont this work?

Steven Williams · ‎11-04-2011

What would be the destination network on the sonicwall? The NAT address range on the ASA or the real LAN address range? This is where I get confused.

ajay chauhan · ‎11-04-2011

NAT Address range on ASA would be destination since packet reached on Sonicwall with identity of

192.168.134.0/24.

Steven Williams · ‎11-04-2011

Ok well I have everything set on each end and verified, but still cannot get traffic across the VPN tunnel? Do I have to add static routes to the routing table? What are some show commands or debug commands that I can use to see if the traffic is trying to cross the VPN tunnel?