Hello all.
First of all, please be a bit indulgent to my poor English :-).
Second, this message is "kinda" BIG, so if you don''t like BIG
messages, simply don''t read it :-).
I''ve read http://shorewall.net/2.0/Shorewall_and_Routing.html
and http://shorewall.net/MultiISP.html, however I still a bit confused how
to organize what I need :-).
I''ve a simple "layout" like a lot of people here have:
eth0
LAN (192.168.1.0/24) ------ Shorewall --- eth1 --- DSL --- SVR
|
+--- eth2 --- DSL ---
OGO
"Shorewall" box is a RH 7.3, Shorewall itself is version 2.4.7.
Preface :-).
1. SVR is very good, but expensive ISP. However, all kind of local
(Ukranian) traffic is free of charge.
2. OGO is not so good as SVR, but its cheap. However, it doesn''t make
a difference between local and foreign traffic -- it charges any traffic.
3. There is an URL, where I can grab current version of local subnets list.
That list changes frequently, so we do grabbing every 15 mins.
4. I don''t need any kind of load balancing! :-)
What do I need?
1. For most LAN default route is OGO.
1.1. All local traffic should be routed to SVR.
1.2. Traffic from some IPs in the LAN (192.168.1.2, 3 and 4) should be
routed only over SVR (CIO, CEO and other "officers" :-).
2. If OGO is down, all traffic (not only local) from the LAN (including
"officer''s" traffic) should go over SVR.
2.1. Otherwise, if SVR is down, all traffic including 192.168.1.2, 3 and
4''s, should go over OGO.
2.2. Once we detects that OGO is up again, all traffic from LAN goes
over OGO again, local traffic goes over SVR, "officer''s"
traffic over SVR.
How do I plan to implement that and what questions I have?
1. Set default gw to OGO :-).
1.1. Grab the list of local subnets via bash script every 15 min and then
implement proper "route" command for every row in that list in order
to
point local traffic over SVR.
1.2. Here is Q: is that possible to do with Shorewall itself? Or I need to
do that via "ip route" manually? Tom says: "As of this writing, I
know of
no distribution that is shipping a kernel or iptables with the ROUTE target
patch included. This means that you must patch and build your own kernel
and iptables in order to be able to use the feature described in this
section.
This code remains experimental since there is no intent by the Netfilter
team to ever submit the ROUTE target patch for inclusion in the official
kernels from kernel.org. This support may also be removed from Shore-
wall in a future release." And this is my "shorewall show
capabilities":
[root@k9-66 root]# shorewall show capabilities
Loading /usr/share/shorewall/functions...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Shorewall has detected the following iptables/netfilter capabilities:
NAT: Available
Packet Mangling: Available
Multi-port Match: Available
Extended Multi-port Match: Not available
Connection Tracking Match: Not available
Packet Type Match: Not available
Policy Match: Not available
Physdev Match: Not available
IP range Match: Not available
Recent Match: Not available
Owner Match: Available
Ipset Match: Not available
ROUTE Target: Not available
^^^^^^^^^^^^ -- so /etc/shorewall/routes is not for me! :-(
Extended MARK Target: Not available
CONNMARK Target: Not available
^^^^^^^^^^^^ -- so "track" option in the /etc/shorewall/providers
also not for me :-( (w/o recompiling kernel/iptables).
Connmark Match: Not available
Raw Table: Not available
[root@k9-66 root]#
2, 2.1 and 2.2 I plan to implement via bash script (not a topic to
discuss here :-).
Finally, I think my /etc/shorewall should be like that:
- interfaces:
svr eth1 detect norfc1918,nobogons,routefilter,blacklist,tcpflags,
routeback,nosmurfs
ogo eth2 detect norfc1918,nobogons,routefilter,blacklist,tcpflags,
routeback,nosmurfs
loc eth0 detect tcpflags,nosmurfs
- masq:
eth1 eth0
eth2 eth0
Using the above masq file means that PBR for so called officers is organized
via "ip route" by the script and can be switched off by the script, if
needed.
- policy:
loc fw ACCEPT
loc svr ACCEPT
loc ogo ACCEPT
fw loc ACCEPT
fw svr ACCEPT
fw ogo ACCEPT
all all DROP
- providers:
SVR 1 1 main eth1 IP.OF.SVR.GW track (?) eth0
OGO 2 2 main eth2 IP.OF.OGO.GW track (?) eth0
- zones:
svr svr svr
ogo ogo ogo
loc loc loc
- rules:
AllowPing svr fw
AllowSSH svr fw
AllowFTP svr fw
AllowSMTP svr fw
AllowPing ogo fw
AllowSSH ogo fw
AllowFTP ogo fw
AllowSMTP ogo fw
So, the main Q is: if I use PBR via "ip route" command from the
script,
will the above files do exactly what I want? I think, no :-). Any help is
appreciated. Thanks.
--
MNV-UANIC
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642