I decided to break from GET VPN for a moment because I had to do some work on a SVTI config with Openswan. I did this all by using GNS3 and VMWARE. Amazingly GNS3 has been working great for me. Not using much resources mainly because I installed an app called ThreadMaster. It will limit the amount of CPU a certain program can use. Its pretty sweet.

So whats the big deal about SVTI? Well its cool of course. There are some things you need to know (Restrictions).

SVTI (Static Virtual Tunnel Interface) supports tunnel mode only and ip any any proxy ID. The main deal here is the “IP any any proxy id”. The proxy ID in crypto maps is what us Cisco folks know as the match ACL. The match ACL defines what traffic flow is to be encrypted for the tunnel. The remote peer must have a mirrored copy of this configured. So why even bother if you have to encrypt everything? Well thats not the case. Remember, We are actually only encrypting what we send to the tunnel interface. So even if we have “any any” as the proxy id we are not necessarily encrypting all traffic to the remote peer. You can have multiple SVTI configured then you would define what traffic you want to send to the tunnel interface by using route entries. Think of all the possibilities of this. You can configure some sweet route-maps to redirect traffic, apply different features to the interface itself like nat, ACLs etc…

So SVTI is a “always on” type of tunnel. You define what you want to encrypt by using route statements pointing to the tunnel interface but the tunnel will always remain up regardless of traffic flow. You can filter using ACLs, ip inspects, auth proxy and more. The issue I hit was the proxy id problem. Openswan had the left and right subnets defined instead of a any any config. The tunnel would come up for like 20 seconds then fail miserably. Openswan was whining that it didnt like the 0.0.0.0 proxy ID sent to it because it wasnt configured that way.

conn mytestVPN
left=192.168.40.129
leftsubnet=10.10.10.10/32
leftnexthop=192.168.40.1
right=192.168.40.10
rightsubnet=192.168.55.128/26
esp=3des-md5-96
auto=start
pfs=no
ikelifetime=28800
keylife=3600

As you can see, the right and left subnets are equivalent to a Cisco match address. The SVTI interface however does not use a match ACL. Here is the quick and dirty config for it.

crypto ipsec transform-set tset_3des_md5 esp-3des esp-md5-hmac
!
crypto ipsec profile 3des_profile
set transform-set tset_3des_md5
!
crypto isakmp key cisco address 192.168.40.129
!
interface Tunnel22
ip address 1.1.1.1 255.255.255.252
no snmp trap link-status
tunnel source FastEthernet0/0
tunnel destination 192.168.40.129
tunnel mode ipsec ipv4
tunnel protection ipsec profile 3des_profile
!
ip route 10.10.10.10 255.255.255.255 tunnel 22

Look how small the config is. This is a much easier way to configure tunnels than using a crypto map. Ultimately, in this scenario I decided to use a crypto map config because I’m not sure if Openswan has anything to compare as far as SVTIs go. Maybe its possible to bind to a loopback and then use route statements to route the encryption traffic correctly in linux.

I did however get this working by configuring openswan for a 0.0.0.0/0 to 0.0.0.0/0 proxy id.

conn mytestVPN
left=192.168.40.129
leftsubnet=0.0.0.0/0
leftnexthop=192.168.40.1
right=192.168.40.10
rightsubnet=0.0.0.0/0
esp=3des-md5-96
auto=start
pfs=no
ikelifetime=28800
keylife=3600

With this configured everything came up as expected. I think the loopback idea might work but haven’t tried it yet.