PIX Crypto Tunnel Selection
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-03-2007 01:02 PM - edited 02-21-2020 01:49 AM
I'm troubleshooting a site-to-site VPN tunnel between our Cat 6506 w/ VPN module to peer's PIX-515. The peer's crypto config appears to be incorrect and has two tunnels built between it and our VPN module.
Example:
!
crypto map mymap 1 match address acl1
crypto map mymap 1 set peer 1.1.1.1
crypto map mymap 1 set transform-set myset
crypto map mymap 2 match address acl2
crypto map mymap 2 set peer 1.1.1.1
crypto map mymap 2 set transform-set myset
access-list acl1 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
access-list acl2 permit ip 10.10.0.0 0.0.255.255 host 10.255.255.1
!
My question is how does the PIX determine which crypto peer (and subsequent SA) to send a packet to? In this example if a packet is sent from 10.10.1.1 to 10.255.255.1, does it match acl1 because it is sequentially higher than the next peer, or does it match acl2 because it is the longest-match for that packet?
I've tried looking through Cisco's website and documentation, but I cannot find the order of precedence for crypto tunnels and how packets are selected/sent.
Anyone here know?
- Labels:
-
Other Network Security Topics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-03-2007 01:23 PM
If memory servers, I believe the lower map statement has priority. Therefore, everything going from 10.0.0.0 /8 to 10.0.0.0 /8 will be encrypted using the first mymap statement...however, both remote peers and transform sets are the same, so I'm not sure what you're trying to accomplish here.
-brad
(please rate the post if this helps!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-03-2007 01:59 PM
The second crypto map statement should not be configured and is being removed. That is the first thing we identified on the peer that needed to be changed. I know that over-lapping networks can cause SPI errors (which is something we are seeing on our end), hence the reason we're troubleshooting.
