--- Joachim Schipper <[EMAIL PROTECTED]> wrote:

> On Fri, Jul 28, 2006 at 07:09:17AM -0700, jeraklo
> wrote:
> > The proposed design will definitely be initially
> > tested in a lab.  Not to worry about that part.   
> > 
> > The major problem I have seen by now is that IPsec
> > have problems with NAT, while OpenVPN doesn't (but
> it
> > adds to latency - it is not a major concern in the
> > desired setup). 
> > 
> > I would like to briefly mention the setup again:
> > 
> > some clients will get private IP addresses at
> their
> > access network (theoretically, it could be
> anywhere in
> > the world), and then immediatelly NAT-ed to some
> > gateway's public IP pool, in order to access the 
> > outside world.  Packets from this public IP pool
> will
> > reach the VPN server and the VPN end should there
> be
> > terminated.  As I know, it is not possible to
> setup
> > this situation using IPsec without using some
> > additional magic.
> > 
> > Opinions would be appreciated.
> 
> This is quite possible, but my caveat that clients
> should not be
> attached to a subnet with the same IP numbering as
> your subnet C still
> applies.
> 

Not to worry about that either. In the desired setup
clients will never be attached to a subnet with the
same IP numbering as the destination network (e.g.
subnet "C" in the diagram).


> However, this is also true for OpenVPN, and most any
> other VPN.
> 
> You *will* require the 'access network' to pass ESP,
> 500/UDP (IKE), and
> 4500/UDP (IPsec NAT-T), of course.
> 

Regarding NAT-T, does it have to be enabled both in
clients and the VPN server ? If yes and if we're
talking about windows clients - does it come bundled
with some external IPsec client or does it have to be
enabled in the windows itself ?  (yes I know I can
possibly find this info on the internet, but if you
already know ...).

Thanks,
j.


>               Joachim
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Reply via email to