[Openswan Users] NAT on both sides
gohanman at gmail.com
Thu Jan 29 10:17:51 EST 2009
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
I did build RPMs, actually:
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.
> 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
>>> conn passthrough-for-non-l2tp
>>> conn road
>>> # disable opportunistic nonsense
>>> conn block
>>> conn private
>>> conn private-or-clear
>>> conn clear-or-private
>>> conn clear
>>> conn packetdefault
>>> 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.
>> To follow the path, look to the master, follow the master, walk with
>> the master, see through the master, become the master. (zen)
> To follow the path, look to the master, follow the master, walk with
> the master, see through the master, become the master. (zen)
More information about the Users