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

ASA - Interface question (IPSec)

cdcjim2877
Level 1
Level 1

Is it possible on an ASA to "split" the interfaces (e0/0 - e0/1 *** e0/2 - e0/3) to behave in such a way as to work as separate ASA's?

Objective (2 separate functions)

--------------------------------

Function 1

e0/0 - Outside Interface - ISP

e0/1 - Inside Interface - traditional LAN

Function 2

e0/2 - Outside2 Interface - to be used for an IPSec tunnel via another external network (BGP cloud)

e0/3 - Inside2 - restricted LAN

*****************************************

- e0/2 and e0/3 do not need to traverse e0/0 or e0/1 (or vice versa).

- e0/2 is only used to connect to a remote site so that the remote site network and e0/3 network communicate with each other.

*****************************************

I am not sure that this will work, as the quad default route statement to e0/0 kills my tunnel traffic routes between the remote site and e0/3.

Thoughts or comments?

1 Accepted Solution

Accepted Solutions

Yep, you should be fine. The command I posted earlier shows that packets are getting encrypted / decrypted. The ASA doesn't increment ACL hit counts for encrypted/decrypted traffic.

View solution in original post

8 Replies 8

andrew.prince
Level 10
Level 10

auraza
Cisco Employee
Cisco Employee

You could use multi-context, but VPN is not supported in MC mode.

With two different public interfaces, you have to think about routing, which would work in the case of L2L tunnels, but wouldn't work with Remote-access, as you can only have one default route, which would most likely be out your e0/0.

Correct - I finally have the routing configured, but I do not see the ACL incrementing on the ASA side (that is, the acl for the allowed tunnel traffic).

I see it increment at the main site PIX, but it is very strange that the acl on the ASA does not increment.

The acl is:

access-list 101 extended permit ip 172.X.X.0 255.255.255.0 10.0.0.0 255.0.0.0

A "sho access-list 101" displays no hit counts however traffic is passing and the correct crytpo statements are present to match the access list. Tunnel comes up beautifully...

Isn't this odd?

Thank you for your comments.

J

What does "show crypto ipsec sa | i ident|encaps|decaps" show on the ASA.

Are you doing any sort of NAT, etc?

I am excluding:

Nat (inside2) 0 access-list 101

-----------------------------------------

The output:

ASA# sho crypto ipsec sa | i ident|encaps|decaps

local ident (addr/mask/prot/port): (172.x.x.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.x.x.0/255.0.0.0/0/0)

#pkts encaps: 311, #pkts encrypt: 311, #pkts digest: 311

#pkts decaps: 302, #pkts decrypt: 302, #pkts verify: 302

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

Currently we are testing this, but it is planned to go in to production tomorrow. Access is available, through all respective interfaces (e0/0, e0/1, e0/2, e0/3) as configured.

I just thought it odd regarding the acl not incrementing.

From that output it seems like you are getting packets encrypted / decrypted. Are you only concerned about the ACL not incrementing?

Yes - that is correct.

I have tested different types of traffic and access to our devices on each respective end of the tunnel and all appears to be working well.

If this is no cause for alarm, then I feel we can move forward with our schedule implementation.

thank you,

Jim

Yep, you should be fine. The command I posted earlier shows that packets are getting encrypted / decrypted. The ASA doesn't increment ACL hit counts for encrypted/decrypted traffic.

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: