Well, it probably is working. I'm probably just misunderstanding something.
Given routing rules that look like this:
0: from all lookup local
10000: from all fwmark 0x40 lookup CGCO
10001: from all fwmark 0x80 lookup IGS
20000: from 67.193.45.68 lookup CGCO
20256: from 66.11.173.224 lookup IGS
32766: from all lookup main
32767: from all lookup default
and given the CGCO routing table:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
67.193.45.68 dev eth0.1 scope link
192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224
10.8.0.0/24 via 10.8.0.2 dev tun0
10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254
10.75.23.0/24 via 10.8.0.2 dev tun0
67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68
default via 67.193.44.1 dev eth0.1
and the main routing table:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224
10.8.0.0/24 via 10.8.0.2 dev tun0
10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254
10.75.23.0/24 via 10.8.0.2 dev tun0
67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68
169.254.0.0/16 via 10.75.22.223 dev br-lan proto zebra metric 20 equalize
default
nexthop via 67.193.44.1 dev eth0.1 weight 1
nexthop via 192.168.200.1 dev ppp0 weight 1
and given a routemark chain of (which I don't think is really much
relevant -- I added those set marks after this started happening but it
does not seem to be the solution):
Chain routemark (2 references)
pkts bytes target prot opt in out source destination
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:1194 MARK set 0x40
6 252 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:1194 MARK set 0x40
332 46438 MARK all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
MARK set 0x80
4600 737K MARK all -- eth0.1 * 0.0.0.0/0 0.0.0.0/0
MARK set 0x40
4932 783K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match !0x0/0xff CONNMARK save mask 0xff
and given the following entry in the /proc/net/ip_conntrack
udp 17 59 src=99.228.107.5 dst=67.193.45.68 sport=34725 dport=1194
packets=47 bytes=1974 [UNREPLIED] src=67.193.45.68 dst=99.228.107.5 sport=1194
dport=34725 packets=0 bytes=0 mark=64 use=1
Why am I seeing these:
Dec 28 17:19:18 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=42 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34725 LEN=22
Dec 28 17:19:18 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=50 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34725 LEN=30
Dec 28 17:19:20 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=42 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34725 LEN=22
Dec 28 17:19:20 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=50 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34725 LEN=30
It seems to me that given that the connection is marked with 64 (0x40)
that the route rules should be shoving that to the CGCO routing table
and causing those packets to be sent via the eth0.1 interface, no?
I do understand that with two default routes with equal weights that the
active default gateways will be alternated round robin, but I would have
thought that the mark on that connection and the route rules and tables
would have trumped that.
Thots?
b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
