[Openswan Users] NAT on both sides

[Peter McGill]

You can solve this on your Openswan machine by marking incomming IPSec 
packets with iptables, the mark is preserved when the packet is 
decrypted and reinserted, then you can allow marked packets for l2tp, 
etc... but drop unmarked ones for security. Read man iptables for details.

Peter

andrew colin wrote:
> 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/
>>
> 
> 
>