[Openswan Users] NAT on both sides

[andrew colin]

On Thu, Jan 29, 2009 at 5:17 PM, Andy Theuninck <gohanman at gmail.com> wrote:
> Wasn't the whole point here to deal with a NAT device in front of the
> server? So long as that NAT device is explicitly dropping 1701, isn't
> it more or less irrelevant what iptables does on the server? Packets
> that get through have to either originate locally or come through the
> tunnel.

Well most cheap dsl routers do not have the option to foward the ESP protocol
the only work around is to use the DMZ option which sends all traffic to a inner
host.

Anyway i have found a workaround for mine by installing the tomato firmware
on the linksys device i am using which allows me to script iptables commands
that cannot go into the firewall interface.

>
> I did build RPMs, actually:
> http://gohanman.com/rpm/CentOS5/RPMS/i386/openswan-2.4.13-1.1.i386.rpm
> http://gohanman.com/rpm/CentOS5/SRPMS/openswan-2.4.13-1.1.src.rpm

Thanks, i also built my Centos rpms using the spec file inside the tarball,
still playing around with it have not had any issues so far/

>
> Built on CentOS, most likely will work on RHEL, and probably Fedora,
> too. I purposely removed one patch that messes up %defaultroute and
> took off a couple others that wouldn't apply cleanly to 2.4.13 source.
> So far I haven't had any problems.
>
> On Thu, Jan 29, 2009 at 6:48 AM, andrew colin <andrew.colin at gmail.com> 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/
>>>
>>
>>
>>
>> --
>> "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/