[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ilug
Subject:    [ILUG] roadwarrior ipsec vpn confusion
From:       John Allman <allmanj () cp ! dias ! ie>
Date:       2005-10-26 15:28:10
Message-ID: 435FA08A.80103 () cp ! dias ! ie
[Download RAW message or body]

I've been struggling with this one trying to understand it and i keep
thinking i've got it but then i'm unsure again.

I'm looking at using a true ipsec roadwarrior vpn setup with windows
remote vpn clients and i'm trying to choose the right tool for the job.
I could go with an openvpn solution but i'd like to try for an ipsec one.

I understand what happens when you use a vpn to join two remote networks
and i'm happy with that. Traffic from network A goes to vpn endpoint A,
gets encrypted, goes accross the internet to endpoint B, gets decrypted
and heads for the appropriate host on network B.

Traffic from network A is easy to identify on network B as when it's
decrypted it's exactly the same as it was beforehand and the source ip
address will be from network A.

I'm also happy enough with old freeswan on 2.4 kernels and openvpn
creating a tunnel interface which is very handy for firewalling on the
vpn endpoint. As far as i understand it, in those setups the tunnel
interface has an ip address and a static route is added for traffic on
the remote private network to go to the ip address on the tunnel
interface of the remote vpn endpoint.

This also means if you try and communicate with a machine on the remote
private network from the local vpn endpoint, the packet will appear on
that end with a the ip address of the local vpn endpoint's tunnel
interface as it's source address (that was a mouthful!).

The problem is, if i understand the situation properly, that the ipsec
implementation on windows doesn't use a tunnel interface like this.
It'll encrypt the traffic all right and the other end will decrypt it
but it will appear on the private network with the real ip address of
the windows client. Now, it seems to me like i've got that wrong as
unless your entire network is behind your vpn endpoint and it's the
default gateway, the reply traffic will get routed out normally and not
through the encrypted link. And even if it did get routed correctly,
you'd be unable to identify traffic that came in encrypted from
unencrypted once you got beyond the vpn endpoint.

I believe that windows clients usually use l2tp to get around this?

>From what i understand, openbsd uses an enc tunnel interface for ipsec
tunnels, but doesn't have an ip address on it, so i'm not sure i
understand how it would operate with the old freeswan setup. I also
understand that openswan with a 2.6 kernel doesn't have a tunnel
interface at all. I'm feeling pretty confused at this point.

Am i understanding that right? Can anyone explain the situation better?

Am i way wrong on my assumptions? If so can someone point me in the
right place? Is what i'm suggesting possible with windows clients? Is it
more trouble than it's worth?

Any pointers or feedback appreciated

John
-- 
Irish Linux Users' Group
http://www.linux.ie/mailman/listinfo/ilug/

[prev in list] [next in list] [prev in thread] [next in thread]