Firewall Wizards mailing list archives
Re: Transparent vs. Non-transparent AGs/SPFs/whatever
From: "Ryan Russell" <ryanr () sybase com>
Date: Sat, 26 Sep 1998 11:30:58 -0700
1) AG is the sole path to the "big bad Internet" 2) Primary DNS resolvers are located on the same subnet as client
machines. Why same subnet? Do you mean just "inside" ?
3) Primary DNS resolvers forward DNS resolution to AG, when they're
confused. The only contain a table of "inside" hosts, 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, inbound
shouldn't be
that much different, though.
Straw-man: 1) Client.local.goodguy.com requests an http connection to
www.somesite.com
1A) 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 internal
address
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 via
recursive
DNS. 2A) ag.goodguy.com looks at the IP address/subnet that the request came
from,
2B) and checks it's state table 2C) and then figures out which external host it should act as a proxy to
and
proxies.
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. 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. 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. Ryan
Current thread:
- Transparent vs. Non-transparent AGs/SPFs/whatever Ryan Russell (Sep 23)
- 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)
- <Possible follow-ups>
- 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)