[Openswan dev] regarding "virtual IP must only be used with %any and without client" and overlapip/mast

[Paul Wouters]

On Wed, 23 Jun 2010, Michael Richardson wrote:

> Well, I didn't write the virtualIP support (It was a SuperFreeSWAN 1.99
> patch, I think), nor did we get test cases for it at the time, so I can
> only guess at what the constraints/boundary conditions of the design was.
>
> I can't think of a reason why the outer policy of who one will accept
> the connection from has anything to do with what tunnel is expressed
> inside.

It seemed the original restriction was based on single conns, versus
multiple instantiations of a conn. Using "%any" anywhere in a conn
causes it to instantiate, even if you just meant to say "any tcp port".
(unless you use 0  but the whole "any 1" vs "any" is another confusing
matter)

> Generally, at the time, virtualIP was used with Windows machines that
> would propose their private network IP for the inside of the tunnel, and
> one could never predict that.  I agree that one can now accept multiple
> proposals with the same tunnel inside, but... how will *routing* and
> TCP/IP deal with that in tunnel mode?

The use case here is that it involves only trafficing being received, not
initiated. Image an openswan server in a cloud, and two customers connecting
a subnet to route to you to anti-spam your mail or http traffic. It would
be nice of the openswan end does not need to have the customer subnets
specified in the conn. And since it is their traffic going from them to you,
they can be marked with SAref, so the overlapping IP ranges is not an issue.

You could even connect to a specific SAref+IP address combination back, using
the SAbind patch (See openswan.git/patches/kernel/2.6.32/ and contrib/saref/)

> It only works if you then NAPT the result, I think.

Yes, once it hits the openswan server, NAT tricks would have to be used to
continue the packet flow to the processing machines.

> Permitting virtual private of %v4:0.0.0.0/0 would of course let any one
> of these nodes impersonate any IP address on the Internet.

In this use case, that's not a problem because the SAref and because the
traffic flows to another machine that handles everything. There is no
"internet to customer" traffic. Though I guess you're right if one customer's
subnet uses a range that another customer's gateway is on. I guess it should
get limited to RFC1918 per default.....

>>>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:
>    Paul> There is a similar issue when using a right=5.6.7.8 and
>    Paul> rightprotoport=17/%any
>
> I can't put that combination together in my head right now.

You can currently specify:

conn http
 	left=1.2.3.4
 	leftsubnet=0.0.0.0/0
 	right=5.6.7.8
 	rightsubnet=192.168.1.0/24
 	rightprotoport=17/80

You cannot currently specify:

conn tcp
 	left=1.2.3.4
 	leftsubnet=0.0.0.0/0
 	right=5.6.7.8
 	rightsubnet=192.168.1.0/24
 	rightprotoport=17/%any

With the two changes I made, this is allowed and will instantiate. I was
wondering about any side effects I should be careful about for doing this,
though my use case is for rightsubnet=vnet:%priv and rightprotoport=17/80

Paul