I have to give credit to @ron for this answer.
The policy map was never going to work the way it was previously. @ron suggested a gre tunnel, then protect that with ipsec.
interface Tunnel0
ip address 10.10.10.2 255.255.255.252
ip mtu 1420
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
crypto map IOFVPN
and a route to point to the internal subnet on the remote side with a gateway of the remote side.
S 192.168.10.0/24 [1/0] via 10.10.10.1
I've never used gre before but I will now. Getting the tunnel up was pretty basic both on the cisco and linux ( openswan ) side. Once that was up and running I tested without ipsec.
On my fa0/0 interface, my internal I put:
ip policy route-map PROXY-REDIRECT
route-map proxy-redirect permit 100
match ip address PROXY-REDIRECT
set ip next-hop recursive 192.168.10.1
The matching ACL is:
ip access-list extended proxy-redirect
deny tcp host 192.168.30.13 any eq www
permit tcp 192.168.30.0 0.0.0.255 any eq www
permit tcp 192.168.30.0 0.0.0.255 any eq 443
permit tcp 192.168.30.0 0.0.0.255 any eq irc
permit tcp 192.168.30.0 0.0.0.255 any eq 6667
deny tcp 192.168.30.0 0.0.0.255 any eq 5938
deny tcp any any
deny udp any any
deny ip any any
As soon as I added that my traffic started passing the way I wanted it. I'll note here that this ACL could be shrunk. I added the implicit deny's because I was having the odd traffic pass over the link.
Once was verified working then I just needed to wrap it in ipsec. Configuring the Cisco side was easy.
crypto isakmp policy 1
encr aes 192
authentication pre-share
group 2
lifetime 43200
crypto isakmp key *********** address 2.2.2.2
!
!
crypto ipsec transform-set IOFSET2 esp-aes 192 esp-sha-hmac
mode transport
!
crypto map IOFVPN 1 ipsec-isakmp
description IOM
set peer 2.2.2.2
set transform-set IOFSET2
match address IPSEC-GRE-IOF
ip access-list extended IPSEC-GRE-IOF
permit gre host 1.1.1.1 host 2.2.2.2
** Must use transport mode. It took me a bit to figure that one out.
Apply that crypto map to both f0/1 and tun0 and you have a tunnel.
The openswan side is what gave me trouble though this whole thing. Their config is a bit odd and it just took some getting used to.
At the end of the day all traffic that I want is peeled off and routed through an ipsec protected gre tunnel to a remote endpoint.
Enjoy.
If you're talking Cisco, each acl record is it's own SA (tunnel). FWIW, the Cisco PIX/ASA will not allow an "any" rule. (which is why an IOS tunnel interface cannot terminate to a PIX/ASA.)
What sort of instability are you seeing? If one rule works, they should all work. Yes, there will be a delay if the SA isn't setup yet. The only issue I can think of would be where IPsec is passing through a NAT device that cannot keep track of multiple streams.
Best Answer
The ACL associated with a point to point VPN should always contain both source and destination information. To classify "interesting traffic", that is the traffic to be protected and then sent to a remote endpoint, Cisco devices (routers and L3 swithces and ASAs oh my) will look at both source and destination addresses. If you would like a singular host to be able to send traffic to an entire remote Class C, then your ACL would look like the following:
If this is not specified and you just have
Then how will your router know that it is not supposed to take traffic from another local sunbnet and encrypt it. Furthermore if you are running NAT on the same device, it adds further confusion. If your external IP on this VPN device is a public IP, then it also falls within the "any" statement of that ACL.
"The reason they cited was because keeping the crypo ACL open like this and then limiting it with an ACL on the interface, you would cut down on the number of SA's built. How does this cut down on the number of SA's and is this the most efficient way to design VPN's?"
This is technically incorrect, you will only have a singular SA (security association) between the devices for each tunnel, not for each individual TCP session or traffic flow.