ASA - Interface question (IPSec)

Answered Question
Jun 15th, 2009

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?

I have this problem too.
0 votes
Correct Answer by auraza about 7 years 5 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
auraza Mon, 06/15/2009 - 08:15

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.

cdcjim2877 Mon, 06/15/2009 - 08:45

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

auraza Mon, 06/15/2009 - 08:47

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

Are you doing any sort of NAT, etc?

cdcjim2877 Mon, 06/15/2009 - 08:57

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.

auraza Mon, 06/15/2009 - 08:59

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

cdcjim2877 Mon, 06/15/2009 - 09:02

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

Correct Answer
auraza Mon, 06/15/2009 - 09:05

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.

Actions

This Discussion