I have Shorewall set up to load balance between two connections (using the
"providers" file). However, I don''t want this to be used for
outgoing http
connections originating on the firewall {I''m really trying to do
something
more complex than this, but want to get this working as the first step}. I
tried this in tcrules:
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
TEST
# PORT(S)
1 $FW 0.0.0.0/0 tcp 80
But it doesn''t seem to have any effect (outgoing http connections
originating on the firewall still use both interfaces).
If I change $FW to 10.1.0.0/255.255.255.0 (my internal network) then all the
HTTP connections originating in my internal network use only connection #1,
but I just can''t seem to get it to work properly with connections
originating on the firewall.
Let me know if you need more information.
Thanks for all your help,
Matt
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
----- Original Message ----- From: "Matt N" <voyager6868@hotmail.com> To: <shorewall-users@lists.sourceforge.net> Sent: Sunday, July 17, 2005 22:12 Subject: [Shorewall-users] Routing Packets Originating on the Firewall> I have Shorewall set up to load balance between two connections (usingthe> "providers" file). However, I don''t want this to be used for outgoinghttp> connections originating on the firewall {I''m really trying to dosomething> more complex than this, but want to get this working as the first step}.I> tried this in tcrules: > > #MARK SOURCE DEST PROTO PORT(S) CLIENTUSER> TEST > # PORT(S) > 1 $FW 0.0.0.0/0 tcp 80 > > But it doesn''t seem to have any effect (outgoing http connections > originating on the firewall still use both interfaces). > > If I change $FW to 10.1.0.0/255.255.255.0 (my internal network) then allthe> HTTP connections originating in my internal network use only connection#1,> but I just can''t seem to get it to work properly with connections > originating on the firewall. > > Let me know if you need more information. >From tcrules: "$FW may be optionally followed by ":" and a host/network address." So try: 1 $FW:<extip4provider/32> 0.0.0.0/0 tcp 80 Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > Sent: Monday, July 18, 2005 1:29 > To: shorewall-users@lists.sourceforge.net > Subject: *****SPAM***** Re: [Shorewall-users] Routing Packets Originating > on the Firewall > > > ----- Original Message ----- > From: "Matt N" <voyager6868@hotmail.com> > To: <shorewall-users@lists.sourceforge.net> > Sent: Sunday, July 17, 2005 22:12 > Subject: [Shorewall-users] Routing Packets Originating on the Firewall > > > > I have Shorewall set up to load balance between two connections (using > the > > "providers" file). However, I don''t want this to be used for outgoing > http > > connections originating on the firewall {I''m really trying to do > something > > more complex than this, but want to get this working as the first step}. > I > > tried this in tcrules: > > > > #MARK SOURCE DEST PROTO PORT(S) CLIENT > USER > > TEST > > # PORT(S) > > 1 $FW 0.0.0.0/0 tcp 80 > > > > But it doesn''t seem to have any effect (outgoing http connections > > originating on the firewall still use both interfaces). > > > > If I change $FW to 10.1.0.0/255.255.255.0 (my internal network) then all > the > > HTTP connections originating in my internal network use only connection > #1, > > but I just can''t seem to get it to work properly with connections > > originating on the firewall. > > > > Let me know if you need more information. > > > > >From tcrules: > "$FW may be optionally followed by ":" and a host/network address." > > So try: > 1 $FW:<extip4provider/32> 0.0.0.0/0 tcp 80 > > JerryJust so I''m clear, I should replace <extip4provider/32> with the IP address of my Internet provider #1? This doesn''t seem to change anything, unfortunately. For now, I changed the rule back to the original, without the ":<extip4provider/32>". This is the rule that results and, as you can see, it''s marking packets. I think the problem is that the packets aren''t rerouted after they''re marked (just a guess). So how would I go about fixing that? Based on the diagram here: http://shorewall.net/Shorewall_and_Routing.html, it seems like after the output chain is traversed, the packet is re-routed. However, in my case, it doesn''t seem to be working the way I think it should? From "shorewall status": Chain OUTPUT (policy ACCEPT 206K packets, 117M bytes) pkts bytes target prot opt in out source destination 40368 19M routeout all -- * * 0.0.0.0/0 0.0.0.0/0 40368 19M tcout all -- * * 0.0.0.0/0 0.0.0.0/0 ... Chain tcout (1 references) pkts bytes target prot opt in out source destination 291 37071 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK set 0x1 Whenever I visit a web site from my firewall computer, those counts increase, regardless of which Internet provider is ultimately chosen by the system. Here are my Routing Rules (Wired & Wirels are my two providers): Routing Rules 0: from all lookup local 32746: from 192.168.1.111 lookup Wirels 32747: from all fwmark 0x2 lookup Wirels 32748: from 70.28.243.52 lookup Wired 32749: from all fwmark 0x1 lookup Wired 32766: from all lookup main 32767: from all lookup default Does fwmark mean that the packet has to have been marked in the FORWARD chain? If so, then how would I also include packets marked in the OUTPUT chain in these routing rules? Thanks again, Matt ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > >From tcrules: > > "$FW may be optionally followed by ":" and a host/network address." > > > > So try: > > 1 $FW:<extip4provider/32> 0.0.0.0/0 tcp80> > > > Jerry > > Just so I''m clear, I should replace <extip4provider/32> with the IPaddress> of my Internet provider #1? This doesn''t seem to change anything, > unfortunately.Yes, that what I meant.> For now, I changed the rule back to the original, without the > ":<extip4provider/32>". This is the rule that results and, as you cansee,> it''s marking packets. I think the problem is that the packets aren''t > rerouted after they''re marked (just a guess). So how would I go aboutfixing> that?I''ll take that as "routed as per the provider''s mark"> Based on the diagram here:http://shorewall.net/Shorewall_and_Routing.html,> it seems like after the output chain is traversed, the packet isre-routed.> However, in my case, it doesn''t seem to be working the way I think it > should?Let me guess, your using "main" in the dupiclate column of the providers file. That results in both providers being in each others tables. From my box: Table shaw: 10.10.0.2 dev tun0 proto kernel scope link src 10.10.0.1 10.50.0.0/24 dev eth1 proto kernel scope link src 10.50.0.1 24.78.220.0/24 dev eth2 proto kernel scope link src 24.78.220.109 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.106 10.5.0.0/24 via 10.10.0.2 dev tun0 169.254.0.0/16 dev eth2 scope link default via 24.78.220.1 dev eth2 Table test: 10.10.0.2 dev tun0 proto kernel scope link src 10.10.0.1 10.50.0.0/24 dev eth1 proto kernel scope link src 10.50.0.1 24.78.220.0/24 dev eth2 proto kernel scope link src 24.78.220.109 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.106 10.5.0.0/24 via 10.10.0.2 dev tun0 169.254.0.0/16 dev eth2 scope link default via 10.50.0.254 dev eth1> > From "shorewall status": > > Chain OUTPUT (policy ACCEPT 206K packets, 117M bytes) > pkts bytes target prot opt in out sourcedestination> > 40368 19M routeout all -- * * 0.0.0.0/00.0.0.0/0> > 40368 19M tcout all -- * * 0.0.0.0/00.0.0.0/0> > > ... > > Chain tcout (1 references) > pkts bytes target prot opt in out sourcedestination> > 291 37071 MARK tcp -- * * 0.0.0.0/00.0.0.0/0> tcp dpt:80 MARK set 0x1 > > Whenever I visit a web site from my firewall computer, those counts > increase, regardless of which Internet provider is ultimately chosen bythe> system. >That is good, the marking is correct, routing with the mark appears to be the issue.> Here are my Routing Rules (Wired & Wirels are my two providers): > > Routing Rules > > 0: from all lookup local > 32746: from 192.168.1.111 lookup Wirels > 32747: from all fwmark 0x2 lookup Wirels > 32748: from 70.28.243.52 lookup Wired > 32749: from all fwmark 0x1 lookup Wired > 32766: from all lookup main > 32767: from all lookup default > > > Does fwmark mean that the packet has to have been marked in the FORWARD > chain? If so, then how would I also include packets marked in the OUTPUT > chain in these routing rules? >The fwmark is working, but with both provider''s routes being present in each other''s tables, not sure of the full effect, I need to confirm my theory, want to help? I''ll need the output of "ip route ls table Wirels" and "ip route ls table Wired" Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
<html><div style=''background-color:''><DIV class=RTE> <P>>From: Jerry Vonau <jvonau@shaw.ca><BR>>Reply-To: shorewall-users@lists.sourceforge.net<BR>>To: shorewall-users@lists.sourceforge.net<BR>>Subject: Re: [Shorewall-users] Routing Packets Originating on the Firewall<BR>>Date: Mon, 18 Jul 2005 11:18:24 -0500<BR>>MIME-Version: 1.0<BR>>Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by mc9-f8.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 09:21:57 -0700<BR>>Received: from projects.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7])by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTPid ECE0A88291; Mon, 18 Jul 2005 09:21:56 -0700 (PDT)<BR>>Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=sc8-sf-mx2.sourceforge.net)by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30)id 1DuYLn-0006Jj-L5for shorewall-users@lists.sourceforge.net; Mon, 18 Jul 2005 09:20:15 -0700<BR>>Received: from idcmail-mo2no.cg.shawcable.net ([64.59.134.9] helo=pd7mo4no.prod.shaw.ca)by sc8-sf-mx2.sourceforge.net with esmtp (Exim 4.44)id 1DuYLl-0006TI-8Vfor shorewall-users@lists.sourceforge.net; Mon, 18 Jul 2005 09:20:15 -0700<BR>>Received: from pd6mr4no.prod.shaw.ca (pd6mr4no-qfe2.prod.shaw.ca [10.0.144.191]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IJT00IICZYNSQ70@l-daemon> for shorewall-users@lists.sourceforge.net; Mon, 18 Jul 2005 10:18:23 -0600 (MDT)<BR>>Received: from pn7ml3no.prod.shaw.ca ([10.0.149.112]) by pd6mr4no.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IJT00I87ZYNASL0@pd6mr4no.prod.shaw.ca> for shorewall-users@lists.sourceforge.net; Mon, 18 Jul 2005 10:18:23 -0600 (MDT)<BR>>Received: from mom (S010600104b708418.wp.shawcable.net [24.78.220.109]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with SMTP id <0IJT0055SZYMH0@l-daemon> for shorewall-users@lists.sourceforge.net; Mon, 18 Jul 2005 10:18:23 -0600 (MDT)<BR>>X-Message-Info: HQbIehuYceRdjtB1KvghLP6DLTIBkwmtiI2fCqBZ3yY=<BR>>X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700<BR>>X-Mailer: Microsoft Outlook Express 5.50.4807.1700<BR>>X-MSMail-priority: Normal<BR>>References: <E1DuVC9-0002rf-Pi@sc8-sf-mx2.sourceforge.net><BR>>X-Spam-Score: 0.4 (/)<BR>>X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=2000010.4 AWL AWL: From: address is in the auto white-list<BR>>Errors-To: shorewall-users-admin@lists.sourceforge.net<BR>>X-BeenThere: shorewall-users@lists.sourceforge.net<BR>>X-Mailman-Version: 2.0.9-sf.net<BR>>Precedence: bulk<BR>>List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/shorewall-users>,<mailto:shorewall-users-request@lists.sourceforge.net?subject=unsubscribe><BR>>List-Id: Shorewall Users <shorewall-users.lists.sourceforge.net><BR>>List-Post: <mailto:shorewall-users@lists.sourceforge.net><BR>>List-Help: <mailto:shorewall-users-request@lists.sourceforge.net?subject=help><BR>>List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/shorewall-users>,<mailto:shorewall-users-request@lists.sourceforge.net?subject=subscribe><BR>>List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=shorewall-users><BR>>X-Original-Date: Mon, 18 Jul 2005 11:18:24 -0500<BR>>Return-Path: shorewall-users-admin@lists.sourceforge.net<BR>>X-OriginalArrivalTime: 18 Jul 2005 16:21:57.0732 (UTC) FILETIME=[D1A17240:01C58BB4]<BR>><BR>><BR>> > > >From tcrules:<BR>> > > "$FW may be optionally followed by ":" and a host/network address."<BR>> > ><BR>> > > So try:<BR>> > > 1 $FW:<extip4provider/32> 0.0.0.0/0 tcp<BR>>80<BR>> > ><BR>> > > Jerry<BR>> ><BR>> > Just so I''m clear, I should replace <extip4provider/32> with the IP<BR>>address<BR>> > of my Internet provider #1? This doesn''t seem to change anything,<BR>> > unfortunately.<BR>><BR>>Yes, that what I meant.<BR>><BR>> > For now, I changed the rule back to the original, without the<BR>> > ":<extip4provider/32>". This is the rule that results and, as you can<BR>>see,<BR>> > it''s marking packets. I think the problem is that the packets aren''t<BR>> > rerouted after they''re marked (just a guess). So how would I go about<BR>>fixing<BR>> > that?<BR>><BR>>I''ll take that as "routed as per the provider''s mark"<BR>><BR>> > Based on the diagram here:<BR>>http://shorewall.net/Shorewall_and_Routing.html,<BR>> > it seems like after the output chain is traversed, the packet is<BR>>re-routed.<BR>> > However, in my case, it doesn''t seem to be working the way I think it<BR>> > should?<BR>><BR>>Let me guess, your using "main" in the dupiclate column of the providers<BR>>file.<BR>>That results in both providers being in each others tables. From my box:<BR>><BR>>Table shaw:<BR>><BR>>10.10.0.2 dev tun0 proto kernel scope link src 10.10.0.1<BR>>10.50.0.0/24 dev eth1 proto kernel scope link src 10.50.0.1<BR>>24.78.220.0/24 dev eth2 proto kernel scope link src 24.78.220.109<BR>>10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.106<BR>>10.5.0.0/24 via 10.10.0.2 dev tun0<BR>>169.254.0.0/16 dev eth2 scope link<BR>>default via 24.78.220.1 dev eth2<BR>><BR>>Table test:<BR>><BR>>10.10.0.2 dev tun0 proto kernel scope link src 10.10.0.1<BR>>10.50.0.0/24 dev eth1 proto kernel scope link src 10.50.0.1<BR>>24.78.220.0/24 dev eth2 proto kernel scope link src 24.78.220.109<BR>>10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.106<BR>>10.5.0.0/24 via 10.10.0.2 dev tun0<BR>>169.254.0.0/16 dev eth2 scope link<BR>>default via 10.50.0.254 dev eth1<BR>><BR>><BR>> ><BR>> > From "shorewall status":<BR>> ><BR>> > Chain OUTPUT (policy ACCEPT 206K packets, 117M bytes)<BR>> > pkts bytes target prot opt in out source<BR>>destination<BR>> ><BR>> > 40368 19M routeout all -- * * 0.0.0.0/0<BR>>0.0.0.0/0<BR>> ><BR>> > 40368 19M tcout all -- * * 0.0.0.0/0<BR>>0.0.0.0/0<BR>> ><BR>> ><BR>> > ...<BR>> ><BR>> > Chain tcout (1 references)<BR>> > pkts bytes target prot opt in out source<BR>>destination<BR>> ><BR>> > 291 37071 MARK tcp -- * * 0.0.0.0/0<BR>>0.0.0.0/0<BR>> > tcp dpt:80 MARK set 0x1<BR>> ><BR>> > Whenever I visit a web site from my firewall computer, those counts<BR>> > increase, regardless of which Internet provider is ultimately chosen by<BR>>the<BR>> > system.<BR>> ><BR>><BR>>That is good, the marking is correct, routing with the mark appears to be<BR>>the issue.<BR>><BR>> > Here are my Routing Rules (Wired & Wirels are my two providers):<BR>> ><BR>> > Routing Rules<BR>> ><BR>> > 0: from all lookup local<BR>> > 32746: from 192.168.1.111 lookup Wirels<BR>> > 32747: from all fwmark 0x2 lookup Wirels<BR>> > 32748: from 70.28.243.52 lookup Wired<BR>> > 32749: from all fwmark 0x1 lookup Wired<BR>> > 32766: from all lookup main<BR>> > 32767: from all lookup default<BR>> ><BR>> ><BR>> > Does fwmark mean that the packet has to have been marked in the FORWARD<BR>> > chain? If so, then how would I also include packets marked in the OUTPUT<BR>> > chain in these routing rules?<BR>> ><BR>><BR>>The fwmark is working, but with both provider''s routes being present in<BR>>each other''s<BR>>tables, not sure of the full effect, I need to confirm my theory, want to<BR>>help?<BR>>I''ll need the output of "ip route ls table Wirels" and "ip route ls table<BR>>Wired"<BR>><BR>>Jerry</P> <P>[Sorry if this gets sent twice.. I accidentally sent it first using a different e-mail address that isn''t registered on the list]</P> <P>Here''s my providers file (in case you''re curious):<BR><BR>Wired 1 1 main eth2 detect <BR>track,balance<BR>Wirels 2 2 main ath0 192.168.1.1 <BR>track,balance<BR><BR>eth2 is my "Wired" and ath0 is my "Wirels"<BR><BR>Here are the routing tables (Main, Wired, Wirels)<BR><BR>Table main:<BR><BR>70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>169.254.0.0/16 dev eth2 scope link<BR>239.0.0.0/8 dev br0 scope link<BR>default<BR> nexthop via 70.28.243.1 dev eth2 weight 1<BR> nexthop via 192.168.1.1 dev ath0 weight 1<BR><BR>Table Wired:<BR><BR>70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>169.254.0.0/16 dev eth2 scope link<BR>239.0.0.0/8 dev br0 scope link<BR>default via 70.28.243.1 dev eth2<BR><BR>Table Wirels:<BR><BR>70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>169.254.0.0/16 dev eth2 scope link<BR>239.0.0.0/8 dev br0 scope link<BR>default via 192.168.1.1 dev ath0</P></DIV></div></html> ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Here''s my providers file (in case you''re curious): > > Wired 1 1 main eth2 detect > track,balance > Wirels 2 2 main ath0 192.168.1.1 > track,balance > > eth2 is my "Wired" and ath0 is my "Wirels" > > Here are the routing tables (Main, Wired, Wirels) > > Table main: > > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default > nexthop via 70.28.243.1 dev eth2 weight 1 > nexthop via 192.168.1.1 dev ath0 weight 1 > > Table Wired: > > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default via 70.28.243.1 dev eth2 > > Table Wirels: > > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default via 192.168.1.1 dev ath0With no other changes, issue these commands and retest: /sbin/ip route del 70.28.243.0/25 dev eth2 table Wirels /sbin/ip route del 192.168.1.0/24 dev ath0 table Wired /sbin/ip route flush cache Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
<html><div style=''background-color:''><DIV class=RTE> <P>> > Here''s my providers file (in case you''re curious):<BR>> ><BR>> > Wired 1 1 main eth2 detect<BR>> > track,balance<BR>> > Wirels 2 2 main ath0 192.168.1.1<BR>> > track,balance<BR>> ><BR>> > eth2 is my "Wired" and ath0 is my "Wirels"<BR>> ><BR>> > Here are the routing tables (Main, Wired, Wirels)<BR>> ><BR>> > Table main:<BR>> ><BR>> > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>> > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>> > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>> > 169.254.0.0/16 dev eth2 scope link<BR>> > 239.0.0.0/8 dev br0 scope link<BR>> > default<BR>> > nexthop via 70.28.243.1 dev eth2 weight 1<BR>> > nexthop via 192.168.1.1 dev ath0 weight 1<BR>> ><BR>> > Table Wired:<BR>> ><BR>> > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>> > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>> > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>> > 169.254.0.0/16 dev eth2 scope link<BR>> > 239.0.0.0/8 dev br0 scope link<BR>> > default via 70.28.243.1 dev eth2<BR>> ><BR>> > Table Wirels:<BR>> ><BR>> > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>> > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>> > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>> > 169.254.0.0/16 dev eth2 scope link<BR>> > 239.0.0.0/8 dev br0 scope link<BR>> > default via 192.168.1.1 dev ath0<BR>><BR>>With no other changes, issue these commands and retest:<BR>>/sbin/ip route del 70.28.243.0/25 dev eth2 table Wirels<BR>>/sbin/ip route del 192.168.1.0/24 dev ath0 table Wired<BR>>/sbin/ip route flush cache<BR>><BR>>Jerry<BR></P> <P>Hi again Jerry,</P> <P>Thanks again for your help. I ran those three commands, and still no luck :( My outgoing HTTP connetions from the firewall are still distributed over both connections. [Here are the new routing tables]</P> <P>Table Wired:</P> <P>70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52<BR>10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>169.254.0.0/16 dev eth2 scope link<BR>239.0.0.0/8 dev br0 scope link<BR>default via 70.28.243.1 dev eth2</P> <P>Table Wirels:</P> <P>192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111<BR>10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1<BR>169.254.0.0/16 dev eth2 scope link<BR>239.0.0.0/8 dev br0 scope link<BR>default via 192.168.1.1 dev ath0<BR></P> <P>My hunch is that it''s still some issue with the marked packets not being routed properly the second time, after they''ve been through the OUTPUT chain. However, according to the shorewall documentation here: <A href="http://www.shorewall.net/Shorewall_and_Routing.html">http://www.shorewall.net/Shorewall_and_Routing.html</A> , the packets should be re-routed after being marked in the OUTPUT chain :(</P> <P>Could someone confirm to me that packets generated from the firewall can definitely be routed using fwmarks?</P> <P>I''m at a loss now as to what to try...<BR></P></DIV></div></html> ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N. wrote on 18/07/2005 15:31:49:> My hunch is that it''s still some issue with the marked packets not > being routed properly the second time, after they''ve been through the > OUTPUT chain. However, according to the shorewall documentation here: > http://www.shorewall.net/Shorewall_and_Routing.html , the packets > should be re-routed after being marked in the OUTPUT chain :( > Could someone confirm to me that packets generated from the firewall > can definitely be routed using fwmarks?I had tested a very similar configuration for the 2.4.0 rollout here (I don''t have the box anymore) and I remember I used a fwmark to route https packets through only one of the interfaces, so that internet banking could be used without IP changing during a session (I was using squid in the box, so the packets were being routed from the firewall). I remember I had to apply the netfilter ROUTE patch to work - so I think I was using the /etc/shorewall/routes file.> I''m at a loss now as to what to try...hope this helps, -- Eduardo Ferreira
> Hi again Jerry, > > Thanks again for your help. I ran those three commands, and still no luck:( My outgoing HTTP connetions from the firewall are still distributed over both connections. [Here are the new routing tables]> > Table Wired: > > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default via 70.28.243.1 dev eth2 > > Table Wirels: > > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default via 192.168.1.1 dev ath0 > > > My hunch is that it''s still some issue with the marked packets not beingrouted properly the second time, after they''ve been through the OUTPUT chain. However, according to the shorewall documentation here: http://www.shorewall.net/Shorewall_and_Routing.html , the packets should be re-routed after being marked in the OUTPUT chain :(> > Could someone confirm to me that packets generated from the firewall candefinitely be routed using fwmarks? How are you marking them in the tcrules file? Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Please stop posting in HTML -- complete waste of bandwidth. Matt N wrote:> Could someone confirm to me that packets generated from the firewall can > definitely be routed using fwmarks? >IIRC, Alex Wilms and I tested that before we released 2.4.0; can you confirm, Alex? -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
> > My hunch is that it''s still some issue with the marked packets not being >routed properly the second time, after they''ve been through the OUTPUT >chain. However, according to the shorewall documentation here: >http://www.shorewall.net/Shorewall_and_Routing.html , the packets should be >re-routed after being marked in the OUTPUT chain :( > > > > Could someone confirm to me that packets generated from the firewall can >definitely be routed using fwmarks? > >How are you marking them in the tcrules file?I simply put the line: 1 $FW 0.0.0.0/0 tcp 80 in tcrules and like I posted earlier, the marking is definitely happening, because the packet/byte counts increase every for that rule every time I make an outgoing HTTP connection from my firewall. However, the routing doesn''t seem to be affected by the mark... [And sorry for the HTML, I''m at work and using hotmail, which is not my usual configuration. I think I managed to turn it off now? But let me know if not...] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N wrote:>> > My hunch is that it''s still some issue with the marked packets not >> being >> routed properly the second time, after they''ve been through the OUTPUT >> chain. However, according to the shorewall documentation here: >> http://www.shorewall.net/Shorewall_and_Routing.html , the packets >> should be >> re-routed after being marked in the OUTPUT chain :( >> > >> > Could someone confirm to me that packets generated from the firewall >> can >> definitely be routed using fwmarks? >> >> How are you marking them in the tcrules file? > > I simply put the line: > > 1 $FW 0.0.0.0/0 tcp 80 > > in tcrules > > and like I posted earlier, the marking is definitely happening, because > the packet/byte counts increase every for that rule every time I make an > outgoing HTTP connection from my firewall. However, the routing doesn''t > seem to be affected by the mark...I just reproduced the problem. Shorewall generates routing rules that ensure that packets with a source IP equal to an IP address on an interface to a provider will be sent via that provider. -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
Tom Eastep wrote:> ... >>and like I posted earlier, the marking is definitely happening, because >>the packet/byte counts increase every for that rule every time I make an >>outgoing HTTP connection from my firewall. However, the routing doesn''t >>seem to be affected by the mark... > > I just reproduced the problem. Shorewall generates routing rules that > ensure that packets with a source IP equal to an IP address on an > interface to a provider will be sent via that provider.How is that a problem? Sounds like the "right thing (tm)" to me. :-) -- Paul Gear, Manager IT Operations, Redlands College 38 Anson Road, Wellington Point 4160, Australia (Please send attachments in portable formats such as PDF, HTML, or OpenOffice.) -- The information contained in this message is copyright by Redlands College. Any use for direct sales or marketing purposes is expressly forbidden. This message does not represent the views of Redlands College.
Paul Gear wrote:> Tom Eastep wrote: >>... >>>and like I posted earlier, the marking is definitely happening, because >>>the packet/byte counts increase every for that rule every time I make an >>>outgoing HTTP connection from my firewall. However, the routing doesn''t >>>seem to be affected by the mark... >>I just reproduced the problem. Shorewall generates routing rules that >>ensure that packets with a source IP equal to an IP address on an >>interface to a provider will be sent via that provider. > > How is that a problem? Sounds like the "right thing (tm)" to me. :-) >It means that you can''t override the rule with fwmarks. One way to work around this is to configure your client apps to bind to a particular local IP address. I''ve implemented a ''loose'' provider option to avoid adding those rules. -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
Tom Eastep wrote:> Paul Gear wrote: >>Tom Eastep wrote: >>>... >>>>and like I posted earlier, the marking is definitely happening, because >>>>the packet/byte counts increase every for that rule every time I make an >>>>outgoing HTTP connection from my firewall. However, the routing doesn''t >>>>seem to be affected by the mark... >>>I just reproduced the problem. Shorewall generates routing rules that >>>ensure that packets with a source IP equal to an IP address on an >>>interface to a provider will be sent via that provider. >>How is that a problem? Sounds like the "right thing (tm)" to me. :-) >> > > It means that you can''t override the rule with fwmarks. One way to work > around this is to configure your client apps to bind to a particular > local IP address. > > I''ve implemented a ''loose'' provider option to avoid adding those rules.The ''firewall'' script and ''providers'' file in CVS (development branch) contain support for ''loose''. Please try that code Matt and let us know if: a) It fixes your problem (it should -- I''ve tested it here); and b) ''loose'' causes any bad side effects. Thanks, -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
>Tom Eastep wrote: > > Paul Gear wrote: > >>Tom Eastep wrote: > >>>... > >>>>and like I posted earlier, the marking is definitely happening, >because > >>>>the packet/byte counts increase every for that rule every time I make >an > >>>>outgoing HTTP connection from my firewall. However, the routing >doesn''t > >>>>seem to be affected by the mark... > >>>I just reproduced the problem. Shorewall generates routing rules that > >>>ensure that packets with a source IP equal to an IP address on an > >>>interface to a provider will be sent via that provider. > >>How is that a problem? Sounds like the "right thing (tm)" to me. :-) > >> > > > > It means that you can''t override the rule with fwmarks. One way to work > > around this is to configure your client apps to bind to a particular > > local IP address. > > > > I''ve implemented a ''loose'' provider option to avoid adding those rules. > >The ''firewall'' script and ''providers'' file in CVS (development branch) >contain support for ''loose''. Please try that code Matt and let us know >if: > >a) It fixes your problem (it should -- I''ve tested it here); and >b) ''loose'' causes any bad side effects.Thanks for your help and time, Tom. I''ll get the new scripts this evening when I get home and post how things are working. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N wrote:>> Tom Eastep wrote: >> > Paul Gear wrote: >> >>Tom Eastep wrote: >> >>>... >> >>>>and like I posted earlier, the marking is definitely happening, >> because >> >>>>the packet/byte counts increase every for that rule every time I >> make an >> >>>>outgoing HTTP connection from my firewall. However, the routing >> doesn''t >> >>>>seem to be affected by the mark... >> >>>I just reproduced the problem. Shorewall generates routing rules that >> >>>ensure that packets with a source IP equal to an IP address on an >> >>>interface to a provider will be sent via that provider. >> >>How is that a problem? Sounds like the "right thing (tm)" to me. :-) >> >> >> > >> > It means that you can''t override the rule with fwmarks. One way to work >> > around this is to configure your client apps to bind to a particular >> > local IP address. >> > >> > I''ve implemented a ''loose'' provider option to avoid adding those rules. >> >> The ''firewall'' script and ''providers'' file in CVS (development branch) >> contain support for ''loose''. Please try that code Matt and let us know >> if: >> >> a) It fixes your problem (it should -- I''ve tested it here); and >> b) ''loose'' causes any bad side effects. > > Thanks for your help and time, Tom. I''ll get the new scripts this > evening when I get home and post how things are working. >You will probably also have to change your /etc/shorewall/masq file to include two additional entries: #INTERFACE SUBNET ADDRESS $IF_ISP1 $IP_ISP2 $IP_ISP1 $IF_ISP2 $IP_ISP1 $IP_ISP2 Where $IF_ISP1 is the interface to ISP 1 with IP address $IP_ISP1 and $IF_ISP2 is the interface to ISP 2 with IP address $IP_ISP2 These will insure that traffic to each ISP from the firewall will have the proper source IP address. -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
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Tom Eastep > Sent: Tuesday, July 19, 2005 12:31 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > Matt N wrote: > >> Tom Eastep wrote: > >> > Paul Gear wrote: > >> >>Tom Eastep wrote: > >> >>>... > >> >>>>and like I posted earlier, the marking is definitely happening, > >> because > >> >>>>the packet/byte counts increase every for that rule every time I > >> make an > >> >>>>outgoing HTTP connection from my firewall. However, the routing > >> doesn''t > >> >>>>seem to be affected by the mark... > >> >>>I just reproduced the problem. Shorewall generates routing rules > that > >> >>>ensure that packets with a source IP equal to an IP address on an > >> >>>interface to a provider will be sent via that provider. > >> >>How is that a problem? Sounds like the "right thing (tm)" to me. :- > ) > >> >> > >> > > >> > It means that you can''t override the rule with fwmarks. One way to > work > >> > around this is to configure your client apps to bind to a particular > >> > local IP address. > >> > > >> > I''ve implemented a ''loose'' provider option to avoid adding those > rules. > >> > >> The ''firewall'' script and ''providers'' file in CVS (development branch) > >> contain support for ''loose''. Please try that code Matt and let us know > >> if: > >> > >> a) It fixes your problem (it should -- I''ve tested it here); and > >> b) ''loose'' causes any bad side effects. > > > > Thanks for your help and time, Tom. I''ll get the new scripts this > > evening when I get home and post how things are working. > > > > You will probably also have to change your /etc/shorewall/masq file to > include > two additional entries: > > #INTERFACE SUBNET ADDRESS > $IF_ISP1 $IP_ISP2 $IP_ISP1 > $IF_ISP2 $IP_ISP1 $IP_ISP2 > > Where $IF_ISP1 is the interface to ISP 1 with IP address $IP_ISP1 and > $IF_ISP2 is the interface to ISP 2 with IP address $IP_ISP2 > > These will insure that traffic to each ISP from the firewall will have the > proper source IP address.Well... Good and bad news. The good news is that the outgoing connections from the firewall are now properly restricted to specific connections according to the rules I place in tcrules :) The bad news is that *incoming* connections on my "second" connection (i.e. not the one that is originally the default) don''t seem to make it in. I tried connecting to my webserver using my "second" IP from an outside connection and it just sits there forever. If I change back to my original settings, everything works. So, just to confirm... here are my two settings: Masq: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth2 10.1.0.0/24 eth2 192.168.1.111 70.28.243.52 ath0 70.28.243.52 192.168.1.111 (I don''t need to "masq" my ath0 connection as it goes to a router that does it for me... and that router is forwarding port 80 to my 192.168.1.111 IP) And just to confirm... the second eth2 and ath0 are what you intended? My primary connection IP is 70.28.243.52 and secondary is 192.168.1.111. Originally, the masq file just contained that first eth2 line. Providers: Wired 1 1 main eth2 detect track,balance,loose Wirels 2 2 main ath0 192.168.1.1 track,balance,loose Originally, I didn''t have the two "loose"s there. So, just to restate.. For the "original" setup, I can connect to my webserver using either of my connections from an external source. With the new set up, I can only connect using the "eth2" connection. For the original setup, the fwmarks had no effect on the connections originating from the firewall, but with the new setup, they do. Thanks again for your help. I do prefer the "new" setup, as being able to connect to my webserver from both IPs isn''t a *huge* issue; however, if I could get that working again as well, it would be perfect. -Matt ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N wrote:> > Originally, I didn''t have the two "loose"s there. > > > So, just to restate.. > > For the "original" setup, I can connect to my webserver using either of my > connections from an external source. With the new set up, I can only connect > using the "eth2" connection. For the original setup, the fwmarks had no > effect on the connections originating from the firewall, but with the new > setup, they do. > > Thanks again for your help. I do prefer the "new" setup, as being able to > connect to my webserver from both IPs isn''t a *huge* issue; however, if I > could get that working again as well, it would be perfect.Someone who has a setup like this and who is willing to play with the routing setup is going to have to tell me what to do. I designed the Shorewall facility based on my readings of the various howtos and without being able to test it locally, I''ve taken it as far as I can. -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
>Someone who has a setup like this and who is willing to play with the >routing setup is going to have to tell me what to do. I designed the >Shorewall facility based on my readings of the various howtos and >without being able to test it locally, I''ve taken it as far as I can.Matt: Can you post a shorewall status and the config files. Need to clear up where br0 and 239.0.0.0/8 fits into all this. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > Sent: Tuesday, July 19, 2005 21:48 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > >Someone who has a setup like this and who is willing to play with the > >routing setup is going to have to tell me what to do. I designed the > >Shorewall facility based on my readings of the various howtos and > >without being able to test it locally, I''ve taken it as far as I can. > > Matt: > > Can you post a shorewall status and the config files. > Need to clear up where br0 and 239.0.0.0/8 fits into all this.I''ve attached a .tar.gz of my shorewall directory, and I put a file called "stat" in there that''s the output of "shorewall status". Hope that''s OK? Just to explain my network to help you out... eth0 & eth1 are for my internal network (eth0 is a gigabit connection to an internal computer and eth1 is a connection to a wireless access point) and they''re joined together with br0. eth2 is my main internet connection. ath0 is so I can use my neighbour''s Internet connection (through his wireless router, with his permission of course). eth2 need to be masq''ed, but ath0 doesn''t, since his wireless router takes care of that. I set up the providers file so that I can load balance over these two outgoing links, but I want some traffic generated at the firewall to go out only over a specific link. 239.0.0.0/8 is in my routing table so that linux-igd (for uPnP) will work correctly (done in rc.local). I also manually add a chain (in shorewall/start) for uPnP rules, because in the past shorewall wasn''t able to do this automatically, and I''ve been too lazy to check on how to do this with the newer versions :) So, like I said, my problem now is that incoming connections to eth2 will come in, but incoming connections to ath0 won''t. When I remove "loose" and the extra entries in masq, both interfaces will work with incoming connections, but then I lose the capability to use marks to route packets that are generated at the firewall (but it was always possible to do this with packets generated by computers on my internal network... just not the firewall itself). If you need more info, please let me know. And thanks for looking into this! -Matt
Matt N wrote:> > eth2 is my main internet connection. ath0 is so I can use my neighbour''s > Internet connection (through his wireless router, with his permission of > course). eth2 need to be masq''ed, but ath0 doesn''t, since his wireless > router takes care of that.So his wireless router is perfectly happy getting packets with source IP = 70.28.243.52 from your firewall? I seriously doubt 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
Tom Eastep wrote:> Matt N wrote: > >>eth2 is my main internet connection. ath0 is so I can use my neighbour''s >>Internet connection (through his wireless router, with his permission of >>course). eth2 need to be masq''ed, but ath0 doesn''t, since his wireless >>router takes care of that. > > So his wireless router is perfectly happy getting packets with source IP > = 70.28.243.52 from your firewall? I seriously doubt it. >Never mind -- I misunderstood what you were saying. -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
> So, like I said, my problem now is that incoming connections to eth2 will > come in, but incoming connections to ath0 won''t.Can you clear this up, does the traffic come from the access point, or your friend''s local lan? See if you can telnet to the mail port from a remote machine that would use ath0. What services don''t work? web, mail, ssh, and/or all of them. I''ll bet that mail works but web doesn''t.>When I remove "loose" and > the extra entries in masq, both interfaces will work with incoming > connections, but then I lose the capability to use marks to route packets > that are generated at the firewall (but it was always possible to do this > with packets generated by computers on my internal network... just notthe> firewall itself). > > If you need more info, please let me know. And thanks for looking intothis!> > -MattThere are no reject/drop messages right? Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > So, like I said, my problem now is that incoming connections to eth2will> > come in, but incoming connections to ath0 won''t. > > Can you clear this up, does the traffic come from the access point, oryour> friend''s local lan? See if you can telnet to the mail port from a remote > machine > that would use ath0. What services don''t work? web, mail, ssh, and/or all > of > them. I''ll bet that mail works but web doesn''t. > > >When I remove "loose" and > > the extra entries in masq, both interfaces will work with incoming > > connections, but then I lose the capability to use marks to routepackets> > that are generated at the firewall (but it was always possible to dothis> > with packets generated by computers on my internal network... just not > the > > firewall itself). > > > > If you need more info, please let me know. And thanks for looking into > this! > > > > -Matt > > There are no reject/drop messages right? > > JerryIn tcrule you might want to try: 1:P 10.1.0.0/24 0.0.0.0/0 all Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > Sent: Wednesday, July 20, 2005 0:36 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > > > > So, like I said, my problem now is that incoming connections to eth2 > will > > come in, but incoming connections to ath0 won''t. > > Can you clear this up, does the traffic come from the access point, or > your > friend''s local lan? See if you can telnet to the mail port from a remote > machine > that would use ath0. What services don''t work? web, mail, ssh, and/or all > of > them. I''ll bet that mail works but web doesn''t.The traffic comes in through my neighbour''s internet connection and into his router. That port (80, and also port 22 for SSH) is forwarded to 192.168.1.111 (my ath0 interface). When I don''t have "loose" or the extra masq entries, I can connect to my web server and my ssh daemon using my neighbour''s external IP address (I connect to it from a machine at my university). Once I add those entries in, then I cannot. The "access point" that I mentioned is simply for my internal network and is a completely different device than my neighbour''s router. So there are two wireless networks in play. One is my internal one (through eth1), and one is for accessing my neighbour''s Internet connection (through ath0).> > >When I remove "loose" and > > the extra entries in masq, both interfaces will work with incoming > > connections, but then I lose the capability to use marks to route > packets > > that are generated at the firewall (but it was always possible to do > this > > with packets generated by computers on my internal network... just not > the > > firewall itself). > > > > If you need more info, please let me know. And thanks for looking into > this! > > > > -Matt > > There are no reject/drop messages right?No, no rejects or drops... Out of curiosity, I ran tcpdump -i ath0 and then tried to do an ssh connect to my firewall from my university using the ath0 interface: [-----------------]# tcpdump -i ath0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes 01:12:03.319631 IP mathgradpc23.math.uwaterloo.ca.32783 > 192.168.1.111.ssh: S 3008650876:3008650876(0) win 5840 <mss 1460,sackOK,timestamp 293647564 0,nop,wscale 2> 01:12:06.318562 IP mathgradpc23.math.uwaterloo.ca.32783 > 192.168.1.111.ssh: S 3008650876:3008650876(0) win 5840 <mss 1460,sackOK,timestamp 293650564 0,nop,wscale 2> So, clearly stuff is reaching my firewall machine over my neighbour''s internet connection; HOWEVER, nothing is making it back to the machine at the university. I''m guessing my firewall is sending the return message out over eth2 instead of ath0... OR it''s sending it over ath0 but using the IP of eth2? ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > Sent: Wednesday, July 20, 2005 0:49 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > > > So, like I said, my problem now is that incoming connections to eth2 > will > > > come in, but incoming connections to ath0 won''t. > > > > Can you clear this up, does the traffic come from the access point, or > your > > friend''s local lan? See if you can telnet to the mail port from a remote > > machine > > that would use ath0. What services don''t work? web, mail, ssh, and/or > all > > of > > them. I''ll bet that mail works but web doesn''t. > > > > >When I remove "loose" and > > > the extra entries in masq, both interfaces will work with incoming > > > connections, but then I lose the capability to use marks to route > packets > > > that are generated at the firewall (but it was always possible to do > this > > > with packets generated by computers on my internal network... just not > > the > > > firewall itself). > > > > > > If you need more info, please let me know. And thanks for looking into > > this! > > > > > > -Matt > > > > There are no reject/drop messages right? > > > > Jerry > > In tcrule you might want to try: > > 1:P 10.1.0.0/24 0.0.0.0/0 all >This is my current tcrules file: 55 $FW 0.0.0.0/0 tcp 80 1:P 0.0.0.0/0 0.0.0.0/0 all 1 $FW 0.0.0.0/0 all - - - !55 - Mark all outgoing HTTP traffic from the firewall as 55. - Everything that comes from a machine other than the firewall, route through Internet connection #1 using a PRE-ROUTING rule - Everything originating from the firewall, other than HTTP traffic should be routed through Internet Connection #1. Now, that third line may be responsible for my problem; however, without it, I can''t accomplish my goal of having all traffic, except outgoing http traffic routed through Internet Connection #1. Ideally, *incoming* traffic should just be routed back out the same way in came in and shouldn''t be affected by anything in this file. What I will try now, is excluding connections with a source port of 22, and see if that allows incoming SSH connections over ath0 to work properly. However, I''m not sure the best way to combine this with my "55" mark above. How would I say something like "NOT 55 and NOT 56" in my third line? Where 56 would be "all traffic from the firewall with source port 22". In any case, I''ll temporarily remove the "55" mark to attempt what I mentioned above... ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Well, I changed my tcrules to: 56 $FW 0.0.0.0/0 tcp - 22 1:P 0.0.0.0/0 0.0.0.0/0 all 1 $FW 0.0.0.0/0 all - - - !56 Now... it sporadically works on both eth2 & ath0; whereas before it worked reliably on eth2, but not on ath0. So, now, it seems like it''s randomly picking a connection to send the reply packet on... sometimes it picks the right one (i.e. the same connection as the incoming packet arrived on), and ssh connects... sometimes it picks the wrong one (i.e. the opposite connection of the one the packet originally came in on). So, the crux of the problem: It seems like the interface of the incoming connection is not being tracked when "loose" is used... Or if it is being tracked, then the routing isn''t taking advantage of the tracking and the return packet is just being routed according to the tcrules file and the routing table. Thanks again for your help... I know it''s a messy situation :) Hopefully someone has a similar set up (perhaps slightly less complex). -Matt> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Matt N > Sent: Wednesday, July 20, 2005 1:28 > To: shorewall-users@lists.sourceforge.net > Subject: RE: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > > > > -----Original Message----- > > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall- > users- > > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > > Sent: Wednesday, July 20, 2005 0:49 > > To: shorewall-users@lists.sourceforge.net > > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > > Firewall > > > > > > So, like I said, my problem now is that incoming connections to eth2 > > will > > > > come in, but incoming connections to ath0 won''t. > > > > > > Can you clear this up, does the traffic come from the access point, or > > your > > > friend''s local lan? See if you can telnet to the mail port from a > remote > > > machine > > > that would use ath0. What services don''t work? web, mail, ssh, and/or > > all > > > of > > > them. I''ll bet that mail works but web doesn''t. > > > > > > >When I remove "loose" and > > > > the extra entries in masq, both interfaces will work with incoming > > > > connections, but then I lose the capability to use marks to route > > packets > > > > that are generated at the firewall (but it was always possible to do > > this > > > > with packets generated by computers on my internal network... just > not > > > the > > > > firewall itself). > > > > > > > > If you need more info, please let me know. And thanks for looking > into > > > this! > > > > > > > > -Matt > > > > > > There are no reject/drop messages right? > > > > > > Jerry > > > > In tcrule you might want to try: > > > > 1:P 10.1.0.0/24 0.0.0.0/0 all > > > > This is my current tcrules file: > > 55 $FW 0.0.0.0/0 tcp 80 > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - > !55 > > - Mark all outgoing HTTP traffic from the firewall as 55. > - Everything that comes from a machine other than the firewall, route > through Internet connection #1 using a PRE-ROUTING rule > - Everything originating from the firewall, other than HTTP traffic should > be routed through Internet Connection #1. > > Now, that third line may be responsible for my problem; however, without > it, > I can''t accomplish my goal of having all traffic, except outgoing http > traffic routed through Internet Connection #1. Ideally, *incoming* traffic > should just be routed back out the same way in came in and shouldn''t be > affected by anything in this file. > > What I will try now, is excluding connections with a source port of 22, > and > see if that allows incoming SSH connections over ath0 to work properly. > However, I''m not sure the best way to combine this with my "55" mark > above. > How would I say something like "NOT 55 and NOT 56" in my third line? Where > 56 would be "all traffic from the firewall with source port 22". > > In any case, I''ll temporarily remove the "55" mark to attempt what I > mentioned above... > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Well, I changed my tcrules to: > > 56 $FW 0.0.0.0/0 tcp - 22 > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - > !56 > > Now... it sporadically works on both eth2 & ath0; whereas before itworked> reliably on eth2, but not on ath0. So, now, it seems like it''s randomly > picking a connection to send the reply packet on... sometimes it picksthe> right one (i.e. the same connection as the incoming packet arrived on),and> ssh connects... sometimes it picks the wrong one (i.e. the opposite > connection of the one the packet originally came in on). > > So, the crux of the problem: > > It seems like the interface of the incoming connection is not beingtracked> when "loose" is used... Or if it is being tracked, then the routing isn''t > taking advantage of the tracking and the return packet is just beingrouted> according to the tcrules file and the routing table. > > Thanks again for your help... I know it''s a messy situation :) Hopefully > someone has a similar set up (perhaps slightly less complex). >Ok that is progress, sounds like you may want to use the copy feature in the providers file. What that will do is change the routing tables to be stricter. From: 192.168.1.1 dev ath0 scope link 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 169.254.0.0/16 dev eth2 scope link 239.0.0.0/8 dev br0 scope link default via 192.168.1.1 dev ath0 To: 192.168.1.1 dev ath0 scope link 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 239.0.0.0/8 dev br0 scope link default via 192.168.1.1 dev ath0 Try this: Wired 1 1 main eth2 detect track,balance,loose br0 Wirels 2 2 main ath0 192.168.1.1 track,balance,loose br0 Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > Well, I changed my tcrules to: > > > > 56 $FW 0.0.0.0/0 tcp - 22 > > 1:P 0.0.0.0/0 0.0.0.0/0 all > > 1 $FW 0.0.0.0/0all - - -> > !56 > >is that a typo? 56 $FW 0.0.0.0/0 tcp - 22 and is really 56 $FW 0.0.0.0/0 tcp 22 Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > Well, I changed my tcrules to: > > > > > > 56 $FW 0.0.0.0/0 tcp - 22 > > > 1:P 0.0.0.0/0 0.0.0.0/0 all > > > 1 $FW 0.0.0.0/0 > all - - - > > > !56 > > > > is that a typo? > 56 $FW 0.0.0.0/0 tcp - 22 > and is really > 56 $FW 0.0.0.0/0 tcp 22 >I really need to get all my ideas together before hitting send...... The order in tcrules is important, the LAST match gets to do the marking, so your "56" mark would need to be at the bottom of the list. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
I''m replying to this after my other replies, as I saw some progress.> > > > In tcrule you might want to try: > > > > 1:P 10.1.0.0/24 0.0.0.0/0 all > > > > This is my current tcrules file: > > 55 $FW 0.0.0.0/0 tcp 80 > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - > !55 > > - Mark all outgoing HTTP traffic from the firewall as 55? > > - Everything that comes from a machine other than the firewall, route > through Internet connection #1 using a PRE-ROUTING ruleAll traffic must pass though the prerouting chain, where the mangle table is used. You have the "track" option, so the fwmarks get applied based on the receiving interface, the rest (br0) get sent to the tcpre chain. In this chain, existing marks are evaulated, and un-marked packets will now have marks applied based on :P entries in the tcrules file. Packets outbound from the firewall itself would use output mangle with a jump to the tcout chain where non :P or :F fwmark entries would be applied.> - Everything originating from the firewall, other than HTTP trafficshould> be routed through Internet Connection #1. > > Now, that third line may be responsible for my problem; however, withoutit,> I can''t accomplish my goal of having all traffic, except outgoing http > traffic routed through Internet Connection #1. Ideally, *incoming*traffic> should just be routed back out the same way in came in and shouldn''t be > affected by anything in this file. >Well it did, without the "loose" option, there was a ip rule (from 192.168.1.111 lookup Wirels) that ensured that the traffic would use the correct provider table. Now you have just fwmarks to do the job. What you need is to mark the packets outbound from the firewall, using the SAME MARK as in the provider file, so the provider''s table routing works.> What I will try now, is excluding connections with a source port of 22,and> see if that allows incoming SSH connections over ath0 to work properly. > However, I''m not sure the best way to combine this with my "55" markabove.> How would I say something like "NOT 55 and NOT 56" in my third line?Where> 56 would be "all traffic from the firewall with source port 22". > > In any case, I''ll temporarily remove the "55" mark to attempt what I > mentioned above... >Think that 55 or 56 should really be a 2. 1:P 0.0.0.0/0 0.0.0.0/0 all 1 $FW 0.0.0.0/0 all - - - !2 2 $FW 0.0.0.0/0 tcp 80,22 Time for sleep. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Think that 55 or 56 should really be a 2. > > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - !2 > 2 $FW 0.0.0.0/0 tcp 80,22 > > Time for sleep. > > JerryOK, I really need sleep, lets try that again. 1:P 0.0.0.0/0 0.0.0.0/0 all 1 $FW 0.0.0.0/0 all - - - !2 2 $FW 0.0.0.0/0 tcp 80 2 $FW 0.0.0.0/0 tcp - 80,22 good night......(morning!!!??? it''s 4am here) Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Ok that is progress, sounds like you may want to use the copy feature in > the > providers file. What that will do is change the routing tables to be > stricter. > > From: > 192.168.1.1 dev ath0 scope link > 70.28.243.0/25 dev eth2 proto kernel scope link src 70.28.243.52 > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 169.254.0.0/16 dev eth2 scope link > 239.0.0.0/8 dev br0 scope link > default via 192.168.1.1 dev ath0 > > To: > > 192.168.1.1 dev ath0 scope link > 192.168.1.0/24 dev ath0 proto kernel scope link src 192.168.1.111 > 10.1.0.0/24 dev br0 proto kernel scope link src 10.1.0.1 > 239.0.0.0/8 dev br0 scope link > default via 192.168.1.1 dev ath0 > > Try this: > Wired 1 1 main eth2 detect > track,balance,loose > br0 > Wirels 2 2 main ath0 192.168.1.1 track,balance,loose > br0 > > JerryNot sure that that will help. I think the problem is that it doesn''t know which routing table to use as it''s just randomly picking one or the other (as far as I can tell). And it should be using the "default" entry in the routing table each time, since my school IP is 129.97.*.*, so the other entries shouldn''t matter. -Matt ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Jerry Vonau > Sent: Wednesday, July 20, 2005 4:55 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > > > Think that 55 or 56 should really be a 2. > > > > 1:P 0.0.0.0/0 0.0.0.0/0 all > > 1 $FW 0.0.0.0/0 all - - - !2 > > 2 $FW 0.0.0.0/0 tcp 80,22 > > > > Time for sleep. > > > > Jerry > > OK, I really need sleep, lets try that again. > > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - !2 > 2 $FW 0.0.0.0/0 tcp 80 > 2 $FW 0.0.0.0/0 tcp - 80,22 > > good night......(morning!!!??? it''s 4am here) > JerryHere''s what I was thinking with the 55... My goal is to say: a) Everything not from the firewall should go over connection #1. So the first tcrules entry takes care of that. b) Everything from the firewall *except* HTTP traffic should go over connection #1 So for b, I would ideally like to be able to say (note the "!") 1 $FW 0.0.0.0/0 all !(80) The problem is that you can''t use the "!" operator on ports... So that''s why I use the 55 entry: 55 $FW 0.0.0.0/0 tcp 80 To *first* mark all local outgoing http traffic... and then I can use !55 in 1 $FW 0.0.0.0/0 all - - - !55 To say "everything *except* http" should go over connection 1. But, maybe a variant of what you''re suggesting would work... something like: [add to the end of tcrules] 1 0.0.0.0/0 0.0.0.0/0 all - - - 1:C 2 0.0.0.0/0 0.0.0.0/0 all - - - 2:C I''m assuming the *connection* is marked with either 1 or 2 when a connection comes in? And then I need to mark the packet before it goes out with the identical mark... But I admit I''m not sure exactly how things are working. Hopefully someone else knows more than I. -Matt ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N wrote:>> > > This is my current tcrules file: > > 55 $FW 0.0.0.0/0 tcp 80 > 1:P 0.0.0.0/0 0.0.0.0/0 all > 1 $FW 0.0.0.0/0 all - - - > !55 > > - Mark all outgoing HTTP traffic from the firewall as 55. > - Everything that comes from a machine other than the firewall, route > through Internet connection #1 using a PRE-ROUTING rule > - Everything originating from the firewall, other than HTTP traffic should > be routed through Internet Connection #1. > > Now, that third line may be responsible for my problem; however, without it, > I can''t accomplish my goal of having all traffic, except outgoing http > traffic routed through Internet Connection #1.If that is your stated goal, why do you have ''balance'' specified on both providers? Why don''t you simply make the route through connection #1 your default route and only redirect the HTTP traffic through ISP 2? -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
>Matt N wrote: > > >> > > > > This is my current tcrules file: > > > > 55 $FW 0.0.0.0/0 tcp 80 > > 1:P 0.0.0.0/0 0.0.0.0/0 all > > 1 $FW 0.0.0.0/0 all - - >- > > !55 > > > > - Mark all outgoing HTTP traffic from the firewall as 55. > > - Everything that comes from a machine other than the firewall, route > > through Internet connection #1 using a PRE-ROUTING rule > > - Everything originating from the firewall, other than HTTP traffic >should > > be routed through Internet Connection #1. > > > > Now, that third line may be responsible for my problem; however, without >it, > > I can''t accomplish my goal of having all traffic, except outgoing http > > traffic routed through Internet Connection #1. > >If that is your stated goal, why do you have ''balance'' specified on both >providers? Why don''t you simply make the route through connection #1 your >default route and only redirect the HTTP traffic through ISP 2? > >-TomI don''t want the firewall''s outgoing HTTP traffic *just* through ISP 2. I want it balanced over both connections. So: a] Everything _except_ the firewall''s outgoing HTTP traffic via ISP 1. b] The firewall''s outgoing HTTP traffic balanced over both ISP 1 & ISP 2. c] incoming connections routed back along the same interface they arrived on, of course Currently, I can get either (a and b) OR (b and c) to work. But I''d like all three ideally. -Matt ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > OK, I really need sleep, lets try that again. > > > > 1:P 0.0.0.0/0 0.0.0.0/0 all > > 1 $FW 0.0.0.0/0 all - - - !2 > > 2 $FW 0.0.0.0/0 tcp 80 > > 2 $FW 0.0.0.0/0 tcp - 80,22 > > > > good night......(morning!!!??? it''s 4am here) > > Jerry > > Here''s what I was thinking with the 55... > > My goal is to say: > > a) Everything not from the firewall should go over connection #1. So the > first tcrules entry takes care of that. > b) Everything from the firewall *except* HTTP traffic should go over > connection #1 > > So for b, I would ideally like to be able to say (note the "!") > > 1 $FW 0.0.0.0/0 all !(80) > > The problem is that you can''t use the "!" operator on ports... So that''swhy> I use the 55 entry:That is because you can''t have an entry in the port column with "all" 1 $FW 0.0.0.0/0 tcp !80 and it does work: 168 7284 MARK tcp -- * * 10.3.0.0/24 0.0.0.0/0 tcp dpt:!25 MARK set 0x1> > 55 $FW 0.0.0.0/0 tcp 80 > > To *first* mark all local outgoing http traffic... and then I can use !55in> > 1 $FW 0.0.0.0/0 all - - - > !55 > > To say "everything *except* http" should go over connection 1. > > But, maybe a variant of what you''re suggesting would work... somethinglike:> > [add to the end of tcrules] > > 1 0.0.0.0/0 0.0.0.0/0 all - - - 1:C > 2 0.0.0.0/0 0.0.0.0/0 all - - - 2:C > > I''m assuming the *connection* is marked with either 1 or 2 when aconnection> comes in? And then I need to mark the packet before it goes out with the > identical mark... But I admit I''m not sure exactly how things areworking.> Hopefully someone else knows more than I. >Can you at least try my suggetstion. There is nothing preventing you from using the same mark over and over in tcrules but with different conditions. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Matt N wrote:>> Matt N wrote: >> >> >> >> > >> > This is my current tcrules file: >> > >> > 55 $FW 0.0.0.0/0 tcp 80 >> > 1:P 0.0.0.0/0 0.0.0.0/0 all >> > 1 $FW 0.0.0.0/0 all - >> - - >> > !55 >> > >> > - Mark all outgoing HTTP traffic from the firewall as 55. >> > - Everything that comes from a machine other than the firewall, route >> > through Internet connection #1 using a PRE-ROUTING rule >> > - Everything originating from the firewall, other than HTTP traffic >> should >> > be routed through Internet Connection #1. >> > >> > Now, that third line may be responsible for my problem; however, >> without it, >> > I can''t accomplish my goal of having all traffic, except outgoing http >> > traffic routed through Internet Connection #1. >> >> If that is your stated goal, why do you have ''balance'' specified on both >> providers? Why don''t you simply make the route through connection #1 your >> default route and only redirect the HTTP traffic through ISP 2? >> >> -Tom > > I don''t want the firewall''s outgoing HTTP traffic *just* through ISP 2. > I want it balanced over both connections. > > So: > > a] Everything _except_ the firewall''s outgoing HTTP traffic via ISP 1. > b] The firewall''s outgoing HTTP traffic balanced over both ISP 1 & ISP 2. > c] incoming connections routed back along the same interface they > arrived on, of course > > Currently, I can get either (a and b) OR (b and c) to work. But I''d > like all three ideally.Not surprising. Shorewall''s multi-ISP facility assumes that the default mode is load-balancing with exceptions for directing traffic to one provider or another. You want exactly the opposite. You will probably be disappointed with what Shorewall offers. -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
I *think* everything is working now! I used an idea similar to one I mentioned earlier today (just got around to trying it now) and it seems to work. I also used the idea from Jerry to get the !80 to work. And I''m using Tom''s "loose" option in the providers file. This is my latest tcrules file: #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 1:P 0.0.0.0/0 0.0.0.0/0 all 1 $FW 0.0.0.0/0 tcp !80 1 $FW 0.0.0.0/0 udp 1 $FW 0.0.0.0/0 all - - - 1:C 2 $FW 0.0.0.0/0 all - - - 2:C I''ll explain: Rule 1: Ensure all non-firewall-generated traffic goes out on ISP 1 Rule 2/3: Mark all packets generated at the firewall (other than those destined to port 80 using TCP) with a 1. Note that some of these packets may later be marked a second time, replacing the 1 with a 2, when rule 5 is encountered [Thanks to Jerry for reminding me of that] Rule 4: Mark all packets generated at the firewall with a 1 *only if* the connection was marked with a 1. Rule 5: Mark all packets generated at the firewall with a 2 *only if* the connection was marked with a 2. Rule 4/5 ensures that any incoming connection on ISP 1/2 is always sent back out on ISP 1/2 This could clearly be automated in the shorewall scripts. Just duplicate rule 4 for each additional ISP. And if additional ports want to be balanced, simply add on the appropriate ! ports on the second or third line (depending on whether it''s a TCP or UDP port) Thanks for everyone''s help. It''s much appreciated. I''ve fully tested it out and it meets my three criteria (I''m pretty sure at least) a] Everything _except_ the firewall''s outgoing HTTP traffic via ISP 1. b] The firewall''s outgoing HTTP traffic balanced over both ISP 1 & ISP 2 c] Incoming connections are routed back along the same interface they arrived on -Matt> -----Original Message----- > From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users- > admin@lists.sourceforge.net] On Behalf Of Tom Eastep > Sent: Wednesday, July 20, 2005 21:45 > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Re: Routing Packets Originating on the > Firewall > > Matt N wrote: > >> Matt N wrote: > >> > >> >> > >> > > >> > This is my current tcrules file: > >> > > >> > 55 $FW 0.0.0.0/0 tcp 80 > >> > 1:P 0.0.0.0/0 0.0.0.0/0 all > >> > 1 $FW 0.0.0.0/0 all - > >> - - > >> > !55 > >> > > >> > - Mark all outgoing HTTP traffic from the firewall as 55. > >> > - Everything that comes from a machine other than the firewall, route > >> > through Internet connection #1 using a PRE-ROUTING rule > >> > - Everything originating from the firewall, other than HTTP traffic > >> should > >> > be routed through Internet Connection #1. > >> > > >> > Now, that third line may be responsible for my problem; however, > >> without it, > >> > I can''t accomplish my goal of having all traffic, except outgoing > http > >> > traffic routed through Internet Connection #1. > >> > >> If that is your stated goal, why do you have ''balance'' specified on > both > >> providers? Why don''t you simply make the route through connection #1 > your > >> default route and only redirect the HTTP traffic through ISP 2? > >> > >> -Tom > > > > I don''t want the firewall''s outgoing HTTP traffic *just* through ISP 2. > > I want it balanced over both connections. > > > > So: > > > > a] Everything _except_ the firewall''s outgoing HTTP traffic via ISP 1. > > b] The firewall''s outgoing HTTP traffic balanced over both ISP 1 & ISP > 2. > > c] incoming connections routed back along the same interface they > > arrived on, of course > > > > Currently, I can get either (a and b) OR (b and c) to work. But I''d > > like all three ideally. > > Not surprising. Shorewall''s multi-ISP facility assumes that the default > mode is load-balancing with exceptions for directing traffic to one > provider or another. You want exactly the opposite. You will probably be > disappointed with what Shorewall offers. > > -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: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click