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?  :-)

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?

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.

In any case...

Cheers and much thanks for the pointer to the source of my problem.

b.

Attachment: signature.asc
Description: This is a digitally signed message part

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

Reply via email to