[Openswan Users] problem with nat

[Jacco de Leeuw]

Paul Wouters wrote:

> On Sat, 30 Jul 2005, Rob Mokkink wrote:
> 
>>        virtual_private=v4:172.16.0.0/12,v4:192.168.0.0/16
> 
> That should be: 
>> virtual_private=%v4:172.16.0.0/12,%v4:192.168.0.0/16,!%v4:192.168.0.0/24

I just learned that 10.0.0.0/8 is his internal subnet...
So indeed the virtual_private was correct.

> This right=%any will probably clash with the one in the other roadwarriors.

Why is this, exactly? It is not mentioned in the documentation.
There could a valid reason for this due to the way things are
implemented, but it is non-intuitive. You would think that the
left/rightprotoport parameters should allow the correct connection
to be selected.

>> conn roadwarrior-l2tp-oldwin
>>        left=%defaultroute
>>        leftcert=dsfw.redhatfw.org.pem
>>        leftprotoport=17/0
>>        right=%any
>>        rightprotoport=17/1701
>>        rightsubnet=vhost:%no,%priv
>>        pfs=no
>>        auto=add
> 
> 
> you can merge these last two togehter if you use leftprotoport=17/%any
> (same for rightprotoport)

I'm a bit apprehensive about this. It would allow clients to connect
to not just L2TP but other UDP services as well, right?

Another idea could be to forget about non-updated Windows clients
altogether. I know that Microsoft bills the Q818043 update as a
functionality update but I can attest that they quietly fix security
issues in such functionality updates. I am not saying that the crypto
in non-updated Windows clients can be broken but it is better to be
safe than sorry.

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl