Jason Costomiris writes:
> On Monday, February 3, 2003, at 01:38 PM, Dick St.Peters wrote:
>
> > 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.
What I left out wasn't clever editing, just removing what was not
being contested ... I'm making no claim that you can't do any DMZ
functions through NAT, only that you can't do all that you might want
to.
I'm not sure what you think it is I don't realize is possible -
running VPNs with NAT? I've been doing that for years. My bookkeeper
works from home connected to my network with a VPN from her NAT'd
cable modem connection. For more than a year, I had a demo with a
webcam viewable through a tunnel from a NAT'd site. (The store
hosting the webcam moved, so I lost that demo, but you can still find
some now-broken links to "SpaCam".)
> >> 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
You'd have been smarter to go read the FAQ. Let me quote more of it
IPsec tunnels are not just virtual wires; they are virtual wires
with built-in access controls. Negotiation of an IPsec tunnel
includes negotiation of access rights for it, which don't include
packets to/from other IP addresses. (The protocols themselves are
quite inflexible about this, so there are limits to what we can do
about it.)
For fairly obvious security reasons, and to comply with the IPsec
RFCs, KLIPS drops any packets it receives that are not allowed on
the tunnels currently defined. So if you send it packets with
route(8), and suitable tunnels are not defined, the packets
vanish. Whether this is reported in the logs depends on the
setting of klipsdebug in your ipsec.conf(5) file.
To rescue vanishing packets, you must ensure that suitable tunnels
for them exist, by editing the connection descriptions ...
They obviously are not talking about authentication access controls
like pre-shared secrets and x.509 digital certificates as you claimed.
They are explicitly talking about access controls that determine what
packets are allowed through the tunnel.
Note the semi-apologetic tone of the FAQ over not being able to do
anything about the access restrictions. The quote is from the FAQ
section for people stumbling over the access controls, which most
people don't expect.
Again, for reference, the above quote is from
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/faq.html
(In FreeSWAN jargon, KLIPS = kernel IPSEC support):
--
Dick St.Peters, [EMAIL PROTECTED]
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
