[Openswan Users] NAT on both sides

andrew colin andrew.colin at gmail.com
Mon Feb 9 07:02:05 EST 2009


Hi Peter

Actually there is a bit of a curve ball to this, the openswan book and
most people tell you to mark the ESP packets in the mangle tables
PREROUTING chain, that does not work if your openswan server is behind NAT.

The ESP packets are encapsulated in UDP packets and arrive on port
4500, to classify this traffic you need to mark UDP packets that
are part of an established connection destined for port 4500

iptables -t mangle -A PREROUTING -i eth0 -p udp --dport 4500 -m state
--state ESTABLISHED,RELATED -j MARK --set-mark 0x5
iptables -A INPUT -i eth0 -m mark --mark 0x5 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 1701 -j DROP

Then use the mark to allow the connection to l2tpd.

Andrew


On Thu, Jan 29, 2009 at 3:28 PM, Peter McGill <petermcgill at goco.net> wrote:
> 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/
>>>
>>
>>
>>
>



-- 
"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