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