On 08/19/2015 12:38 PM, Brian J. Murrell wrote:
> On Wed, 2015-08-19 at 12:15 -0700, Tom Eastep wrote:
>>
>> Note that the first entry in mangle creates tcpre rule 4!! Do the 
>> same
>> thing searching for tcpre and see what is generating rules 1-3.
> 
> Ahhh!  I forgot that tcrules plays a part in all of this.  Indeed I had
> to add 10.75.22.247 to the exclude list in that rule such as:
> 
> 1024:P        br-lan:!10.75.22.3,10.75.22.247 0.0.0.0/0       tcp     80
> 
> and now mangle looks better:
> 
> Chain tcpre (1 references)
>  pkts bytes target     prot opt in     out     source               
> destination         
>     0     0 ~excl0     tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 
>            mark match ! 0x0/0x300
>     0     0 MARK       tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:25 MARK set 0x200
>     0     0 ~excl1     tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
>     0     0 ~excl2     tcp  --  br-guest *     0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
> 
> Chain ~excl0 (1 references)
>  pkts bytes target     prot opt in     out     source               
> destination         
>     0     0 RETURN     all  --  *      *       10.75.22.3           0.0.0.0/0 
>           
>     0     0 RETURN     all  --  *      *       10.75.22.247         0.0.0.0/0 
>           
>     0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0 
>            MARK set 0x400
> 
> Chain ~excl1 (1 references)
>  pkts bytes target     prot opt in     out     source               
> destination         
>     0     0 RETURN     all  --  *      *       10.75.22.3           0.0.0.0/0 
>           
>     0     0 RETURN     all  --  *      *       10.75.22.247         0.0.0.0/0 
>           
>     0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0 
>            MARK set 0x400
> 
> Chain ~excl2 (1 references)
>  pkts bytes target     prot opt in     out     source               
> destination         
>     0     0 RETURN     all  --  *      *       10.75.22.3           0.0.0.0/0 
>           
>     0     0 RETURN     all  --  *      *       10.75.22.247         0.0.0.0/0 
>           
>     0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0 
>            MARK set 0x400
> 
> It's interesting to note that ~excl[0-2] are all the same.  Room for an
> optimization here?  :-)

Inteed -- if you turn on the optimizer (OPTIMIZE=all), that duplication
will go away.

> 
> I also took notice that I needed a tcrules entry for br-guest also:
> 
> 1024:P        br-guest:!10.75.22.3,10.75.22.247 0.0.0.0/0     tcp     80
> 
> (which adds another duplicate of the above ~excl[0-2] chains FWIW)
> 
> Looking more closely at the specific tcpre chain though:
> 
> Chain tcpre (1 references)
>  pkts bytes target     prot opt in     out     source               
> destination         
>     0     0 ~excl0     tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
>     0     0 ~excl1     tcp  --  br-guest *     0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0 
>            mark match ! 0x0/0x300
>     0     0 MARK       tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:25 MARK set 0x200
>     0     0 ~excl2     tcp  --  br-lan *       0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
>     0     0 ~excl3     tcp  --  br-guest *     0.0.0.0/0            0.0.0.0/0 
>            tcp dpt:80
> 
> It seems that rules 1 and 4 are the same thing as are 2 and 5.  If I'm
> understanding correctly 1 and 2 are added by the tcrules entries.  Does
> that mean that the tcrules entries (as described at 
> http://shorewall.net/Shorewall_Squid_Usage.html#Local) are in fact
> superfluous and don't really need to be added?  Or is this something
> specific to my configuration of the Local transparent proxying that
> others would not benefit from for some reason?

The mangle file replaces the tcrules file -- I just haven't updated all
of the documentation that refers to tcrules.

> 
> And as usual when the number of files that contain information about a
> single "canned" feature grows to as many as this method of transparent
> proxying does, I wonder if another level of abstraction could be
> implemented getting all of this information into a single file and
> having Shorewall work out the needed iptables/routing/etc.
> configuration from that single file.

It practice, one should never have both a tcrules file and a mangle file
-- so that's one less file to deal with :-) Don't know that I want to
add another one for proxying, though...

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to