[Vpn-help] Client proposal not correct to OpenSwan

Matthew Grooms mgrooms at shrew.net
Thu Sep 18 09:05:29 CDT 2008


List Receiver wrote:
> Hello all,
> 
> First time poster to the list, so "deform" me if I break any rules.  :^)
> 
> I've got a Shrew Soft 2.1.1 client on Windows that I'm trying to get connected to an OpenSwan server road warrior style.  I'm using RSA certs, NAT-T, compression, and a bunch of good stuff, but I'm having trouble with one aspect of this setup.
> 
> On the OpenSwan side, I'm dedicating a private subnet to the road warrior clients with options like this:
> 
> conn roadwarrior
>         authby=rsasig
>         auto=add
>         compress=yes
>         dpdaction=clear
>         dpddelay=30
>         dpdtimeout=120
>         keyingtries=3
>         left=fwip
>         leftcert=serverCert.pem
>         leftrsasigkey=%cert
>         leftsubnet=192.168.13.0/24
>         pfs=no
>         right=%any
>         rightrsasigkey=%cert
>         rightsubnetwithin=192.168.248.0/24
> 
> My Shrew config is as follows, with public IP's and cert info removed:
> 

Disable compression on both sides. This will cause problems.

> 
> When I connect, things look OK.  I try to ping a host in the 192.168.13.0/24 subnet, though, and the tunnel setup fails on the OpenSwan side with this error message:
> 
> Sep 17 20:34:19 fw pluto[18671]: "roadwarrior"[2] 75.146.54.65 #1: the peer proposed: 192.168.13.0/24:0/0 -> 192.168.248.35/32:0/0
> Sep 17 20:34:19 fw pluto[18671]: "roadwarrior"[2] 75.146.54.65 #1: cannot respond to IPsec SA request because no connection is known for 192.168.13.0/24===fwip<fwip>[+S=C]...clientfwip[C=US, ST=Washington, O=Losers R Us, OU=VPN, CN=Joe Schmoe, E=joe at schmoe.com,+S=C]===192.168.248.35/32
> 
> On the other hand, the tunnel functions as it should if I change the one line in the OpenSwan config to this:
> 
> #rightsubnetwithin=192.168.248.0/24
> rightsubnet=192.168.248.35/32
> 
> So...my question is, why does the Shrew Soft VPN client announce a /32 as policy instead of the /24 that it's been told to?  If it would announce the /24 as policy, I have a feeling OpenSwan would find the SA and work just fine.
> 

Thats a good question. I will need to look into that further since you 
have specified a /24 in the client config. But this sounds more like a 
OpenSwan question than a shrew soft question. From the documentation 
below, it looks like it should work regardless. We are a peer that 
completes phase1 and uses a network ID that exists within the specified 
rightsubnetwithin in phase2. They even state a specific example (rw1) 
that uses a /32 address in their documentation ...

4.4 Handling Virtual IPs and wildcard subnets

Often roadwarriors are behind NAT-boxes with IPsec passthrough, which 
causes the inner IP source address of an IPsec tunnel to be different 
from the outer IP source address usually assigned dynamically by the 
ISP. Whereas the varying outer IP address can be handled by the 
right=%any construct, the inner IP address or subnet must always be 
declared in a connection definition. Therefore for the three 
roadwarriors rw1 to rw3 connecting to a FreeS/WAN security gateway the 
following entries are required in /etc/ipsec.conf:

conn rw1
      right=%any
      righsubnet=10.0.1.5/32

conn rw2
      right=%any
      rightsubnet=10.0.1.5.47/32

conn rw3
      right=%any
      rightsubnet=10.0.1.128/28

With the new wildcard parameter rightsubnetwithin these three entries 
can be reduced to the single connection definition

conn rw
      right=%any
      rightsubnetwithin=10.0.1.0/24

Any host will be accepted (of course after successful authentication 
based on the peer's X.509 certificate only) if it declares a client 
subnet lying totally within the brackets defined by the wildcard subnet 
definition (in our example 10.0.1.0/24). For each roadwarrior a 
connection instance tailored to the subnet of the particular client will 
be created, based on the generic rightsubnetwithin template.

This feature of the X.509 patch can also be helpful with VPN clients 
getting a dynamically assigned inner IP from a DHCP server located on 
the NAT router box.

... sorry I can't be more helpful at the moment. I have a friend in the 
hospital I need to go visit.

-Matthew



More information about the vpn-help mailing list