Transparent proxy question

Transparent proxy question

[Sasa Stupar]

Hi!

I have configure a transparent proxy and it is working fine. But now all 
requests to squid came from my nat box and I can't use my MAC acl 
anymore. Is there any option to provide to squid who is connecting and 
not the nat box which is used for transparency?

Regards,
Sasa

Re: Transparent proxy question

[Antony Stone]

On Monday 15 March 2004 8:52 am, Sasa Stupar wrote:

> Hi!
>
> I have configure a transparent proxy and it is working fine. But now all
> requests to squid came from my nat box and I can't use my MAC acl
> anymore. Is there any option to provide to squid who is connecting and
> not the nat box which is used for transparency?

If you really mean MAC address based ACL, then no, you cannot use this to 
identify clients any more, because all the packets will be coming from the 
netfilter machine, so that is the only MAC address your proxy will know 
about.

If you actually mean source IP address based ACL, then you need to check your 
SNAT rule in the POSTROUTING chain of netfilter - make sure it is only 
applied to your external interface, not the interface where your proxy server 
is connected.

If you have a more complicated network setup than I am assuming, please supply 
a description or a diagram.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Transparent proxy question

[Sasa Stupar]

Antony Stone pravi:

> On Monday 15 March 2004 8:52 am, Sasa Stupar wrote:
> 
> 
>>Hi!
>>
>>I have configure a transparent proxy and it is working fine. But now all
>>requests to squid came from my nat box and I can't use my MAC acl
>>anymore. Is there any option to provide to squid who is connecting and
>>not the nat box which is used for transparency?
> 
> 
> If you really mean MAC address based ACL, then no, you cannot use this to 
> identify clients any more, because all the packets will be coming from the 
> netfilter machine, so that is the only MAC address your proxy will know 
> about.
> 
> If you actually mean source IP address based ACL, then you need to check your 
> SNAT rule in the POSTROUTING chain of netfilter - make sure it is only 
> applied to your external interface, not the interface where your proxy server 
> is connected.
> 
> If you have a more complicated network setup than I am assuming, please supply 
> a description or a diagram.
> 
> Regards,
> 
> Antony.
> 

Yes, I ahve ment source IP bassed, sorry my mistake. Anyway here is my 
config for trasparent proxy:
-------------------
$IPT -t nat -A PREROUTING -i $INIF -s ! 192.168.10.10 -p tcp --dport 80 
-j DNAT --to 192.168.10.10:3128
$IPT -t nat -A POSTROUTING -o $INIF -s $INNET -d 192.168.10.10 -j SNAT 
--to 192.168.10.111
$IPT -A FORWARD -s $INNET -d 192.168.10.10 -i $INIF -o $INIF -p tcp 
--dport 3128 -j ACCEPT
-------------------
Description:
192.168.10.10 is proxy server
192.168.10.111 is netfilter machine
INIF=192.168.10.111
INNET=192.168.10.0/24

Is there something to add or change here?

Regards,
Sasa

Re: Transparent proxy question

[Antony Stone]

On Monday 15 March 2004 9:38 am, Sasa Stupar wrote:

> Antony Stone pravi:
> >
> > If you actually mean source IP address based ACL, then you need to check
> > your SNAT rule in the POSTROUTING chain of netfilter - make sure it is
> > only applied to your external interface, not the interface where your
> > proxy server is connected.
>
> Yes, I ahve ment source IP bassed, sorry my mistake. Anyway here is my
> config for trasparent proxy:
> -------------------
> $IPT -t nat -A PREROUTING -i $INIF -s ! 192.168.10.10 -p tcp --dport 80
> -j DNAT --to 192.168.10.10:3128
> $IPT -t nat -A POSTROUTING -o $INIF -s $INNET -d 192.168.10.10 -j SNAT
> --to 192.168.10.111
> $IPT -A FORWARD -s $INNET -d 192.168.10.10 -i $INIF -o $INIF -p tcp
> --dport 3128 -j ACCEPT
> -------------------
> Description:
> 192.168.10.10 is proxy server
> 192.168.10.111 is netfilter machine
> INIF=192.168.10.111
> INNET=192.168.10.0/24
>
> Is there something to add or change here?

Yes.   Remove the POSTROUTING rule, because it is specifically changing the 
source address of all packets sent to the proxy server to be that of the 
firewall.

Regards,

Antony.

-- 
"Note: Windows 98, Windows 98SE and Windows 95 are not affected by [MS
Blaster].   However, these products are no longer supported.   Users of these
products are strongly encouraged to upgrade to later versions."

(which *are* affected by MS Blaster...)

http://www.microsoft.com/security/security_bulletins/ms03-026.asp

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Transparent proxy question

[Sasa Stupar]

Antony Stone pravi:

> On Monday 15 March 2004 9:38 am, Sasa Stupar wrote:
> 
> 
>>Antony Stone pravi:
>>
>>>If you actually mean source IP address based ACL, then you need to check
>>>your SNAT rule in the POSTROUTING chain of netfilter - make sure it is
>>>only applied to your external interface, not the interface where your
>>>proxy server is connected.
>>
>>Yes, I ahve ment source IP bassed, sorry my mistake. Anyway here is my
>>config for trasparent proxy:
>>-------------------
>>$IPT -t nat -A PREROUTING -i $INIF -s ! 192.168.10.10 -p tcp --dport 80
>>-j DNAT --to 192.168.10.10:3128
>>$IPT -t nat -A POSTROUTING -o $INIF -s $INNET -d 192.168.10.10 -j SNAT
>>--to 192.168.10.111
>>$IPT -A FORWARD -s $INNET -d 192.168.10.10 -i $INIF -o $INIF -p tcp
>>--dport 3128 -j ACCEPT
>>-------------------
>>Description:
>>192.168.10.10 is proxy server
>>192.168.10.111 is netfilter machine
>>INIF=192.168.10.111
>>INNET=192.168.10.0/24
>>
>>Is there something to add or change here?
> 
> 
> Yes.   Remove the POSTROUTING rule, because it is specifically changing the 
> source address of all packets sent to the proxy server to be that of the 
> firewall.
> 
> Regards,
> 
> Antony.
> 

Not good. Now my transparent proxy doesn't work anymore. :(
What's the catch?

Regards,
Sasa

PS: sorry Antony for sending directly to you but this list doesn't 
automatically put the list address when replying. Maybe something for 
moderators to configure.

Re: Transparent proxy question

[Antony Stone]

On Monday 15 March 2004 10:51 am, Sasa Stupar wrote:

> PS: sorry Antony for sending directly to you but this list doesn't
> automatically put the list address when replying. Maybe something for
> moderators to configure.

http://www.unicom.com/pw/reply-to-harmful.html

 :)

Antony.

-- 
Christmas was just an opportunity to upgrade to kernel 2.6 while no-one was 
around to notice the downtime.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Transparent proxy question

[Antony Stone]

On Monday 15 March 2004 10:47 am, Sasa Stupar wrote:

> Antony Stone pravi:
>
> > > $IPT -t nat -A POSTROUTING -o $INIF -s $INNET -d 192.168.10.10 -j SNAT
> > > --to 192.168.10.111
> > >
> > > Is there something to add or change here?
> >
> > Yes.   Remove the POSTROUTING rule, because it is specifically changing
> > the source address of all packets sent to the proxy server to be that of
> > the firewall.
>
> Not good. Now my transparent proxy doesn't work anymore. :(
> What's the catch?

1. Now that it isn't working, do you get any errors in your proxy log file, or 
does it think there are no requests?
2. What source IPs does your proxy server allow access for?
3. Does the proxy server know how to route back to the clients?
4. Do you have a suitable ESTABLISHED,RELATED rule on your firewall to allow 
back the replies?   (I expect so, but you didn't post your full ruleset 
earlier, so I can't be sure...)
5. Where are the clients on the network in relation to the firewall and the 
proxy server (please don't tell me they're on the same subnet as the 
proxy...?)

Regards,

Antony.

-- 
Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

Re: Transparent proxy question

[Sasa Stupar]

Antony Stone pravi:

> On Monday 15 March 2004 10:47 am, Sasa Stupar wrote:
> 
> 
>>Antony Stone pravi:
>>
>>
>>>>$IPT -t nat -A POSTROUTING -o $INIF -s $INNET -d 192.168.10.10 -j SNAT
>>>>--to 192.168.10.111
>>>>
>>>>Is there something to add or change here?
>>>
>>>Yes.   Remove the POSTROUTING rule, because it is specifically changing
>>>the source address of all packets sent to the proxy server to be that of
>>>the firewall.
>>
>>Not good. Now my transparent proxy doesn't work anymore. :(
>>What's the catch?
> 
> 
> 1. Now that it isn't working, do you get any errors in your proxy log file, or 
> does it think there are no requests?
> 2. What source IPs does your proxy server allow access for?
> 3. Does the proxy server know how to route back to the clients?
> 4. Do you have a suitable ESTABLISHED,RELATED rule on your firewall to allow 
> back the replies?   (I expect so, but you didn't post your full ruleset 
> earlier, so I can't be sure...)
> 5. Where are the clients on the network in relation to the firewall and the 
> proxy server (please don't tell me they're on the same subnet as the 
> proxy...?)
> 
> Regards,
> 
> Antony.
> 

1. I've got nothing in the squid log but in the browser I get Timeout 
error, so looks like squid doesn't get any requests
2. It allows for LAN IP's
3. Yep
4. Yep $IPT -A STATE -m state --state ESTABLISHED,RELATED -j ACCEPT
5. Some of them are on the same subnet and some not.

Regards,
Sasa

Re: Transparent proxy question

[Antony Stone]

On Monday 15 March 2004 11:07 am, Sasa Stupar wrote:

> Antony Stone pravi:
>
> > 1. Now that it isn't working, do you get any errors in your proxy log
> > file, or does it think there are no requests?
> > 2. What source IPs does your proxy server allow access for?
> > 3. Does the proxy server know how to route back to the clients?
> > 4. Do you have a suitable ESTABLISHED,RELATED rule on your firewall to
> > allow back the replies?   (I expect so, but you didn't post your full
> > ruleset earlier, so I can't be sure...)
> > 5. Where are the clients on the network in relation to the firewall and
> > the proxy server (please don't tell me they're on the same subnet as the
> > proxy...?)
>
> 1. I've got nothing in the squid log but in the browser I get Timeout
> error, so looks like squid doesn't get any requests
> 2. It allows for LAN IP's
> 3. Yep
> 4. Yep $IPT -A STATE -m state --state ESTABLISHED,RELATED -j ACCEPT
> 5. Some of them are on the same subnet and some not.

Okay, first off, you will not be able to do what you want for clients which 
are on the same subnet as the proxy server - the only way to get them 
communicating through the firewall is to SNAT the packets on the way out of 
the firewall.   If you want their real IPs to be seen by the proxy, configure 
the clients to use the proxy instead of doing it transparently.

Second, are you experiencing the same problem (clients can no longer access 
proxy) for both clients which are on the same subnet as the proxy (I expect 
this to fail) and clients which are not?

Regards,

Antony.

-- 
This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

                                                     Please reply to the list;
                                                           please don't CC me.