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.
When the ASA attempts to send traffic out an interface where a crypto map is applied, it will always process the crypto map from top-down, looking for the first match. Therefore, it will always match sequence 11, and never sequence 16. So the behavior you describe above is normal.
One correct way to do this would be to build GRE tunnels with routers, where you can run a dynamic routing protocol to determine the health of the paths. Then, you can wrap the GRE tunnels in IPSec for security. However, you said replacing the hardware is not an option. SDWAN is also another correct solution for this.
But, here's an idea for you, though. If the headquarters never initiates traffic to the remote site (or can withstand an outage when the primary tunnel goes down), you could set it up where the 897 performs NAT on the traffic when it leaves the cellular interface, so that it appears to the HQ that it's a different site. The ASA would then see this "new" site as attached to crypto map sequence 16, instead of 11. This would allow the remote site to maintain connectivity during an outage, but its source addresses would be translated. Then, when the primary internet comes back up, the 897 fails back to the primary path, to the primary tunnel, and to the primary address space. It's a bandaid, but it's an option.
Best Answer
Quoting from the order of IPSec operations in Cisco IOS, including both IPSec and NAT.
Inside to outside traffic:
Outside to Inside traffic:
Regarding how to split traffic from a single host between the tunnel and the internet connection: you will need to include the destination at the other end of the tunnel in the ACL for interesting traffic and also make sure you have a route to this destination vía the interface where the crypto map is applied.