Firewall Wizards mailing list archives
Re: Transparent vs. Non-transparent AGs/SPFs/whatever
From: "Stephen P. Gibbons" <steve () aztech net>
Date: Sun, 27 Sep 1998 19:19:18 -0700
I'll yammer some more. Feed-back is still appreciated. :-) Ryan Russell wrote:
1) AG is the sole path to the "big bad Internet" 2) Primary DNS resolvers are located on the same subnet as clientmachines. Why same subnet? Do you mean just "inside" ?
I imagine that the pool of IP addresses available to the AG is limited,and exhaustable. Enabling the AG to re-use the same IP address for multiple client/server connections seems like a win and the easiest way to do that is if the DNS query and client connection request are correlatable. This constraint could be lifted, with trade-offs.
3) Primary DNS resolvers forward DNS resolution to AG, when they'reconfused. The only contain a table of "inside" hosts, yes?
Yes.
4) AG has X number of IP addresses/virtual interfaces assigned to it and configured. 5) I've mostly been thinking in terms of outbound access, inboundshouldn't be that much different, though.Straw-man: 1) Client.local.goodguy.com requests an http connection towww.somesite.com1A) resolve www.somesite.com via dns.local.goodguy.com 1B) dns.local.goodguy.com can't resolve it, so it gets forwarded to dns.ag.goodguy.com 1C) dns.ag.goodguy.com realizes that the request came from an internaladdress and:1C1) reconfigures an available virtual interface 1C2) responds with this newly configured address instead of the A RR for www.somesite.com 1C3) keeps a state table of requests and responses 2) client.local.goodguy.com connects to the A RR that it got back viarecursive DNS.2A) ag.goodguy.com looks at the IP address/subnet that the request camefrom, and:2B) checks it's state table 2C) then figures out which external host it should act as a proxy to and proxies the connection.This sounds like a really clever hack. It could rather neatly solve the problem of the AG not being transparent from it's point-of-view.
"It's point of view" meaning the client's point of view, yes?
If you're hadning out a unique inside IP address per DNS name, so it
can keep track of the real destination IP address, it think this is workable.
It's still a back-of-the napkin idea, but I think so too.
Unfortunatly, it doesn't help my question. There are two side-effects of an AG being not transparent, and I didn't break these out very well in my original note. One is that your client has to do something special in terms of delivering the packet to the AG (i.e. that will be the destination IP address of the packet.) You've got a potentially nice solution for that. The second is that the client program has the option to inform the AG what proxy it's speaking, and to what port on the final machine. You browser could talk to the AG and say "I want HTTP at www.sun.com at port 80." I don't imagine all proxy clients do this, some also probably just work off of port number. But, the advantage here is that the client can pick a protocol independent of port number, i.e. it could ask for HTTP on port 23.
Ah. The approach that I've outlined presumes the stance of "anything notspecifically enableded, is prohibited." The AG proxies should be configuarable so that it would be easy enough to allow HTTP traffic from a given client to a given server on a given port. I'm thinking that it wouldn't be horrendously difficult to write an AG proxy or proxy "shim" that understood most of the standard initial protocol exhanges, and could determine the protocol being used, even if it was running on a non-standard port. This should be relatively easy to do for most of the useful TCP protocols, and would fit into the category of plug-GW on steroids. (The biggest concern here would be about keeping things simple and straight-forward.) There's still the option of running proxies that require client configuration, so that if you need to be able to talk HTTP to www.sun.com on port 23 you can. The ideas that I've presented were initially aimed at how to solve the problem of using standard clients talking to standard servers on standard ports with little or no user training, and getting the benefits of an AG vs. relying on an SPF. I think that some of the harder problems are also solvable, but increase the complexity beyond the level of what one person can write (and feel comfortable) with in a month or two (my original estimate, for the basic functionality of what I outlined.) -- Steve
Current thread:
- why isn't there a newer linux fw-howto, (continued)
- why isn't there a newer linux fw-howto Bárány Sándor (Sep 24)
- Re: why isn't there a newer linux fw-howto Stefan Laudat (Sep 25)
- Re: why isn't there a newer linux fw-howto Kevin Steves (Sep 29)
- RE: why isn't there a newer linux fw-howto Andy Burns (Sep 30)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Woody Weaver (Sep 25)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Bill_Royds (Sep 24)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Stephen P. Gibbons (Sep 25)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Ryan Russell (Sep 24)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Bill_Royds (Sep 25)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Ryan Russell (Sep 29)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Stephen P. Gibbons (Sep 29)
- Re: Transparent vs. Non-transparent AGs/SPFs/whatever Ryan Russell (Sep 29)
- why isn't there a newer linux fw-howto Bárány Sándor (Sep 24)