[strongSwan-dev] NAT of Subnet Behind Left Gateway with %modeconfig

William Bloom william.bloom at kinetx.com
Fri Jul 23 08:18:39 CEST 2010


I am attempting to find a strongSwan configuration that solves a VPN  
need that is rather different from the (IKEv1) examples in the  
documentation collection (I am using strongSwan 4.4.0).

I am converting (to strongSwan) from a former VPN client software  
package that has passed end-of-life.  The VPN scheme we use has  
closest similarity to the ikev1/nat-before-esp example (http://www.strongswan.org/uml/testresults43/ikev1/nat-before-esp 
) with the significant difference that the left gateway (moon) must  
accept a virtual IP assignment  via %modeconfig from the right gateway  
(which, in my case, is a Cisco ASA).

My experimental configuration specifies leftsourceip=%modeconfig and  
leftsubnet=10.1.0.10/16.  Since source routing statements are added by  
the updown script to table 220, I had at first believed, mistakenly,  
that this would give me the desired behavior.  However, 'ip xfrm  
policy' shows that the SAs were negotiated with the right subnet  
(10.2.0.0/16) using the assigned virtual IP instead of the left subnet  
(10.1.0.0/16).  Hence, no traffic flows between 10.1.0.0/16 and  
10.2.0.0/16.

If I remove the leftsourceip=%modeconfig, then the SAs are are  
negotiated between 10.1.0.0/16 and 10.2.0.0/16, and I observe traffic  
flow between the subnets through the tunnel.

But - I cannot do without the virtual address.  The reason for this is  
that I will have a collection of many clients such as 'alice', each  
with its own gateway such as 'moon', and the address space used for a  
client is at the user's discretion.  Furthermore, new clients can be  
introduced at any time.  Address space reuse therefore needs to be  
accommodated by having the ASA dole out virtual IPs.

How do I configure this?


Bill
--
William Bloom
williambloom at mac.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20100722/f70bff43/attachment.html>


More information about the Dev mailing list