All of lore.kernel.org
 help / color / mirror / Atom feed
* redirecting on a local machine
@ 2007-01-19 18:44 saspan
  2007-01-19 18:47 ` Jan Engelhardt
  2007-01-19 19:24 ` Pascal Hambourg
  0 siblings, 2 replies; 8+ messages in thread
From: saspan @ 2007-01-19 18:44 UTC (permalink / raw)
  To: netfilter

Hi there,

I have serious trouble configuring a LTSP-server, wanting it to 
work as a transparent proxy using squid in order to secure 
web-access for our children.

The problem is to redirect TCP-requests to the machine itself.

More detailed: I want the tcp-requests from users logged into 
the LTSP-machine being redirected to the machines' proxy. 
As mentioned above the proxy is running on the same system.

A simple

iptables -t -nat -A OUTPUT -m owner ! --owner-uid squid -p tcp 
--dport 80 -j REDIRECT --to-destination 3128

doesn't seem to work, cause a browser would not be expecting a 
reply from a transparent proxy when waiting for replies to its requests.

What am I doing wrong here? Do the packets have to masked 
locally before redirecting them to the proxy?

Any help is appreciated as I have been guessing on this problem 
for three days.

Regards,
Sascha


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 18:44 redirecting on a local machine saspan
@ 2007-01-19 18:47 ` Jan Engelhardt
  2007-01-19 18:54   ` saspan
  2007-01-19 19:24 ` Pascal Hambourg
  1 sibling, 1 reply; 8+ messages in thread
From: Jan Engelhardt @ 2007-01-19 18:47 UTC (permalink / raw)
  To: saspan; +Cc: netfilter


> A simple
>
> iptables -t -nat -A OUTPUT -m owner ! --owner-uid squid -p tcp --dport 80 -j
> REDIRECT --to-destination 3128
>
> doesn't seem to work, cause a browser would not be expecting a reply from a
> transparent proxy when waiting for replies to its requests.

So configure squid to actually act transparent. Or better, reject the 
traffic and make everyone actively use the proxy. It does not have as 
many caching caveats as transparent.
 

	-`J'
-- 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 18:47 ` Jan Engelhardt
@ 2007-01-19 18:54   ` saspan
  0 siblings, 0 replies; 8+ messages in thread
From: saspan @ 2007-01-19 18:54 UTC (permalink / raw)
  To: netfilter

> So configure squid to actually act transparent. 

That's what I did, doesn't work though.

>Or better, reject the traffic and make everyone actively 
>use the proxy. It does not have as  many caching caveats 
>as transparent.

You mean by configuring the users' browsers to use
localhost:3128 and deny any other destination?

That is a quite good idea but it doesn't really solve the problem.

Regards,
Sascha



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 18:44 redirecting on a local machine saspan
  2007-01-19 18:47 ` Jan Engelhardt
@ 2007-01-19 19:24 ` Pascal Hambourg
  2007-01-19 19:48   ` saspan
  1 sibling, 1 reply; 8+ messages in thread
From: Pascal Hambourg @ 2007-01-19 19:24 UTC (permalink / raw)
  To: netfilter

Hello,

saspan a écrit :
> 
> iptables -t -nat -A OUTPUT -m owner ! --owner-uid squid -p tcp --dport 
> 80 -j REDIRECT --to-destination 3128

'--to-destination' is not a valid option for REDIRECT. The only valid 
option is '--to-ports'.

> doesn't seem to work,

That does not provide much info. Can you elaborate ?

> cause a browser would not be expecting a reply 
> from a transparent proxy when waiting for replies to its requests.

Huh ?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 19:24 ` Pascal Hambourg
@ 2007-01-19 19:48   ` saspan
  2007-01-19 22:23     ` Jan Engelhardt
  2007-01-19 22:34     ` Pascal Hambourg
  0 siblings, 2 replies; 8+ messages in thread
From: saspan @ 2007-01-19 19:48 UTC (permalink / raw)
  To: netfilter

From: "Pascal Hambourg" <pascal.mail@plouf.fr.eu.org>

>> iptables -t -nat -A OUTPUT -m owner ! --owner-uid squid -p tcp --dport 
>> 80 -j REDIRECT --to-destination 3128
>
>'--to-destination' is not a valid option for REDIRECT. The only valid 
>option is '--to-ports'.

Sorry, sure, that is what it actually looked like. 
I pasted the code quickly from my memory.
The rule I used was

iptables -t -nat -A OUTPUT -m owner ! --owner-uid squid -p tcp --dport 
80 -j REDIRECT --to-ports 3128

>> doesn't seem to work,
>
>That does not provide much info. Can you elaborate ?

The browser sends http-request, it is redirected to squid
and then network-timeout-error occurs in the browser .

>> cause a browser would not be expecting a reply 
>> from a transparent proxy when waiting for replies to its requests.
>
>Huh ?

See: 
The browser sends http-request to e.g. 99.9.9.9.1:80.
The request is redirected to proxy on 127.0.0.1:3128.
Browser waits for reply from 99.9.9.9:80.
Actually the reply will come from proxy on 127.0.0.1:3128.

Do you see the problem?

Regards

Sascha




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 19:48   ` saspan
@ 2007-01-19 22:23     ` Jan Engelhardt
  2007-01-27 14:57       ` Jan Engelhardt
  2007-01-19 22:34     ` Pascal Hambourg
  1 sibling, 1 reply; 8+ messages in thread
From: Jan Engelhardt @ 2007-01-19 22:23 UTC (permalink / raw)
  To: saspan; +Cc: netfilter


On Jan 19 2007 20:48, saspan wrote:
>> > cause a browser would not be expecting a reply from a transparent
>> > proxy when waiting for replies to its requests.
>> 
>> Huh ?
>
> See: The browser sends http-request to e.g. 99.9.9.9.1:80.
> The request is redirected to proxy on 127.0.0.1:3128.
> Browser waits for reply from 99.9.9.9:80.
> Actually the reply will come from proxy on 127.0.0.1:3128.
>
> Do you see the problem?

What, you wanna tell us that there is a way for the browser to directly connect
to the internet? As in... this ascii graph?


      INET
       |
SQUID--+
       |
      BROWSER



	-`J'
-- 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 19:48   ` saspan
  2007-01-19 22:23     ` Jan Engelhardt
@ 2007-01-19 22:34     ` Pascal Hambourg
  1 sibling, 0 replies; 8+ messages in thread
From: Pascal Hambourg @ 2007-01-19 22:34 UTC (permalink / raw)
  To: netfilter

saspan a écrit :
> 
> See: The browser sends http-request to e.g. 99.9.9.9.1:80.
> The request is redirected to proxy on 127.0.0.1:3128.
> Browser waits for reply from 99.9.9.9:80.
> Actually the reply will come from proxy on 127.0.0.1:3128.

Yes. Then the NAT code is supposed to translate it back to 99.9.9.9:80 
on its way to the browser. Is this actually what happens ?
What is the kernel version ?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: redirecting on a local machine
  2007-01-19 22:23     ` Jan Engelhardt
@ 2007-01-27 14:57       ` Jan Engelhardt
  0 siblings, 0 replies; 8+ messages in thread
From: Jan Engelhardt @ 2007-01-27 14:57 UTC (permalink / raw)
  To: saspan; +Cc: netfilter



On Jan 19 2007 23:23, Jan Engelhardt wrote:
>On Jan 19 2007 20:48, saspan wrote:
>>> > cause a browser would not be expecting a reply from a transparent
>>> > proxy when waiting for replies to its requests.
>>> 
>>> Huh ?
>>
>> See: The browser sends http-request to e.g. 99.9.9.9.1:80.
>> The request is redirected to proxy on 127.0.0.1:3128.
>> Browser waits for reply from 99.9.9.9:80.
>> Actually the reply will come from proxy on 127.0.0.1:3128.
>>
>> Do you see the problem?

And the box doing the redirect has which IP address (is where in your 
network scheme)?

	-`J'
-- 


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-01-27 14:57 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-19 18:44 redirecting on a local machine saspan
2007-01-19 18:47 ` Jan Engelhardt
2007-01-19 18:54   ` saspan
2007-01-19 19:24 ` Pascal Hambourg
2007-01-19 19:48   ` saspan
2007-01-19 22:23     ` Jan Engelhardt
2007-01-27 14:57       ` Jan Engelhardt
2007-01-19 22:34     ` Pascal Hambourg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.