cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
672
Views
0
Helpful
4
Replies

Site to Site tunnelling of all traffic..

connectone
Level 4
Level 4

Hello:

I have a branch site, and a main datacenter site.  All traffic, VPN or not needs to go to the datacenter site now and not getting NATed from the branch site anylonger on its own ASA 5505 to the internet.

I have been looking at some configs, and think I have the traffic flowing to the datacenter ASA 5510 no problem, but the traffic is not returning.  I see packets being encrypted on the branch side, and decrypted on the datacenter side, but 0 packets encrypted on the datacenter side so it is like the traffic is not making it back to the VPN tunnel to return to the branch.

Here is the branch config that is current now.

access-list inside_nat0_outbound extended permit ip 192.168.2.0 255.255.255.0 172.20.10.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 192.168.2.0 255.255.255.0 10.1.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 192.168.2.0 255.255.255.0 any

access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 172.20.10.0 255.255.255.0
access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 10.1.0.0 255.255.0.0
access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 any

global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 192.168.2.0 255.255.255.0

crypto map outside_map 20 match address outside_cryptomap_20
crypto map outside_map 20 set peer x.x.x.x
crypto map outside_map 20 set transform-set 3DES-MD5
crypto map outside_map interface outside

I see the traffic going into the VPN tunnel and the other ASA shows the same thing so I know the tunnel for this any traffic comes up.  Here is the datacenter side.

access-list inside_nat0_outbound extended permit ip 172.20.10.0 255.255.254.0 192.168.2.0 255.255.254.0
access-list inside_nat0_outbound extended permit ip 172.20.10.0 255.255.254.0 10.1.0.0 255.255.0.0

access-list outside_cryptomap_10 extended permit ip 172.20.10.0 255.255.254.0 192.168.2.0 255.255.255.0
access-list outside_cryptomap_10 extended permit ip 10.1.0.0 255.255.0.0 192.168.2.0 255.255.255.0
access-list outside_cryptomap_10 extended permit ip any 192.168.2.0 255.255.255.0

global (outside) 1 38.x.x.12 netmask 255.255.255.192
global (outside) 2 8.y.y.12 netmask 255.255.255.0
nat (outside) 2 192.168.2.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 172.20.10.0 255.255.255.0

crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer x.x.x.x
crypto map outside_map 10 set transform-set 3DES-MD5
crypto map outside_map interface outside

Both ASA's, 5505 in branch and 5510 in datacenter have the same-security-traffic permit intra-interface command set.

The NAT on the outside seems to be working.  I see in a debug that the address from the branch is getting nat translated.

Oct 22 2010 09:31:44: %ASA-6-305011: Built dynamic ICMP translation from outside:192.168.2.74/1 to outside:8.x.x.12/3
Oct 22 2010 09:31:44: %ASA-6-302020: Built inbound ICMP connection for faddr 192.168.2.74/1 gaddr 8.8.8.8/0 laddr 8.8.8.8/0
Oct 22 2010 09:31:46: %ASA-6-305011: Built dynamic UDP translation from outside:192.168.2.73/51814 to outside:8.x.x.12/1026
Oct 22 2010 09:31:46: %ASA-6-302015: Built inbound UDP connection 99342996 for outside:192.168.2.73/51814 (8..x.x.12/1026) to outside:208.67.222.222/53 (208.67.222.222/53
Oct 22 2010 09:31:48: %ASA-6-302021: Teardown ICMP connection for faddr 192.168.2.74/1 gaddr 8.8.8.8/0 laddr 8.8.8.8/0
Oct 22 2010 09:31:48: %ASA-7-609002: Teardown local-host outside:8.8.8.8 duration 0:00:04

What is missing which is not causing the traffic to go back into the VPN tunnel on the datacenter ASA to the branch.  Is there something else I need to do with access lists applied to the outside interface?

Thanks

Frank

4 Replies 4

praprama
Cisco Employee
Cisco Employee

Hi,

Please share the output of "show crypto isakmp sa" and "sjow crypto ipsec sa" from the data center side for this VPN tunnel. What exactly are you trying to conect to, that is, what subnet does the IP that you are trying to connect to lie in?

Thanks and Regards,

Prapanch

jj27
Spotlight
Spotlight

I think this is a simple fix, from quickly looking at your configuration. You are missing the "any" to the Branch in your nat0 access-list at the datacenter side.

access-list inside_nat0_outbound extended permit ip 172.20.10.0 255.255.254.0 192.168.2.0 255.255.254.0
access-list inside_nat0_outbound extended permit ip 172.20.10.0 255.255.254.0 10.1.0.0 255.255.0.0

access-list inside_nat0_outbound extended permit ip any 255.255.254.0 192.168.2.0 255.255.254.0

You specified the traffic in your encryption domain, but not in your no-nat.

Seems as though it still is not injecting the traffic.  I used packet-tracer for ICMP pings.  looks like

it is working based on the access list that is on the outside interface but it

then drops the packet for anti spoofing.. This is the results from packet-tracer.

packet-tracer input outside icmp 192.168.2.74 8 11 8.8.8.8    

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: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound_outinterface in interface outside
access-list inbound_outinterface extended permit icmp any any object-group icmp-allowed
object-group icmp-type icmp-allowed
description: Allow ping from outside interface
icmp-object echo
icmp-object time-exceeded
icmp-object echo-reply
Additional Information:

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

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 6

Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside) 2 192.168.2.0 255.255.255.0
  match ip outside 192.168.2.0 255.255.255.0 outside any
    dynamic translation to pool 2 (8.x.x.12)
    translate_hits = 61, untranslate_hits = 0
Additional Information:
Dynamic translate 192.168.2.74/0 to 8.x.x.12/4 using netmask 255.255.255.255

Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (outside) 2 192.168.2.0 255.255.255.0
  match ip outside 192.168.2.0 255.255.255.0 outside any
    dynamic translation to pool 2 (8.x.x.12)
    translate_hits = 61, untranslate_hits = 0
Additional Information:

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

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (ipsec-spoof) IPSEC Spoof detected

I am not sure how to resolve this one now..

Hello,

On the Branch site************

You don't need this 2 lines:
global (outside) 1 interface
nat (inside) 1 192.168.2.0 255.255.255.0

You don't need the following two lines either:

access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 172.20.10.0 255.255.255.0
access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 10.1.0.0 255.255.0.0

because you already have this line:
access-list outside_cryptomap_20 extended permit ip 192.168.2.0 255.255.255.0 any

On the Datacenter:*****************

same thing here:
You don't need the following two lines

access-list outside_cryptomap_10 extended permit ip 172.20.10.0 255.255.254.0 192.168.2.0 255.255.255.0
access-list outside_cryptomap_10 extended permit ip 10.1.0.0 255.255.0.0 192.168.2.0 255.255.255.0

because you already have this line:
access-list outside_cryptomap_10 extended permit ip any 192.168.2.0 255.255.255.0


We don't need the line that jjohnstone1127 said:
access-list inside_nat0_outbound extended permit ip any 255.255.254.0 192.168.2.0 255.255.254.0

We just need the same-security-traffic permit intra-interface on the datacenter.

Please attach the sh crypto ipsec sa so we can see what's going on with the traffic, on the datacenter you could also issue a
debug icmp trace and then from an internal host at the branch location try to ping 4.2.2.2 for example and we'll be able to see
that on the debug output, if there'is a lot of traffic on the datacenter the output might be huge. Why don't you set up a asp-drop capture
just to make sure the ASA is not dromping the packets.