[Openswan Users] road warrior set up with openswan

[Paul Wouters]

On Fri, 14 Jan 2011, Erich Titl wrote:

> The mystery primarily rotates around the following parameter
>
> rightsubnet: not easily to be known, I found
>
> rightsubnet=vhost:%priv,%no but unfortunately was not able to discern
> the meaning of those parameters.
>

> Can someone point me to a public documentation which details this.

        virtual_private
            contains the networks that are allowed as subnet= for the remote
            client. In other words, the address ranges that may live behind a
            NAT router through which a client connects. This value is usually
            set to all the RFC-1918 address space, excluding the space used in
            the local subnet behind the NAT (An IP address cannot live at two
            places at once). IPv4 address ranges are denoted as %v4:a.b.c.d/mm
            and IPv6 is denoted as %v6:aaaa::bbbb:cccc:dddd:eeee/mm. One can
            exclude subnets by using the !. For example, if the VPN server is
            giving access to 192.168.1.0/24, this option should be set to:
            virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24.
            This parameter is only needed on the server side and not on the
            client side that resides behind the NAT router, as the client will
            just use its IP address for the inner IP setting. This parameter
            may eventually become per-connection.

Anything defined in virtual_private becomes part of "%priv" which can be used
in rightsubnet=

So rightsubnet=vhost:%priv,%no  means "If NATed any IP range from virtual_private/32
is accepted. If not NATed (%no) the public ip is accepted.". Or in shorter terms,
"accept clients behind NAT or on public IP".

You can also use rightsubnet=vnet:%priv to build tunnels where the remote sends you
a subnet, eg allowing the remote to use a leftsubnet= that you don't have hardcoded
in your config. Note that this allows instantiation, so a remote could have multiple
conns with multiple subnets and your conn would instantiate for all of them. This
makes using openswan in "clouds" easy.

I've updated the man pages to explain this a bit better,

Paul