[Openswan Users] NAT on both sides

andrew colin andrew.colin at gmail.com
Thu Jan 29 07:48:25 EST 2009


Hi All,


I have got it working with 2.4.13, I have noticed how ever that this
setup introduces a security problem
with l2tpd if using NETKEY

The l2tpd connection that comes out of the tunnel has a destination ip
of the servers interface, which
means you have to allow connections to port 1701 from any where if it
is to work.

If you have a dumb ass router siting infront of the openswan server
that does not have the option to
forward protocol ESP (meaning you forward everthing to the server),
your l2tpd daemon then
becomes exposed to the world.

KLIPS would be a better option here as it creates the ipsecX
interfaces to which you can apply
filtering rules.

I

On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com> wrote:
> Thanks mate, i will test that did you build an RPM that you can share
> our just pristine source ?
>
>
> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
>> OK, I've got it. I was running into a documented bug with 2.6.x
>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>> replace it.
>>
>> I ended up with this server configuration:
>> version 2.0     # conforms to second version of ipsec.conf specification
>>
>> config setup
>>        protostack=netkey
>>        nat_traversal=yes
>>        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
>>
>> conn passthrough-for-non-l2tp
>>        type=passthrough
>>        left=192.168.1.2
>>        leftnexthop=192.168.1.254
>>        right=0.0.0.0
>>        rightsubnet=0.0.0.0/0
>>        auto=route
>>
>> conn road
>>        authby=secret
>>        pfs=no
>>        rekey=no
>>        keyingtries=3
>>        type=transport
>>        forceencaps=yes
>>        left=192.168.1.2
>>        leftnexthop=192.168.1.254
>>        leftprotoport=17/1701
>>        right=%any
>>        rightsubnet=vhost:%no,%priv
>>        rightprotoport=17/%any
>>        auto=add
>>
>> # disable opportunistic nonsense
>> conn block
>>    auto=ignore
>>
>> conn private
>>    auto=ignore
>>
>> conn private-or-clear
>>    auto=ignore
>>
>> conn clear-or-private
>>    auto=ignore
>>
>> conn clear
>>    auto=ignore
>>
>> conn packetdefault
>>    auto=ignore
>>
>> Differences from before:
>> Those auto=ignore sections are necessary or pluto will gobble up all
>> incoming connections. Version 2.4.13 also gives errors on start up if
>> there is vertical whitespace within a connection section (although
>> comment lines interleaved are fine). I had to use left + leftnexthop
>> instead of %defaultroute to make both connections work. I haven't
>> tried an OS X client yet, but that's why forceencaps is there.
>> Passthrough seems to behave nicely; I can connect simultaneously by
>> VPN and SSH.
>>
>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>> setup too, but that's probably not a normal set up (my VPN server
>> happens to also be routing traffic on 4 separate subnets).
>>
>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>> Please let me know if you get it working with a windows client.
>>>
>>
>
>
>
> --
> "Dru"
> To follow the path, look to the master, follow the master, walk with
> the master, see through the master, become the master. (zen)
> http://www.topdog.za.net/
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/


More information about the Users mailing list