Re: More VPN info

[Jason Costomiris]

On Monday, February 3, 2003, at 01:38  PM, Dick St.Peters wrote:

Jason Costomiris writes:

On Sunday, February 2, 2003, at 11:11  PM, Dick St.Peters wrote:

Giving a remote site access to the DMZ over the VPN is exactly the
example intended.

Ok, if that's the case, what's wrong with RFC 1918 space in the DMZ???
If this DMZ is only ever accessed over a VPN, using globally routable
IP space is just plain wasteful.

A DMZ accessed _only_ over a VPN isn't much of a DMZ.  The usual
purpose for a DMZ is a place to locate bastion hosts that provide
public services and run proxies allowing the internal network to
access the internet without actually exchanging packets between the
internal network and the internet.

Clever editing techniques you're deploying here.. You (conveniently) removed my explanation of using RFC 1918 space in a DMZ with NAT and VPN. You don't seem to realize that you can do both.

You want your bastions to be at globally routable IP addresses so the
public can reach your public services, and you don't want NAT in the
way so you don't restrict your proxying to NAT-tolerant applications.

Um. Yeah. Sure. Who even mentioned proxying??? We're not talking about proxying. Would you care to name me one, just one application that's going to be in the average DMZ that won't work with NAT? Let's see.. HTTP and HTTPS both work. So does SMTP, IMAP, IMAPS, POP3, POP3S, DNS, NNTP and even streaming media servers like Real, QT and M$. Even if you want to proxy outbound connections through something like a Squid cache, NATing the outbound connection does no harm. Your anti-NAT argument just fails to hold water. You can keep making up new requirements all you want, you're still terribly wrong about IPsec.

Services that aren't NAT-tolerant, like say SQL*Net and friends would never be exposed to the Internet. Those would be done with controlled access on a VPN -- where connections are NOT BEING NATed.

You also seem hung up on this notion of a "virtual wire" and how you
seem to think that IPsec doesn't act like one. As another poster has
pointed out, an IPsec tunnel meets your definition of a "virtual wire".

From the FreeSWAN FAQ:

    "IPsec tunnels are not just virtual wires; they are virtual wires
    with built-in access controls."

Yes, those access controls are pre-shared secrets and x.509 digital certificates. There is no access control beyond validation of the shared secret or the signature on the certificate. There are extensions to IPsec such as X-Auth (from Nortel), Hybrid Mode IKE (from Check Point) and CRACK (from Network Alchemy, later part of Nokia). Those add-ons introduce the ability to add a username/password to an IPsec tunnel. These all involve changes to the IKE (phase 1) process. FreeSWAN has none of those. Even if it had those extensions, those do not constitute filters. I don't think you understand IPsec.

I am an advocate of FreeSWAN for cases where I think IPsec is
appropriate.  The core difference between us seems to be that you
think IPsec is always apprpriate, whereas I feel that most of the time
its baggage outweighs its advantages.  You want people to plan their
networks around IPsec's rigidity, whereas I feel there's no reason to
put up with that rigidity when you don't have to.

Just for giggles, I sent your statements (without your name attached) to several colleagues. We've all been at this for a long time. Everyone pretty much laughed at your claims of IPsec's alleged "rigidity" and "baggage". You can say you have to plan your network around IPsec until you're blue in the face. It just does not make it true.

I've explained away every single one of your supposed "problems" with IPsec. We're done here.

--
Jason Costomiris <><
E: jcostom {at} jasons {dot} org / W: http://www.jasons.org/
Quidquid latine dictum sit, altum viditur.



--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list