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.
Turns out that in NOS 4.1.2 PBR is broken if your next hop traverses port-channel or VLAG.
In this case the 10.5.2.2 router is accessed over an LACP trunk from 10.5.2.1 router, which breaks the PBR
This is fixed in firmware 4.1.3
Best Answer
That's called recursive next-hop lookup (or something along those lines) by most vendors. Most equipment will handle that just fine, but its not a particularly good practice to get into for static routing.
FWIW, iBGP typically works this way. The "next-hop" carried in an iBGP session is the next-hop on the far side of the autonomous system and some sort of IGP (typically OSPF, less commonly, IS-IS, RIP, or even static routing) is used to recursively resolve that iBGP next-hop to an immediate next-hop.
If you do too much of this, the gear is having to do more and more layers of recursion to find the real next-hop. I've never really tested any gear to see how many times it would recurse to find a real next-hop, but I wouldn't be surprised if the limit were 3 or 4.