Thanks !

well, I think that could have not worked because of (blind guesses):

- it should be dst port 3128 but that would be only for local  
connections, squid could be creating a second connection for the  
external iface to the destination using a different port (not 3128).

If squid has a specific user on the system, use marking based on the  
username owning the packet.

This has the limitation that would affect all users using squid, so  
you might not be able to create exceptions.

That's why I thought about about using connection marking on the  
input iface, but I gues wouldn't work neither because it would mark  
your connection between the localnet system and squid, and not  
squid's to external.

I'm basing all this on the asumption that squid creates a new  
connection to the target system. I read it nowhere, I'm guessing...  
sorry if wrong.

If that would be the case you might be able to use squid  
authentication to create some kind of internal squid marking, like  
ToS, and the use that value on shorewall as the base for new marking  
rules.

Don't know squid. But if you don't need exceptions the "marking based  
on user" is a fast an easy solution.

Hope it helps, jorge

Jorge Daza García-Blanes
[EMAIL PROTECTED] - GPG id: 5D7ACDEF


On 30/12/2006, at 14:31, Ismael Milach da Silveira wrote:

> This line looks to me a redirection to a 3128 (squid transparent
> proxy?), is it ?
>
> Then incomming traffic wouldn't have the proper mark using IP because
> source address has been changed by the local one, would also fail
> using iface name... I guess.
>
> ****************
>
> I think you're absolutely correct..
>
> One thing I thought would do the trick was to limit the traffic  
> coming from
> port 3128 to everywhere, tried that also.
>
> The other thing I did was to limit every traffic to dport 80,  
> coming from
> anywhere, (the dump attached on the previous post).  Now, why that  
> didn't
> work?
>
> Thanks Jorge!
>
> Ismael
>
>
>
>
>
> ----- Original Message -----
> From: "Jorge Daza García-Blanes" <[EMAIL PROTECTED]>
> To: "Shorewall Users" <[email protected]>
> Sent: Saturday, December 30, 2006 6:54 AM
> Subject: Re: [Shorewall-users] TC - not marking correctly
>
>
> Thanks for your non-flaming post Tom,
>
> I apologize.
>
> Now I've read the dump and will try to make a humble second guess, I
> think that somehow related to my first post.
>
> This has been taken from the dump:
> tcp      6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245
> sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128
> dport=33955 [ASSURED] mark=0 use=1
>
> This line looks to me a redirection to a 3128 (squid transparent
> proxy?), is it ?
>
> Then incomming traffic wouldn't have the proper mark using IP because
> source address has been changed by the local one, would also fail
> using iface name... I guess.
>
> So my guess is that this would be what I mentioned in the previous
> email as "natting".
>
> If that were correct, my guess is you could either use connection
> marks on mangle's prerouting and check for it. Or look for every
> packet... this might be a bit more complex because incomming traffic
> generated that way wouldn't have a known destionation port (comes
> from 80 but squid [or whoever] wouldn't be forced to use 3128 as
> destination port). As we wouldn't know at that point the destination
> local address, could also be harder to create exclusions or any other
> more refined marking rule...
>
> I have some theories on why that could also fail even if the
> masquerade theory is right (basically because you could have two tcp
> connections).
>
> But am I closer now at why it is marking right given the rules ?
>
> Now, show no mercy, I decided to live one more day. :)
>
> Jorge Daza García-Blanes
> [EMAIL PROTECTED] - GPG id: 5D7ACDEF
>
>
> On 30/12/2006, at 0:42, Tom Eastep wrote:
>
>> Jorge Daza García-Blanes wrote:
>>
>>>
>>> I just saw that the rule is in "tcfor" and the IP is local so,
>>> shouldn't it be in "tcout" ?
>>
>> Jorge,
>>
>> You often have to read between the lines when dealing with Shorewall
>> problem reports. The ifconfig output that made you think the IP is
>> local
>> was apparently obtained on a system other than where Shorewall is
>> running. I came to that conclusion by comparing that ifconfig output
>> with the dump attached to the same post.
>>
>> The dump showed the following:
>>
>> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
>>     link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff
>>     inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0
>>     inet6 fe80::240:f4ff:fecb:3375/64 scope link
>>        valid_lft forever preferred_lft forever
>> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>>     link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff
>>     inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1
>>     inet6 fe80::202:55ff:fe5e:faff/64 scope link
>>        valid_lft forever preferred_lft forever
>>
>> So it seems that the traffic in question is arriving on the  
>> firewall's
>> eth0 and being sent through eth1; hence, it will traverse the
>> 'tcfor' chain.
>>
>> -Tom
>> -- 
>> Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
>> Shoreline,     \ http://shorewall.net
>> Washington USA  \ [EMAIL PROTECTED]
>> PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ 
>> _
>> _______________
>> Shorewall-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Shorewall-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Shorewall-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shorewall-users


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to