Hi All, I have some questions (and assumptions (perhaps wrong)) relating to Multi-ISP setup. after reading www.shorewall.net/multiisp.html (and FAQ 57 and FAQ 58) also the the lartc docs. A similar setup to the diagram in the howto, but with a DMZ as well as a LAN. (4 nic''s). I have been using Shorewall for awhile now and I believe the firewalling side is fine. the setup : debian sarge, shorewall 3.2.3 3 DSL (ppp0,ppp1,ppp2) providers from the same ISP. (which means they have the same gateway, but different static ISP''s) 1 DMZ (eth2)- to host websites and email from 1 LAN (eth3) - for the office PC''s the Plan : * to balance outgoing web traffic to ease the load My assumptions : * the purpose of multi-homing is to share outgoing bandwidth load, i.e to direct outgoing traffic up a link different perhaps to where the request came in, or to balance outgoing traffic. * ''tcrules'' is used to decide (the routing rules) of which outgoing provider to send a packet to. * ''providers'' decides how to connection mark the incoming requests. My questions : * the track option. Track is used to mark a connection so that it returns out the same interface the request came in on. What does this mean if the plan is to balance to outgoing traffic ? i.e. send the replies up a different link ? In the section ''what an entry in the providers file does'' [snip] If you specify track, then connections which have had at least one packet arrive on the interface listed in the INTERFACE column have their connection mark set to the value in the MARK column. In the PREROUTING chain, packets with a connection mark have their packet mark set to the value of the associated connection mark; packets marked in this way bypass any prerouting rules that you create in /etc/shorewall/tcrules. This ensures that packets associated with connections from outside are always routed out of the correct interface. [snip] * is this saying that a provider with ''track'' specfied, does not get told where to go by tcrules ? [snip] The bottom line is that if you want traffic to go out through a particular provider then you must mark that traffic with the provider''s MARK value in /etc/shorewall/tcrules and you must do that marking in the PREROUTING chain. [snip] * This has me confused, the first snip appears to say the track option bypasses any pre-routing rules that are created by tcrules, the second snip appears to say if you want to direct traffic with tcrules you must do it in the pre-routing chain. * I believe there is a reason to send requests out the interface they came in, something to with ISP''s and IP Spoofing protection ? So how does a multi-home firewall fix this to balance outgoing traffic ? * I am thinking I am missing something fundamental here and would love to be set straight. providers : telstra1 1 1 main ppp0 track,balance eth2,eth3 telstra2 2 2 main ppp1 track,balance eth2,eth3 telstra3 3 3 main ppp2 track,balance eth2,eth3 I get an error with the eth2,eth3 at the end, I am not quite sure what they do. the 3 uplinks have the static ip addresses but share the same gateway. Regards, Richard Hatherly Ritech Computing Services ------------------------------------------------------------------------- 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
Richard wrote:> ... > debian sarge, shorewall 3.2.3 > 3 DSL (ppp0,ppp1,ppp2) providers from the same ISP. (which means they have > the same gateway, but different static ISP''s)Do they actually have the same peer address?> ... > * the purpose of multi-homing is to share outgoing bandwidth load, i.e to > direct outgoing traffic up a link different perhaps to where the request > came in, or to balance outgoing traffic.Correct.> * ''tcrules'' is used to decide (the routing rules) of which outgoing provider > to send a packet to. > * ''providers'' decides how to connection mark the incoming requests.Providers also sets up your load-balanced outbound routing.> * the track option. Track is used to mark a connection so that it returns > out the same interface the request came in on. What does this mean if the > plan is to balance to outgoing traffic ? i.e. send the replies up a > different link ?You should use track (and balance, and i recommend optional as well). The outgoing balancing will not be affected by this option.> ... > [snip] If you specify track, then connections which have had at least one > packet arrive on the interface listed in the INTERFACE column have their > connection mark set to the value in the MARK column. In the PREROUTING > chain, packets with a connection mark have their packet mark set to the > value of the associated connection mark; packets marked in this way bypass > any prerouting rules that you create in /etc/shorewall/tcrules. This ensures > that packets associated with connections from outside are always routed out > of the correct interface. [snip] > > * is this saying that a provider with ''track'' specfied, does not get told > where to go by tcrules ?Yes, but only for incoming connections on that interface.> [snip] The bottom line is that if you want traffic to go out through a > particular provider then you must mark that traffic with the provider''s MARK > value in /etc/shorewall/tcrules and you must do that marking in the > PREROUTING chain. [snip] > > * This has me confused, the first snip appears to say the track option > bypasses any pre-routing rules that are created by tcrules, the second snip > appears to say if you want to direct traffic with tcrules you must do it in > the pre-routing chain.The second snip is about outgoing connections.> * I believe there is a reason to send requests out the interface they came > in, something to with ISP''s and IP Spoofing protection ?It might work in your setup (since you''re using the same DSL provider for all three interfaces), but you should route them back out the same interface. This gives you the flexibility of changing to a different provider later if you need to.> So how does a multi-home firewall fix this to balance outgoing traffic ?Multihoming doesn''t balance incoming connections.> * I am thinking I am missing something fundamental here and would love to be > set straight.Your main issue is thinking about all outgoing packets as being the same. Outgoing reply packets on incoming connections need the track option to be routed correctly. Outgoing packets on connections initiated from your end are routed according to the rules created by the combination of providers and tcrules.> I get an error with the eth2,eth3 at the end, I am not quite sure what they > do.I think using just eth3 might work for you. Paul ------------------------------------------------------------------------- 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
Richard wrote:> > providers : > > telstra1 1 1 main ppp0 track,balance eth2,eth3 > telstra2 2 2 main ppp1 track,balance eth2,eth3 > telstra3 3 3 main ppp2 track,balance eth2,eth3 > > I get an error with the eth2,eth3 at the end, I am not quite sure what they > do. >That''s like saying "I had a problem when I walked down Post Street yesterday; what should I do?" If you have an unresolvable problem with "shorewall [re]start", we need a trace. See http://www.shorewall.net/support.htm#Guidelines As to "I''m not quite sure what they do"... Having read the LARTC, you hopefully understand the concepts of packet marking, multiple routing tables and routing rules that select a routing table based on the packet mark. If you don''t, any explanation that I give you will be pretty meaningless. Shorewall has this silly idea that when a response packet is received from the Internet, the routing of that packet should be governed by the same routing table that was used to route the original outgoing request. In retrospect, that may be a warped notion but it is what Shorewall implements. When you define a ''provider'' in /etc/shorewall/providers, you are actually defining a routing table. So that means that any routing table (e.g., provider) that you define must be capable of routing response packets for any outgoing request packet that can be sent using that routing table. That requires that routes from any host that could have sent a request out of each provider have a route in that provider''s routing table. Still with me? All routes in the main table (or whatever table is mentioned in the DUPLICATE column) have an associated interface. The way that Shorewall builds the provider-specific routing tables is to copy entries from the table specified in the DUPLICATE column. The COPY column specifies the interfaces whose entries in the DUPLICATE table will be copied to the provider-specific table. In other words, it names the interfaces which could provide requests that could be routed out through the provider. Make sense? As I have hinted, I think that I probably got it wrong -- but it is what we have currently so until 3.4, we must live with it. -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
Tom Eastep wrote:> > All routes in the main table (or whatever table is mentioned in the > DUPLICATE column) have an associated interface. The way that Shorewall > builds the provider-specific routing tables is to copy entries from the > table specified in the DUPLICATE column. The COPY column specifies the > interfaces whose entries in the DUPLICATE table will be copied to the > provider-specific table. In other words, it names the interfaces which > could provide requests that could be routed out through the provider. > > Make sense? > > As I have hinted, I think that I probably got it wrong -- but it is what > we have currently so until 3.4, we must live with it. >Every time I think about how this works, I forget one important point. Packet marking for routing must be done before we know where the packet is going (that''s the point). Which means that traffic that is being marked may not be headed for the internet at all but may be routed out a local interface instead (a DMZ for example). That is another reason that each provider routing table must have the routes to all local interfaces. So I didn''t get it wrong after all. About the only additional optimization that I could make would be to not mark packets from ''tracked'' interfaces (just mark the connection). But that wouldn''t remove the need for DUPLICATE and COPY columns in the file. -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