Hi all
I have a setup like the one discussed in
http://www.shorewall.net/MultiISP.html, but with only one physical nic
connected to the 2 ISP routers (refer to the figure below). I''m using
Shorewall 3.0.6 but I had similar results in a test with 3.2.8 too. CentOS 4
(similar to Red Hat), 2.6.9 pom-patched kernel, 1.2.9 pom-patched iptables.
I have two questions regarding this setup.
LAN
-------------------------------
|
|
eth1
+-------+
| Linux | Shorewall here
+-------+
eth0 192.168.21.2
11.11.111.186 / \ 22.222.222.218
/ \
11.11.111.177/ \22.222.222.217 MAC: 0014:0014:0014
MAC:0009:0009: +---+ +---+
0009 |LK1| |LK2| Internet provider''s
+---+ +---+ routers
| |
| |
...................
.........................
........ INTERNET .........
.............................
.............................
eth0 has 3 IP addresses: 2 for the 2 providers, one private for other
purposes. "ip addr" reports:
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:4f:3c:fb:97 brd ff:ff:ff:ff:ff:ff
inet 192.168.21.2/24 brd 192.168.21.255 scope global eth0
inet 11.11.111.186/28 brd 11.11.111.191 scope global eth0:0
inet 22.222.222.218/29 brd 22.222.222.223 scope global eth0:1
In the providers file I have:
LK2 2 2 main eth0 22.222.222.217 balance
LK1 1 1 main eth0 11.11.111.177 balance
In the tcrules file I have:
1:P 0.0.0.0/0
1 $FW
2:P 0.0.0.0/0 0.0.0.0/0 tcp 25
2 $FW 0.0.0.0/0 tcp 25
"ip route list" shows:
...
default
nexthop via 22.222.222.217 dev eth0 weight 1
nexthop via 11.11.111.177 dev eth0 weight 1
If I issue "ip rule list" I get:
0: from all lookup local
10001: from all fwmark 0x1 lookup LK1
10002: from all fwmark 0x2 lookup LK2
20001: from 192.168.21.2 lookup LK1
21001: from 11.11.111.186 lookup LK1
22001: from 22.222.222.218 lookup LK1
32766: from all lookup main
32767: from all lookup default
And here is the first question (the least important one to me):
Shouldn''t
the line "22001: from 22.222.222.218 lookup LK1" be "22001:
from
22.222.222.218 lookup LK2" ?
It seems that the last provider appearing in the providers file is more
important than the others, because it is used to route all the packets
coming from addresses of the firewall itself. But I find no reference to the
importance of the order in the providers file, and morevoer I think that
traffic from one provider''s IP should be routed via that
provider''s link.
On to the second question. If I generate SMTP traffic (port 25) from the lan
to the internet, it gets routed via LK2 (I see this from MAC addresses),
masqueraded with the 22.222.222.218 IP address (yes, masq is in action). If
I generate non-SMTP traffic, it gets routed via LK1, masqueraded with the
11.11.111.186 address. Allright.
Instead, if I generate traffic from the firewall (both SMTP and other
traffic) it gets routed through the correct provider (LK2 for SMTP, LK1 for
everything else), BUT the packets assumes randomly the 11.11.111.186 OR
22.222.222.218 source address. So there is a 50% chance that the replies get
back through the wrong provider.
I think the fact is that I am unable to configure the 2 masq rules as
required in http://www.shorewall.net/MultiISP.html, since I have only one
outbound interface. Maybe I would need the ability to masq the traffic with
one address or the other, based on the mark vale? (it would be SO simple if
locally generated traffic got as the IP source address the address closer to
the gateway it gets relayed to.. but this is not a shorewall question I
think).
Is there a solution for this problem?
Thanks
Luigi
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Lux wrote:> > "ip route list" shows: > ... > default > nexthop via 22.222.222.217 dev eth0 weight 1 > nexthop via 11.11.111.177 dev eth0 weight 1 > > If I issue "ip rule list" I get: > 0: from all lookup local > 10001: from all fwmark 0x1 lookup LK1 > 10002: from all fwmark 0x2 lookup LK2 > 20001: from 192.168.21.2 lookup LK1 > 21001: from 11.11.111.186 lookup LK1 > 22001: from 22.222.222.218 lookup LK1 > 32766: from all lookup main > 32767: from all lookup default > > And here is the first question (the least important one to me): Shouldn''t > the line "22001: from 22.222.222.218 lookup LK1" be "22001: from > 22.222.222.218 lookup LK2" ?It is a consequence of your oddball configuration (one interface with two uplinks). Shorewall determines the IP addresses on each provider interface and generates a route rule for each address. So in your configuration, whichever provider comes last will get all of these rules. There is no solution to this problem under Shorewall 3.0. Under Shorewall 3.2, you can specify the ''loose'' option for both providers and write your own correct route rules in /etc/shorewall/route_rules.> > > BUT the packets assumes randomly the 11.11.111.186 OR > 22.222.222.218 source address. So there is a 50% chance that the replies get > back through the wrong provider. > > Is there a solution for this problem?There was never any intention for Shorewall Multi-ISP support to handle this configuration. If the uplinks are handled by different ISPs, then you are bridging those ISPs'' internal networks which is usually considered to be "a bad thing(tm)". You can only solve this second problem by configuring firewall-local apps to use one local IP or the other (See the section entitled "Applications Running on the Firewall" in the Shorewall Multi-ISP documentation. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> [mailto:shorewall-users-bounces@lists.sourceforge.net]On Behalf Of Tom > Eastep> Lux wrote: > > > > > "ip route list" shows: > > ... > > default > > nexthop via 22.222.222.217 dev eth0 weight 1 > > nexthop via 11.11.111.177 dev eth0 weight 1 > > > > If I issue "ip rule list" I get: > > 0: from all lookup local > > 10001: from all fwmark 0x1 lookup LK1 > > 10002: from all fwmark 0x2 lookup LK2 > > 20001: from 192.168.21.2 lookup LK1 > > 21001: from 11.11.111.186 lookup LK1 > > 22001: from 22.222.222.218 lookup LK1 > > 32766: from all lookup main > > 32767: from all lookup default > > > > And here is the first question (the least important one to me): > Shouldn''t > > the line "22001: from 22.222.222.218 lookup LK1" be "22001: from > > 22.222.222.218 lookup LK2" ? > > It is a consequence of your oddball configuration (one interface with two > uplinks).Sorry for replying so late, but I wanted to make some tests. I don''t know exactly what oddball means, but it doesn''t have to be a compliment :) There are reasons for this setup, which I did not mention for simplicity. The routers are running a routing protocol, and HSRP, for example.> > BUT the packets assumes randomly the 11.11.111.186 OR > > 22.222.222.218 source address. So there is a 50% chance that > the replies get > > back through the wrong provider. > > > > Is there a solution for this problem? > > There was never any intention for Shorewall Multi-ISP support to > handle this > configuration.Ok but we could handle it correctly just now, and with small effort: as I supposed in my original posting, I found that the problem is solved if I am able to masq some traffic based on the presence of some mark value. So I wrote a very small patch for Shorewall 3.2.9 that does exactly that thing: add a mark column to the masq file, and add some logic to Shorewall to handle this. With the masq patch, my problem was solved by putting in the masq file something like: eth0 11.11.111.186 22.222.222.218 - - - 2 eth0 22.222.222.218 11.11.111.186 - - - 1 I also wrote patches to do analogous thing in the accounting, tos and rules file. Surely I find these not essential as the masq one is for me, but I found them useful: if someone marks some traffic, than it''s likely he wants to let it pass through the firewall too. So he can keep his config files smaller. I''d like if someone accustomed with Shorewall code could review them. You can find them attached to the message. Tank you. Luigi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Lux wrote:> > Ok but we could handle it correctly just now, and with small effort: as I > supposed in my original posting, I found that the problem is solved if I am > able to masq some traffic based on the presence of some mark value. So I > wrote a very small patch for Shorewall 3.2.9 that does exactly that thing: > add a mark column to the masq file, and add some logic to Shorewall to > handle this. > > With the masq patch, my problem was solved by putting in the masq file > something like: > eth0 11.11.111.186 22.222.222.218 - - - 2 > eth0 22.222.222.218 11.11.111.186 - - - 1 > > I also wrote patches to do analogous thing in the accounting, tos and rules > file. Surely I find these not essential as the masq one is for me, but I > found them useful: if someone marks some traffic, than it''s likely he wants > to let it pass through the firewall too. So he can keep his config files > smaller. > I''d like if someone accustomed with Shorewall code could review them. You > can find them attached to the message.Thanks for the patches. Unfortunately, 3.2.9 will be the last 3.2 release (except for bug fixes) because Shorewall 3.4.0 will be released shortly. Once 3.4.0 is out, I''ll look at modifying the patches for the 3.4 release. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV