On 08/19/2015 04:02 AM, Brian J. Murrell wrote: > Hi Tom, > > I'm running shorewall 4.6.11.1 on Fedora 22 as a master for a router > running shorewall-lite. I'm doing transparent proxying per > http://shorewall.net/Shorewall_Squid_Usage.html#Local. > > I have a providers entry of: > > Squid 3 0x400 - br-lan 10.75.22.247 > loose,notrack > > And a mangle entry of: > > MARK(0x400):P br-lan:!10.75.22.3,10.75.22.247 0.0.0.0/0 tcp 80 > MARK(0x400):P br-guest:!10.75.22.3,10.75.22.247 0.0.0.0/0 tcp 80 > > But I end up with a tcpre (and ~excl0 and ~excl1) looking like: > > Chain tcpre (1 references) > pkts bytes target prot opt in out source > destination > 0 0 MARK tcp -- br-lan * !10.75.22.3 0.0.0.0/0 > tcp dpt:80 MARK set 0x400 > 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 ~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 > > 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 > > Surely that first rule: > > 0 0 MARK tcp -- br-lan * !10.75.22.3 0.0.0.0/0 > tcp dpt:80 MARK set 0x400 > > in the tcpre table should not be there, right?
Right -- and it isn't there when I compile this configuration:
shorewall trace -vvv check -r . | less
export COLORTERM='mate-terminal'
export
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-GKT6hkgxs4,guid=7902f8877609f53d5719269b55d4b427'
export DESKTOP_SESSION='mate'
export DISPLAY=':0.0'
export DOGFOOD='loc:10.75.22.6'
export DSLIF='wan1'
...
Checking /home/teastep/shorewall/support/Brian/mangle...
IN===> MARK(0x400):P br-lan:!10.75.22.3,10.75.22.247 0.0.0.0/0
tcp 80
NF-(N)-> mangle:~excl0
NF-(!O4)-> mangle:~excl0
NF-(A)-> mangle:tcpre:1 -A tcpre -p 6 --dport 80
-i br-lan -j ~excl0
NF-(A)-> mangle:~excl0:1 -A ~excl0 -s 10.75.22.3
-j RETURN
NF-(A)-> mangle:~excl0:2 -A ~excl0 -s
10.75.22.247 -j RETURN
NF-(A)-> mangle:~excl0:3 -A ~excl0 -j MARK
--set-mark 0x400
Mangle Rule "MARK(0x400):P br-lan:!10.75.22.3,10.75.22.247 0.0.0.0/0
tcp 80" 0
IN===> MARK(0x400):P br-guest:!10.75.22.3,10.75.22.247 0.0.0.0/0
tcp 80
NF-(N)-> mangle:~excl1
NF-(!O4)-> mangle:~excl1
NF-(A)-> mangle:tcpre:2 -A tcpre -p 6 --dport 80
-i br-guest -j ~excl1
NF-(A)-> mangle:~excl1:1 -A ~excl1 -s 10.75.22.3
-j RETURN
NF-(A)-> mangle:~excl1:2 -A ~excl1 -s
10.75.22.247 -j RETURN
NF-(A)-> mangle:~excl1:3 -A ~excl1 -j MARK
--set-mark 0x400
Mangle Rule "MARK(0x400):P br-guest:!10.75.22.3,10.75.22.247
0.0.0.0/0 tcp 80" 0
...
:tcpre - [0:0]
:~excl0 - [0:0]
:~excl1 - [0:0]
-A PREROUTING -j CONNMARK --restore-mark --mask 0xff00
-A PREROUTING -i wan0 -m mark --mark 0/0xff00 -j routemark
-A PREROUTING -i wan1 -m mark --mark 0/0xff00 -j routemark
-A PREROUTING -m mark --mark 0/0xff00 -j tcpre
-A INPUT -j tcin
-A FORWARD -j MARK --set-mark 0/0xff00
-A FORWARD -j tcfor
-A OUTPUT -j CONNMARK --restore-mark --mask 0xff00
-A OUTPUT -m mark --mark 0/0xff00 -j tcout
-A POSTROUTING -j tcpost
-A routemark -i wan0 -j MARK --set-mark 0x100/0xff00
-A routemark -i wan1 -j MARK --set-mark 0x200/0xff00
-A routemark -m mark ! --mark 0/0xff00 -j CONNMARK --save-mark --mask 0xff00
-A tcpre -p 6 --dport 80 -i br-lan -j ~excl0
-A tcpre -p 6 --dport 80 -i br-guest -j ~excl1
-A ~excl0 -s 10.75.22.3 -j RETURN
-A ~excl0 -s 10.75.22.247 -j RETURN
-A ~excl0 -j MARK --set-mark 0x400
-A ~excl1 -s 10.75.22.3 -j RETURN
-A ~excl1 -s 10.75.22.247 -j RETURN
-A ~excl1 -j MARK --set-mark 0x400
COMMIT
>
> Also, I notice that transparent proxying adds a route to the main
> routing table such as:
>
> 10.75.22.247 dev br-lan scope link src 10.75.22.253
>
> I'm curious why that is needed.
Some kernel versions require a host route to a default gateway in the
main routing table before they will permit a default route to the
gateway to be added in a secondary routing table.
>
> But also, I notice that if you change the providers entry to a
> different IP address and then do a "shorewall reload" the above routing
> table entry for the old IP address is not removed from the main routing
> table.
>
We are going to have to live with that -- the compiler can't tell that
the gateway has changed, and deleting the route unconditionally when an
interface is disabled will break link monitoring via LSM.
Thanks,
-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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
