[Openswan Users] FW: [Vpn-help] Client proposal not correct to OpenSwan

[List Receiver]

Hello all,

I'm having some trouble with OpenSwan as a server and Shrew Soft as a client, all enumerated below.  I made this post to the Shrew mailing list, and the author replied that it may not be a problem with Shrew.  Is there a reason why OpenSwan doesn't detect that the client-proposed subnet lies within the rightsubnetwithin variable?  I'd think that OpenSwan should accept the proposal since it is within the declared right subnet.

I'm running OpenSwan U2.6.14/K2.6.18-92.1.10.el5, if anyone is interested.  It was installed and updated with the CentOS repo's.


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