06-15-2009 05:44 AM - edited 02-21-2020 04:15 PM
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?
Solved! Go to Solution.
06-15-2009 09:05 AM
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.
06-15-2009 07:53 AM
I suggest you look at the multiple context approach:-
HTH>
06-15-2009 08:15 AM
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.
06-15-2009 08:45 AM
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
06-15-2009 08:47 AM
What does "show crypto ipsec sa | i ident|encaps|decaps" show on the ASA.
Are you doing any sort of NAT, etc?
06-15-2009 08:57 AM
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.
06-15-2009 08:59 AM
From that output it seems like you are getting packets encrypted / decrypted. Are you only concerned about the ACL not incrementing?
06-15-2009 09:02 AM
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
06-15-2009 09:05 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide