== Transparent forwarding to a parent proxy == Hello, Is is possible to have ftp-proxy transparently forward the flow to a parent proxy (client -> ftp-proxy -> parent -> target) -- client being not aware of "parent" ? The need occurs when name resolution is not locally available, e.g. within architectures like this: user ---> H1:ftp-proxy ---- firewall ----> target on internet | | v | LDAP auth H2:parent Host H1 lies in intranet and provides LDAP user authentication, but is not allowed to resolve internet names for obvious security reasons. So the flow has to run through another proxy, H2. In such schemes, you usually have to do (the LDAP auth part was stripped for clarity): # ftp H1 user: targetuser@h2user@target@H2 pass: targetpass@h2pass But could we configure fpt-proxy on H1 so that the client would not have to mention H2 ? i.e. the client would only have to enter: # ftp H1 user: targetuser@target pass: targetpass This would be much more convenient ! An advanced feature, enabling to relay toward both intranet and internet would be to have H1 try to open an FTP connection to "target", and, if this fails, to transparently forward the flow to H2. But in my case it's simpler, there is no intranet bouncing and everything goes to internet via my proxies. Regards Phil
On Wed, Jul 07, 2004 at 01:03:55PM +0200, porte64@free.fr wrote:
== Transparent forwarding to a parent proxy ==
Hello,
Hi!
Is is possible to have ftp-proxy transparently forward the flow to a parent proxy (client -> ftp-proxy -> parent -> target) -- client being not aware of "parent" ?
The need occurs when name resolution is not locally available, e.g. within architectures like this:
user ---> H1:ftp-proxy ---- firewall ----> target on internet | | v | LDAP auth H2:parent
Host H1 lies in intranet and provides LDAP user authentication, but is not allowed to resolve internet names for obvious security reasons.
You can' use transparent proxying without resolveing.
So the flow has to run through another proxy, H2.
Hmm... It's an ill configuration :-) I mean, you can enable ldap auth without magic user feature "AllowMagicUser no" and "DestinationAddress H2" on the first H1 proxy. On the second H2 proxy you say "ForceMagicUser yes". The auth stuff is extracted on the first proxy, the real destination/target is extracted on the second proxy, and connects the server... Should work, but I've never tryed this combination :-)) BTW: Between H2 and the internet you can use transparent proxying again as long as the further proxies are installed on gateways :-)
In such schemes, you usually have to do (the LDAP auth part was stripped for clarity):
# ftp H1 user: targetuser@h2user@target@H2 pass: targetpass@h2pass
But could we configure fpt-proxy on H1 so that the client would not have to mention H2 ? i.e. the client would only have to enter:
# ftp H1 user: targetuser@target pass: targetpass
This would be much more convenient !
An advanced feature, enabling to relay toward both intranet and internet would be to have H1 try to open an FTP connection to "target", and, if this fails, to transparently forward the flow to H2.
No.
H1 allways forwards the request to H2 and H2 checks
where the connection should go via magic user.
Don't forget to use statefull protection here!!
On firewall something like:
iptables -A FORWARD -i $internet_interface \
-d H2 -p tcp --dport 21 \
-m state --state NEW -j DROP
# ... ESTABLISHED,RELATED -j ACCEPT
And on H1 as well:
iptables -A INPUT -i $internet_interface \
-p tcp --dport 21 \
-m state --state NEW -j DROP
# ... ESTABLISHED,RELATED -j ACCEPT
Using magic user destinations means, that everybody who
is able to reach the H2 proxy, can connect every host!
Also back to a host in your private network.
Bye,
Marius.
--
° --- Marius Tomaschewski
participants (2)
-
Marius Tomaschewski
-
porte64@free.fr