> From: Dick St.Peters [mailto:[EMAIL PROTECTED]] > Sent: Sunday, February 02, 2003 8:11 PM > > > Jason Costomiris writes: > > On Sunday, February 2, 2003, at 03:41 PM, Dick St.Peters wrote: > > > > > > A DMZ with RFC1918 private-IP-space addressing? I'll grant that's > > > imaginative ... kinda useless though. > > > > Useless? Hardly. Most ISPs aren't handing out lots of IP space, > > particularly to small customers these days. You do NAT for the couple > > of boxes that you stick in the DMZ, unless the systems are being > > accessed over the VPN. In this day & age, when ISPs are handing out a > > /28 or even a /29, do you really want to blow additional IPs by further > > subnetting an already small IP space? I'd file that one under "bad > > planning". Plus, adding NAT gives you a bit more protection, granted > > not a lot, but every little bit counts. > > Giving a remote site access to the DMZ over the VPN is exactly the > example intended. > > It's odd to see an IPsec advocate speaking highly of NAT. NAT changes > packets checksums, which disables some things - IPsec being the most > commonly-cited example.
I am sure AH and ESP doesn't care if the IP checksum changes because that is just down one layer. ESP and AH are separate from TCP and UDP so most firewall's won't even perform NAT on these packets. > > > > Other VPN technologies create tunnels that act like virtual wires. > > > IPsec creates tunnels that act like virtual wires with filters that > > > limit the connection to a specific subnet/gateway pair. With other > > > VPN technologies you can add such filters if you want them, but with > > > IPsec you can't remove them if you don't want them. > > > > You seem confused. IPsec does not have any filtering built in. In > > most cases, your IPsec tunnels are terminated on a firewall, which DOES > > have filtering capabilities. > > If an IPsec tunnel links net1 to net2, and you establish a route > through it from net1 to net3, the IPsec tunnel will refuse to carry the > packets. You may not call that filtering, but that's what it is. That is correct unless you build the tunnel with net3 in mind. The way IPSEC works is an SA is generated based on the host or network information on either end. So, if you give it the proper information, net2 and net3, you don't need to manually build more tunnels. Multiple SA's or an SA bundle will be generated and the traffic will pass. (RFC 2401 and 2406) So, if you provide the far-end networks, i.e. net3 then IPSEC will accept the packet and forward it. > > > I've been building networks for 13 years, and VPNs for 7 years. I've > > never once had to re-architect a network to deploy an IPsec VPN. Some > > IPsec configurations have been easier than others, and those are the > > ones done on *well-planned* networks. > > Show and tell time, eh? Ok, I built my first IP network in 1983. > That network became one of the two foundation networks for the GE > Corporate network. > > When GE and RCA merged, the GE and RCA networks were merged - hundreds > of sites, some with thousands of IP stations. A couple years later, > GE traded its Electronics business (GE and RCA parts) for Thompson's > Medical Equipment business in Europe. Then GE sold its Aerospace > business (GE and RCA parts) to Martin Marietta. Don't talk to me > about planned networks ... You both have been in the industry for a long time so that means you should know by now that everybody has different opinions on how to do things. I will bypass this section since I am not in a show and tell mood nor do I think everybody who posts needs to also post there resume. > > -- > Dick St.Peters, [EMAIL PROTECTED] > Gatekeeper, NetHeaven, Saratoga Springs, NY > Saratoga/Albany/Amsterdam/GlensFalls/Greenwich/NorthCreek/SaranacLake > Oldest Internet service based in the Adirondack-Albany region > > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe > https://listman.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
