Having trouble getting a very simple site-to-site VPN going

Unanswered Question
Oct 10th, 2007
User Badges:

The headend is an ASA5510 running 7.2(2).


I will post the config if requested, but here is the gist of it:


I have a nat exempt ACL and a corresponding nat 0 statement


I have an identical acl for the crypto map


I have sysopt connection permit-vpn


I have an appropriate transform set


I have a crypto map defined and applied. (includes a dynmap for remote users, dynmap is seq 99, site-to-site is seq 10)


I have isakmp enable outside


I have appropriate isakmp policies defined.


I have a tunnel group with the IP address of the peer defined and the shared key defined.


I have done numerous clear xlates and clear ipsec/isakmp sa.


When interesting traffic arrives at the interface, a debug crypto isakmp or ipsec shows no activity.


A packet trace runs and succeeds until:


Phase: 8

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

out id=0x45c8ec0, priority=70, domain=encrypt, deny=false

hits=1, user_data=0x0, cs_id=0x3c4c550, reverse, flags=0x0, protocol=0

src ip=192.168.0.14, mask=255.255.255.255, port=0

dst ip=192.168.10.0, mask=255.255.255.0, port=0


Result:

input-interface: alarms-dmz

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


I am stumped, I've done this 100 times and this one is killing me. Random thoughts:


I've cleared the service policies I had applied


I've cleared the default group policy.


The "interesting" traffic in this case originates on a "DMZ" interface. I've tried security 100 and 80. The interface has no ACLs applied to it in either direction.


Any ideas??

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
acomiskey Wed, 10/10/2007 - 08:22
User Badges:
  • Green, 3000 points or more

Probably want to post the clean configs. One quick thought is that your nat exemption might look like nat (inside) 0 instead of nat (dmz) 0, just a guess of course.

mattward6 Wed, 10/10/2007 - 08:32
User Badges:

Thanks for the reply! The NAT statement references the correct interface, but a good guess. Here is what I think is the salient part of the configuration:


access-list alarms-no-nat extend permit ip host 192.168.0.14 192.168.10.0 255.255.255.0


access-list telsa extend permit ip host 192.168.0.14 192.168.10.0 255.255.255.0


nat (alarms-dmz) 0 access-list alarms-no-nat


sysopt connection permit-vpn


crypto ipsec transform-set site-to-site esp-aes-256 esp-sha-hmac



crypto map melford 10 match address telsa

crypto map melford 10 set peer 75.148.20.165

crypto map melford 10 set transform-set site-to-site

crypto map melford 99 ipsec-isakmp dynamic dynmap


crypto map melford interface outside


isakmp enable outside


isakmp policy 10 authentication pre-share

isakmp policy 10 encryption aes-256

isakmp policy 10 hash sha

isakmp policy 10 group 5

isakmp policy 10 lifetime 86400


isakmp policy 65535 authentication pre-share

isakmp policy 65535 encryption 3des

isakmp policy 65535 hash sha

isakmp policy 65535 group 2

isakmp policy 65535 lifetime 86400


tunnel-group 75.148.20.165 type ipsec-l2l

tunnel-group 75.148.20.165 ipsec-attributes

pre-shared-key [redacted]

exit


clear xlate


**clear ipsec sa

**clear isakmp sa


I stumbled across a page that states the packet tracer won't work if the SA is not already established, so I guess that is not a valid test.

Actions

This Discussion