cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3537
Views
0
Helpful
8
Replies

Problems with ASA->ASA VPN

slug420
Level 1
Level 1

Trying to setup a couple of ASAs here in a lab environment. I jsut want to get a simple site to site VPN working between them.

config is attached...logs are here:

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 0, code 0)

%ASA-6-302021: Teardown ICMP connection for faddr 172.17.171.2/512 gaddr 172.20.0.10/0 laddr 172.20.0.10/0

%ASA-7-609002: Teardown local-host tunnelside:172.17.171.2 duration 0:00:02

%ASA-7-609002: Teardown local-host Londonside:172.20.0.10 duration 0:00:02

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 8, code 0)

%ASA-7-609001: Built local-host tunnelside:172.17.171.2

%ASA-7-609001: Built local-host Londonside:172.20.0.10

%ASA-6-302020: Built inbound ICMP connection for faddr 172.17.171.2/512 gaddr 172.20.0.10/0 laddr 172.20.0.10/0

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 0, code 0)

%ASA-6-302021: Teardown ICMP connection for faddr 172.17.171.2/512 gaddr 172.20.0.10/0 laddr 172.20.0.10/0

%ASA-7-609002: Teardown local-host tunnelside:172.17.171.2 duration 0:00:02

%ASA-7-609002: Teardown local-host Londonside:172.20.0.10 duration 0:00:02

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 8, code 0)

%ASA-7-609001: Built local-host tunnelside:172.17.171.2

%ASA-7-609001: Built local-host Londonside:172.20.0.10

%ASA-6-302020: Built inbound ICMP connection for faddr 172.17.171.2/512 gaddr 172.20.0.10/0 laddr 172.20.0.10/0

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 0, code 0)

So I need to get the VPN working...right now I get:

ASA5505-4KV-CFC(config)# show crypto isakmp

Active SA: 1

Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1 IKE Peer: 172.17.168.171

Type : L2L Role : responder

Rekey : no State : MM_ACTIVE

Among other questions...wtf does this mean:

%ASA-3-106014: Deny inbound icmp src Londonside:172.20.0.10 dst Londonside:172.17.171.2 (type 0, code 0)

Shouldnt it be Londonside:172.20.0.10 and tunnelside:172.17.171.2?? Is it trying to route traffic back out the interface it came in since my gateway is out that interface? Do I need to add a route to the remote network to make the traffic go through the tunnel? I have never needed this before 7.x (or on the few VPNs I have configured in 7.x) but I saw someone's 8.x config recently where they had added routes for all their VPN traffic pointing to the remote peer.

8 Replies 8

Marwan ALshawi
VIP Alumni
VIP Alumni

Add:

access-list TUNNEL-TRAFFIC extended permit ip 172.20.0.0 255.255.0.0 172.17.171.0 255.255.255.0

thi same thing should be done but in the opesit direction i mean u need to have an ACL as a matching for ur inersting traffic like

access-list TUNNEL-TRAFFIC extended permit ip 172.17.171.0 255.255.255.0 172.20.0.0 255.255.0.0

also for more information see the following link as a reference

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9950.shtml

good luck

please, if helpful rate

thanks I will try that tomorrow....will it not match on icmp ACLs? I have been doing all of my testing with ICMP..

u right

but also try to check that

isakmp udp 500

and esp traffic allowed to terminiate on the outsid einterfaces

for vpn

I thought of that also since I am not using sysopt connection permit-vpn....but I was expecting/hoping (I have always used the sysopt command in the past) that I would see denies in the logs when the VPN traffic from the other side tried to hit the outside access-list at which point I would explicitly allow the tunnel traffic in the outside access-list....is there a reason I wouldnt?

ok so upon further investigation...my tunnel is now up. I cant remember where I was at with this last night but I think it was what I suspected and I had to add a route to the foreign network for the traffic to get there.

So...

Interface VPNside has tunnel built to stub network. The rest of the environment and the internet are located out of the other interface, lets call it "inside".

So my default gateway points out the inside interface.

Normally with a VPN you try to get to the remote network which you have no route to, but the firewall sees that your traffic would be routed out the "outside" interface which is where you tunnel is probably built and also where your default gateway is located. So once it determines the interface the packet will be leaving it looks at the crypto maps applied to that interface, consults the match address ACL, and determines that yes indeed your packet should go through the tunnel which is then builds and fires your packet through.

In this circumstance. The ASA gets the packet and does not have a route to the remote network so it consults its routing table. This should go to the DG which is out the INSIDE interface which has no crypto maps applied to it so no VPN tunnel, it just gets sent out that interface (or tries to). Thus the log message in my original post identifying both hosts as being out the INSIDE interface.

Now with a route to the remote network configured, even if the next hop is not local (which in this case it is for me since I am just tunneling over a cat5 cable) it consults the routing table just to deterimne what interface it is going to be routed out of. With my route in place it sees that it should go out the VPN interface, then finds the crypto map on that interface and sends the traffic over the tunnel.

It is possible that specifying the VPN peer as the next hop tells the ASA to send this traffic through that specific tunnel, the purpose of this route could just be identifying the interface it will leave from so that it can look for crypto maps applied to that interface.

None of this was a problem on version 6.x (I imagine) because routing back out the interface it came in was never an option. or maybe since the 7.x/8.x code is based more on IOS consulting the routing table has moved up in the order or operations?

At any rate I have a new problem....thats not really a problem.....my tunnel works.

My problem is I have NOT enabled sysopt connection permit-vpn on EITHER firewall.

As I understand it this means I should have to apply ACLs to the VPN interface allowing IPSEC/AH/IKE traffic to hit the firewall, and then I can also add ACLs allowing and disallowing traffic from within the tunnel as apparently this ACL will now be consulted once traffic has been decrypted????

So I have none of this. In fact the only line in the ACL on my VPN interface is a dummy line allowing anyone to talk to a hsot that doesnt exist in a network that doesnt exist and vice versa. (example my ACL is like permit ip 10.110.110.10 any and im using 172 addresses for this whole configuration) The only reason that ACL line is in place is so that I can apply that access-group to the interface (which it is, applied to inbound traffic on that interface) and have the implicit deny in place.

BUT...the tunnel works. I have cleared crypto, stopped pings, done whatever I could and I cant get it to require ACLs allowing the tunnel connections to the firewalls OR allowing the traffic through the tunnels.

I even ran a capture on ip any any on the VPN interface to verify that all traffic passing is indeed in the tunnel and sure enough all it saw was proto 50.

Why is this working?

The previous post is ALL my conclusions based on testing last night and today and what I have seen....would appreciate it if some CCIE type whiz could confirm/deny-and-provide-actual-explanation-for-observed-behavior

problem solved! (i think)

So i re-issued the no sysopt connection permit-vpn command on both firewalls cleared crypto map and the tunnel went away!

So apparently in 7.x/8.x the sysopt command only appears when you do show conf, not when you do show run? wtf is that?

Guess this is example #483998 of how

6.3(5) > 7.*,8.*

so my next question...why do I not see drops in my firewall logs from IPSEC/AH/IKE traffic hitting my outside interface and being denied by my access-list on that interface??

it was showing

%ASA-3-106014: Deny inbound

that why i was wondring about the acl

but sysopt not must.. andnot secure becuse u gonna give the user full access

while u can control it through normal acl with source remote site lan and destination u lan and put what even ports u want to allow

and aaplly it inbound on the outside interface

hope this helpful

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: