Hi all, I am trying to configure a firewall with 2 ISPs, difference between them is the strictness of the firewall. some zones have to route via ISP1, some via ISP2. What do I need to put in the providers file? More in particular, what does DUPLICATE do exactly and what should I put there? Thanks in adv, Erwin ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
On Wed, 2007-12-05 at 16:41 +0100, Erwin Van de Velde wrote:> Hi all, > > I am trying to configure a firewall with 2 ISPs, difference between them is > the strictness of the firewall. some zones have to route via ISP1, some via > ISP2. > What do I need to put in the providers file? More in particular, what does > DUPLICATE do exactly and what should I put there?Adding an entry to /etc/shorewall/providers creates a routing table. Now, a routing table is useless unless it is populated with routes. Shorewall will always add a default route via the GATEWAY to the table but you need additional routes if you specify the ''track'' option. That is because when ''track'' is specified, traffic entering the INTERFACE is routed using the provider''s table. I regret having designed the facility in this way and I''m thinking of providing an option to change it in Shorewall 4.2. But in the mean time, when ''track'' is given, you normally will want to copy the routes to your local networks into the provider''s routing table. To do that, you enter ''main'' in the DUPLICATE column and you list your local interfaces in the COPY column. That way, traffic entering a tracked interface can be routed to the local networks. HTH, -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 ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
On Wed, 2007-12-05 at 08:11 -0800, Tom Eastep wrote:> On Wed, 2007-12-05 at 16:41 +0100, Erwin Van de Velde wrote: > > Hi all, > > > > I am trying to configure a firewall with 2 ISPs, difference between them is > > the strictness of the firewall. some zones have to route via ISP1, some via > > ISP2. > > What do I need to put in the providers file? More in particular, what does > > DUPLICATE do exactly and what should I put there? > > Adding an entry to /etc/shorewall/providers creates a routing table. > Now, a routing table is useless unless it is populated with routes. > Shorewall will always add a default route via the GATEWAY to the table > but you need additional routes if you specify the ''track'' option. That > is because when ''track'' is specified, traffic entering the INTERFACE is > routed using the provider''s table. > > I regret having designed the facility in this way and I''m thinking of > providing an option to change it in Shorewall 4.2. But in the mean time, > when ''track'' is given, you normally will want to copy the routes to your > local networks into the provider''s routing table. To do that, you enter > ''main'' in the DUPLICATE column and you list your local interfaces in the > COPY column. That way, traffic entering a tracked interface can be > routed to the local networks.I always forget there is another factor here. Let''s suppose you have the following: ISP1 ISP2 | | -------------------- | | | Firewall |-- DMZ | | --------------------- | LOC If you mark traffic from LOC in PREROUTING based on protocol and port, then that traffic will be routed based on whether it will go to ISP1 or ISP2. But suppose that it goes to the DMZ! So you need to include the route to the DMZ in the routing tables for both ISP1 and ISP2. That is independent of whether you use ''track'' or not. -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 ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
On Wed, 2007-12-05 at 09:07 -0800, Tom Eastep wrote:> > I always forget there is another factor here. > > Let''s suppose you have the following: > > ISP1 ISP2 > | | > -------------------- > | | > | Firewall |-- DMZ > | | > --------------------- > | > LOC > > If you mark traffic from LOC in PREROUTING based on protocol and port, > then that traffic will be routed based on whether it will go to ISP1 or > ISP2. But suppose that it goes to the DMZ! So you need to include the > route to the DMZ in the routing tables for both ISP1 and ISP2. That is > independent of whether you use ''track'' or not.Note that you could also add a routing rule in the 1000-1999 range, sending traffic to the DMZ address range through the main table (254). I do that here with my DMZ which has one system (206.124.146.177): #SOURCE DEST PROVIDER PRIORITY - 206.124.146.177 254 1000 -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 ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Hi, Thank you for the response. It will take some time before I can test it on the real firewall (maintenance is at the end of each month), but now I can start to prepare it whenever I have time. Regards, Erwin ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Hi all, I have to add a problem here: Suppose I have to NAT for ISP1 and not for ISP2. Is there a way to do this? e.g. Can I use the marks of the providers file to create MASQ rules for ISP1? Regards, Erwin On Wednesday 05 December 2007, Tom Eastep wrote:> On Wed, 2007-12-05 at 09:07 -0800, Tom Eastep wrote: > > I always forget there is another factor here. > > > > Let''s suppose you have the following: > > > > ISP1 ISP2 > > > > -------------------- > > > > | Firewall |-- DMZ > > > > --------------------- > > > > LOC > > > > If you mark traffic from LOC in PREROUTING based on protocol and port, > > then that traffic will be routed based on whether it will go to ISP1 or > > ISP2. But suppose that it goes to the DMZ! So you need to include the > > route to the DMZ in the routing tables for both ISP1 and ISP2. That is > > independent of whether you use ''track'' or not. > > Note that you could also add a routing rule in the 1000-1999 range, > sending traffic to the DMZ address range through the main table (254). I > do that here with my DMZ which has one system (206.124.146.177): > > #SOURCE DEST PROVIDER PRIORITY > - 206.124.146.177 254 1000 > > -Tom------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Erwin Van de Velde wrote:> Hi all, > > I have to add a problem here: > Suppose I have to NAT for ISP1 and not for ISP2. Is there a way to do this? > e.g. Can I use the marks of the providers file to create MASQ rules for ISP1?Why would you need marks? The outgoing interface is specified explicitly in /etc/shorewall/masq. -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 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
On Monday 10 December 2007, Tom Eastep wrote:> Why would you need marks? The outgoing interface is specified explicitly in > /etc/shorewall/masq.If I understand this correctly, all trafic with the source defined in the masq rules but leaving the firewall through another interface does not get NAT''ed? Thanks in adv, Erwin ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Erwin Van de Velde wrote:> On Monday 10 December 2007, Tom Eastep wrote: >> Why would you need marks? The outgoing interface is specified explicitly in >> /etc/shorewall/masq. > > If I understand this correctly, all trafic with the source defined in the masq > rules but leaving the firewall through another interface does not get NAT''ed?It is true that if you don''t have a masq rule that covers certain traffic then that traffic will not have its source IP address rewritten. But that doesn''t have anything to do with packet marks. -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 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php