VPN Types – Which VPN Protocols Support Multicast Traffic

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.

Obviously you aren't using a Cisco VPN client, as it monitors the route table and will remove your tampering immediately. Even if the routes stick, the ASA will ignore traffic that doesn't belong in the tunnel.

There are two possibilities at play here:

• the ASA isn't configured to hairpin traffic
• the ASA isn't configured to allow those networks through the tunnel

The first can be enabled via same-security-traffic permit inter-interface and same-security-traffic permit intra-interface.

The second requires changes to the VPN split-tunnel configuration, any ACLs restricting access, routes on other gateways to know where the vpn-pool lives, and finally ensure the site-to-site VPNs know about and allow that pool across their tunnel.

(The latter is why my ASA proxy's DHCP from the local LAN for clients. It essentially makes VPN clients look like nodes on the local LAN.)

[UPDATE]

With IOS, the crypto map defines what traffic goes in the tunnel(s). (match address clause) That info is provided to the IPSec client. (it creates a security-association (SA) for each rule of the ACL.)

(for the record, I don't use the old IPSec client engine anymore. I prefer the SSLVPN (webvpn) setup on both ASA and IOS -- the setup is nearly identical. ASA-IOS tunnels are still the old, complicated crypto map IPSec setup. IOS-IOS tunnels, I prefer Tunnel interfaces.)