I am attempting to set up a Multi-ISP configuration of Shorewall where one of
the interfaces is a ppp interface that will not connect to its ISP until after
Shorewall has started. I had to set the interface as optional in
/etc/shorewall/interfaces in order for Shorewall to start. After Shorewall has
started, I can run "ping -I eth2 <GoogleIPaddress>" fine. When
I then bring the
ppp0 interface up, I can no longer ping out the eth2 or ppp0 interface
("Destination host unreachable error"). There seems to be a default
route
through the eth2 interface, but not the ppp0 interface. Is there a way to
configure Shorewall to add the default route to the ppp0 interface when it comes
up? Why can I no longer ping out eth2 once the ppp0 interface comes up? I
currently have everything set to ACCEPT in /etc/shorewall/policy.
tcors02:/etc/shorewall# more interfaces
#ZONE INTERFACE BROADCAST OPTIONS
net eth2 - dhcp
net ppp0 - tcpflags,nosmurfs,optional
net eth3 - dhcp
loc eth0 -
loc eth1 - dhcp
tcors02:/etc/shorewall# more providers
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
lan 1 0x100 main eth2 129.116.XXX.254 track,balance
eth0,eth1
cell 2 0x200 main ppp0 - track,balance eth0,eth1
bgan 3 0x300 main eth3 192.168.128.100 track,balance
eth0,eth1
tcors02:/etc/shorewall# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:166.183.155.49 P-t-P:192.168.111.111 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:64 (64.0 B) TX bytes:97 (97.0 B)
tcors02:/etc/shorewall# ifconfig eth2
eth2 Link encap:Ethernet HWaddr 00:d0:69:45:19:95
inet addr:129.116.XXX.XX Bcast:129.116.XXX.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5958 errors:0 dropped:0 overruns:0 frame:0
TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:442658 (432.2 KiB) TX bytes:18103 (17.6 KiB)
Interrupt:40 Base address:0x240
tcors02:/etc/shorewall# ip route
255.255.255.255 dev eth1 scope link
192.168.111.111 dev ppp0 proto kernel scope link src 166.183.155.49
192.168.128.0/24 dev eth3 proto kernel scope link src 192.168.128.101
129.116.XXX.0/24 dev eth2 proto kernel scope link src 129.116.XXX.XX
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
default
nexthop via 129.116.XXX.254 dev eth2 weight 1
nexthop via 192.168.128.100 dev eth3 weight 1
Thank you for any help that you can provide.
Don
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
After changing the entries in the DUPLICATE and COPY columns of /etc/shorewall/providers to ''-'' and adding KEEP_RT_TABLES=Yes ROUTE_FILTER=No USE_DEFAULT_RT=Yes I was able to get pings to work out of the ppp0 interface when brought up, and then to continue to work out of the eth2 interface when the ppp0 interface is brought down. However, I am still unable to get pings to work out of BOTH interfaces when they are both up at the same time. Any ideas on how to enable that? Pinging out eth2 when ppp0 is up just hangs (there is no "Destination host unreachable" error like before). Don On 2012-03-12 16:08, dtucker wrote:> I am attempting to set up a Multi-ISP configuration of Shorewall where one of > the interfaces is a ppp interface that will not connect to its ISP until > after > Shorewall has started. I had to set the interface as optional in > /etc/shorewall/interfaces in order for Shorewall to start. After Shorewall > has > started, I can run "ping -I eth2 <GoogleIPaddress>" fine. When I then bring > the > ppp0 interface up, I can no longer ping out the eth2 or ppp0 interface > ("Destination host unreachable error"). There seems to be a default route > through the eth2 interface, but not the ppp0 interface. Is there a way to > configure Shorewall to add the default route to the ppp0 interface when it > comes > up? Why can I no longer ping out eth2 once the ppp0 interface comes up? I > currently have everything set to ACCEPT in /etc/shorewall/policy. > > tcors02:/etc/shorewall# more interfaces > #ZONE INTERFACE BROADCAST OPTIONS > net eth2 - dhcp > net ppp0 - tcpflags,nosmurfs,optional > net eth3 - dhcp > loc eth0 - > loc eth1 - dhcp > > tcors02:/etc/shorewall# more providers > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY > lan 1 0x100 main eth2 129.116.XXX.254 track,balance > eth0,eth1 > cell 2 0x200 main ppp0 - track,balance eth0,eth1 > bgan 3 0x300 main eth3 192.168.128.100 track,balance > eth0,eth1 > > tcors02:/etc/shorewall# ifconfig ppp0 > ppp0 Link encap:Point-to-Point Protocol > inet addr:166.183.155.49 P-t-P:192.168.111.111 > Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:64 (64.0 B) TX bytes:97 (97.0 B) > > tcors02:/etc/shorewall# ifconfig eth2 > eth2 Link encap:Ethernet HWaddr 00:d0:69:45:19:95 > inet addr:129.116.XXX.XX Bcast:129.116.XXX.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:5958 errors:0 dropped:0 overruns:0 frame:0 > TX packets:104 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:442658 (432.2 KiB) TX bytes:18103 (17.6 KiB) > Interrupt:40 Base address:0x240 > > tcors02:/etc/shorewall# ip route > 255.255.255.255 dev eth1 scope link > 192.168.111.111 dev ppp0 proto kernel scope link src 166.183.155.49 > 192.168.128.0/24 dev eth3 proto kernel scope link src 192.168.128.101 > 129.116.XXX.0/24 dev eth2 proto kernel scope link src 129.116.XXX.XX > 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 > default > nexthop via 129.116.XXX.254 dev eth2 weight 1 > nexthop via 192.168.128.100 dev eth3 weight 1 > > Thank you for any help that you can provide. > Don > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 3/12/12 4:00 PM, "dtucker" <dtucker@arlut.utexas.edu> wrote:>After changing the entries in the DUPLICATE and COPY columns of >/etc/shorewall/providers to ''-'' and adding > >KEEP_RT_TABLES=Yes >ROUTE_FILTER=No >USE_DEFAULT_RT=Yes > >I was able to get pings to work out of the ppp0 interface when brought >up, and >then to continue to work out of the eth2 interface when the ppp0 >interface is >brought down. However, I am still unable to get pings to work out of BOTH >interfaces when they are both up at the same time. Any ideas on how to >enable >that? Pinging out eth2 when ppp0 is up just hangs (there is no >"Destination >host unreachable" error like before).For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' to be able to help. See http://www.shorewall.net/Support.htm for instructions. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car www.shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 2012-03-12 18:08, Tom Eastep wrote:> On 3/12/12 4:00 PM, "dtucker" <dtucker@arlut.utexas.edu> wrote: > >>After changing the entries in the DUPLICATE and COPY columns of >>/etc/shorewall/providers to ''-'' and adding >> >>KEEP_RT_TABLES=Yes >>ROUTE_FILTER=No >>USE_DEFAULT_RT=Yes >> >>I was able to get pings to work out of the ppp0 interface when brought >>up, and >>then to continue to work out of the eth2 interface when the ppp0 >>interface is >>brought down. However, I am still unable to get pings to work out of BOTH >>interfaces when they are both up at the same time. Any ideas on how to >>enable >>that? Pinging out eth2 when ppp0 is up just hangs (there is no >>"Destination >>host unreachable" error like before). > > For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' > to be able to help. See http://www.shorewall.net/Support.htm for > instructions. > > -Tom >I''ve attached the results of ''shorewall dump.'' I successfully pinged out (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and then attempted (unsuccessfully) to ping out eth2. Thanks in advance to anyone who is able to take a look at it. I received some "RTNETLINK: invalid argument" errors when executing the dump. Just scanning the results of the dump, I didn''t see anything related to ppp0. I DID see some things in the iptables related to connectivity state (ESTABLISHED, RELATED). I don''t understand how those could be in there, since I haven''t entered in any new rules for Shorewall yet (other than ACCEPT all). Before using Shorewall I had iptables set up with connectivity state rules, but I did an iptables -F and an iptables-save before rebooting and Shorewall starting. Don ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 03/13/2012 09:55 AM, dtucker wrote:> On 2012-03-12 18:08, Tom Eastep wrote: >> On 3/12/12 4:00 PM, "dtucker" <dtucker@arlut.utexas.edu> wrote: >> >>> After changing the entries in the DUPLICATE and COPY columns of >>> /etc/shorewall/providers to ''-'' and adding >>> >>> KEEP_RT_TABLES=Yes >>> ROUTE_FILTER=No >>> USE_DEFAULT_RT=Yes >>> >>> I was able to get pings to work out of the ppp0 interface when brought >>> up, and >>> then to continue to work out of the eth2 interface when the ppp0 >>> interface is >>> brought down. However, I am still unable to get pings to work out of BOTH >>> interfaces when they are both up at the same time. Any ideas on how to >>> enable >>> that? Pinging out eth2 when ppp0 is up just hangs (there is no >>> "Destination >>> host unreachable" error like before). >> >> For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' >> to be able to help. See http://www.shorewall.net/Support.htm for >> instructions. >> >> -Tom >> > I''ve attached the results of ''shorewall dump.'' I successfully pinged out > (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and then > attempted (unsuccessfully) to ping out eth2. Thanks in advance to anyone who is > able to take a look at it. I received some "RTNETLINK: invalid argument" errors > when executing the dump. > > Just scanning the results of the dump, I didn''t see anything related to ppp0.That''s because ppp0 was not up when the dump was taken. In the dump, the default route is balanced between eth2 and eth3.> I DID see some things in the iptables related to connectivity state > (ESTABLISHED, RELATED). I don''t understand how those could be in there, since I > haven''t entered in any new rules for Shorewall yet (other than ACCEPT all). > Before using Shorewall I had iptables set up with connectivity state rules, but > I did an iptables -F and an iptables-save before rebooting and Shorewall > starting.What you are seeing is simply the result of the conntrack kernel module being loaded. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 3/13/2012 11:55 AM, dtucker wrote:> On 2012-03-12 18:08, Tom Eastep wrote: >> On 3/12/12 4:00 PM, "dtucker"<dtucker@arlut.utexas.edu> wrote: >> >>> After changing the entries in the DUPLICATE and COPY columns of >>> /etc/shorewall/providers to ''-'' and adding >>> >>> KEEP_RT_TABLES=Yes >>> ROUTE_FILTER=No >>> USE_DEFAULT_RT=Yes >>> >>> I was able to get pings to work out of the ppp0 interface when brought >>> up, and >>> then to continue to work out of the eth2 interface when the ppp0 >>> interface is >>> brought down. However, I am still unable to get pings to work out of BOTH >>> interfaces when they are both up at the same time. Any ideas on how to >>> enable >>> that? Pinging out eth2 when ppp0 is up just hangs (there is no >>> "Destination >>> host unreachable" error like before). >> For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' >> to be able to help. See http://www.shorewall.net/Support.htm for >> instructions. >> >> -Tom >> > I''ve attached the results of ''shorewall dump.'' I successfully pinged out > (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and then > attempted (unsuccessfully) to ping out eth2. Thanks in advance to anyone who is > able to take a look at it. I received some "RTNETLINK: invalid argument" errors > when executing the dump. > > Just scanning the results of the dump, I didn''t see anything related to ppp0. > I DID see some things in the iptables related to connectivity state > (ESTABLISHED, RELATED). I don''t understand how those could be in there, since I > haven''t entered in any new rules for Shorewall yet (other than ACCEPT all). > Before using Shorewall I had iptables set up with connectivity state rules, but > I did an iptables -F and an iptables-save before rebooting and Shorewall > starting. > > DonAfter manually reflushing iptables and restarting Shorewall, I repeated the above test. This time ppp0 appeared in the IP Configuration section of the dump. I''ve attached that file as well, in case it is more relevant that the previous one. Don ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 03/13/2012 10:19 AM, Don Tucker wrote:> > On 3/13/2012 11:55 AM, dtucker wrote: >> On 2012-03-12 18:08, Tom Eastep wrote: >>> On 3/12/12 4:00 PM, "dtucker"<dtucker@arlut.utexas.edu> wrote: >>> >>>> After changing the entries in the DUPLICATE and COPY columns of >>>> /etc/shorewall/providers to ''-'' and adding >>>> >>>> KEEP_RT_TABLES=Yes >>>> ROUTE_FILTER=No >>>> USE_DEFAULT_RT=Yes >>>> >>>> I was able to get pings to work out of the ppp0 interface when brought >>>> up, and >>>> then to continue to work out of the eth2 interface when the ppp0 >>>> interface is >>>> brought down. However, I am still unable to get pings to work out >>>> of BOTH >>>> interfaces when they are both up at the same time. Any ideas on how to >>>> enable >>>> that? Pinging out eth2 when ppp0 is up just hangs (there is no >>>> "Destination >>>> host unreachable" error like before). >>> For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' >>> to be able to help. See http://www.shorewall.net/Support.htm for >>> instructions. >>> >>> -Tom >>> >> I''ve attached the results of ''shorewall dump.'' I successfully pinged out >> (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and >> then >> attempted (unsuccessfully) to ping out eth2. Thanks in advance to >> anyone who is >> able to take a look at it. I received some "RTNETLINK: invalid >> argument" errors >> when executing the dump. >> >> Just scanning the results of the dump, I didn''t see anything related >> to ppp0. >> I DID see some things in the iptables related to connectivity state >> (ESTABLISHED, RELATED). I don''t understand how those could be in >> there, since I >> haven''t entered in any new rules for Shorewall yet (other than ACCEPT >> all). >> Before using Shorewall I had iptables set up with connectivity state >> rules, but >> I did an iptables -F and an iptables-save before rebooting and Shorewall >> starting. >> >> Don > After manually reflushing iptablesWhy are you doing that? It is totally unnecessary.> and restarting Shorewall, I repeated > the above test. This time ppp0 appeared in the IP Configuration section > of the dump. I''ve attached that file as well, in case it is more > relevant that the previous one.The problem here is that bringing up ppp0 is plopping a default route into the main routing table. You need to restart shorewall once ppp0 is up and running. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 03/13/2012 10:29 AM, Tom Eastep wrote:> On 03/13/2012 10:19 AM, Don Tucker wrote: >> >> On 3/13/2012 11:55 AM, dtucker wrote: >>> On 2012-03-12 18:08, Tom Eastep wrote: >>>> On 3/12/12 4:00 PM, "dtucker"<dtucker@arlut.utexas.edu> wrote: >>>> >>>>> After changing the entries in the DUPLICATE and COPY columns of >>>>> /etc/shorewall/providers to ''-'' and adding >>>>> >>>>> KEEP_RT_TABLES=Yes >>>>> ROUTE_FILTER=No >>>>> USE_DEFAULT_RT=Yes >>>>> >>>>> I was able to get pings to work out of the ppp0 interface when brought >>>>> up, and >>>>> then to continue to work out of the eth2 interface when the ppp0 >>>>> interface is >>>>> brought down. However, I am still unable to get pings to work out >>>>> of BOTH >>>>> interfaces when they are both up at the same time. Any ideas on how to >>>>> enable >>>>> that? Pinging out eth2 when ppp0 is up just hangs (there is no >>>>> "Destination >>>>> host unreachable" error like before). >>>> For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' >>>> to be able to help. See http://www.shorewall.net/Support.htm for >>>> instructions. >>>> >>>> -Tom >>>> >>> I''ve attached the results of ''shorewall dump.'' I successfully pinged out >>> (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and >>> then >>> attempted (unsuccessfully) to ping out eth2. Thanks in advance to >>> anyone who is >>> able to take a look at it. I received some "RTNETLINK: invalid >>> argument" errors >>> when executing the dump. >>> >>> Just scanning the results of the dump, I didn''t see anything related >>> to ppp0. >>> I DID see some things in the iptables related to connectivity state >>> (ESTABLISHED, RELATED). I don''t understand how those could be in >>> there, since I >>> haven''t entered in any new rules for Shorewall yet (other than ACCEPT >>> all). >>> Before using Shorewall I had iptables set up with connectivity state >>> rules, but >>> I did an iptables -F and an iptables-save before rebooting and Shorewall >>> starting. >>> >>> Don >> After manually reflushing iptables > > Why are you doing that? It is totally unnecessary. > >> and restarting Shorewall, I repeated >> the above test. This time ppp0 appeared in the IP Configuration section >> of the dump. I''ve attached that file as well, in case it is more >> relevant that the previous one. > > The problem here is that bringing up ppp0 is plopping a default route > into the main routing table. You need to restart shorewall once ppp0 is > up and running. >Or better yet, configure ppp0 so that no default route is generated. That way, you can put ''-'' in the GATEWAY column of ppp0''s providers entry. You are running a fairly old version of Shorewall (4.4.11.6) which doesn''t support the ''enable'' and ''disable'' commands. Those commands allows you to bring up and take down interfaces without restarting Shorewall (providing that bringing up the interface doesn''t create a default route in the main RT). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 3/13/2012 12:59 PM, Tom Eastep wrote:> On 03/13/2012 10:29 AM, Tom Eastep wrote: >> On 03/13/2012 10:19 AM, Don Tucker wrote: >>> On 3/13/2012 11:55 AM, dtucker wrote: >>>> On 2012-03-12 18:08, Tom Eastep wrote: >>>>> On 3/12/12 4:00 PM, "dtucker"<dtucker@arlut.utexas.edu> wrote: >>>>> >>>>>> After changing the entries in the DUPLICATE and COPY columns of >>>>>> /etc/shorewall/providers to ''-'' and adding >>>>>> >>>>>> KEEP_RT_TABLES=Yes >>>>>> ROUTE_FILTER=No >>>>>> USE_DEFAULT_RT=Yes >>>>>> >>>>>> I was able to get pings to work out of the ppp0 interface when brought >>>>>> up, and >>>>>> then to continue to work out of the eth2 interface when the ppp0 >>>>>> interface is >>>>>> brought down. However, I am still unable to get pings to work out >>>>>> of BOTH >>>>>> interfaces when they are both up at the same time. Any ideas on how to >>>>>> enable >>>>>> that? Pinging out eth2 when ppp0 is up just hangs (there is no >>>>>> "Destination >>>>>> host unreachable" error like before). >>>>> For *any* Multi-ISP issue, we need to see the output of ''shorewall dump'' >>>>> to be able to help. See http://www.shorewall.net/Support.htm for >>>>> instructions. >>>>> >>>>> -Tom >>>>> >>>> I''ve attached the results of ''shorewall dump.'' I successfully pinged out >>>> (Google.com) eth2, brought up ppp0, successfully pinged out ppp0, and >>>> then >>>> attempted (unsuccessfully) to ping out eth2. Thanks in advance to >>>> anyone who is >>>> able to take a look at it. I received some "RTNETLINK: invalid >>>> argument" errors >>>> when executing the dump. >>>> >>>> Just scanning the results of the dump, I didn''t see anything related >>>> to ppp0. >>>> I DID see some things in the iptables related to connectivity state >>>> (ESTABLISHED, RELATED). I don''t understand how those could be in >>>> there, since I >>>> haven''t entered in any new rules for Shorewall yet (other than ACCEPT >>>> all). >>>> Before using Shorewall I had iptables set up with connectivity state >>>> rules, but >>>> I did an iptables -F and an iptables-save before rebooting and Shorewall >>>> starting. >>>> >>>> Don >>> After manually reflushing iptables >> Why are you doing that? It is totally unnecessary. >> >>> and restarting Shorewall, I repeated >>> the above test. This time ppp0 appeared in the IP Configuration section >>> of the dump. I''ve attached that file as well, in case it is more >>> relevant that the previous one. >> The problem here is that bringing up ppp0 is plopping a default route >> into the main routing table. You need to restart shorewall once ppp0 is >> up and running. >> > Or better yet, configure ppp0 so that no default route is generated. > That way, you can put ''-'' in the GATEWAY column of ppp0''s providers > entry. You are running a fairly old version of Shorewall (4.4.11.6) > which doesn''t support the ''enable'' and ''disable'' commands. Those > commands allows you to bring up and take down interfaces without > restarting Shorewall (providing that bringing up the interface doesn''t > create a default route in the main RT). > > -TomJust to make sure I understand, are you saying that I do NOT need to restart shorewall if pppd doesn''t add a default route for ppp0? I tried putting ''nodefaultroute'' into /etc/ppp/options, but pon would no longer bring up the interface for some reason. Instead, I deleted the default route as soon as the connection comes up by putting a script into /etc/ppp/ip-up.d to "ip route del default dev ppp0". The result of then bringing ppp0 up was that I could neither ping out of ppp0 nor eth2. After restarting shorewall, I could then ping out of ppp0, but still not eth2. Pinging out eth2 returned the "Destination Host Unreachable" error. Attached is the shorewall dump after having restarted shorewall. 4.4.11 was the latest version that I could find through "aptcache showpkg shorewall". I was wary of trying to install from the .deb and manually managing all of the dependencies that might be required. Thank you for your help! Don ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 03/13/2012 02:57 PM, Don Tucker wrote:>> -Tom > Just to make sure I understand, are you saying that I do NOT need to > restart shorewall if pppd doesn''t add a default route for ppp0?Running 4.4.11.6, if ppp0 is listed in /etc/shorewall/providers then you need to ''shorewall restart'' when it goes up or down.> > I tried putting ''nodefaultroute'' into /etc/ppp/options, but pon would no > longer bring up the interface for some reason. Instead, I deleted the > default route as soon as the connection comes up by putting a script > into /etc/ppp/ip-up.d to "ip route del default dev ppp0". The result of > then bringing ppp0 up was that I could neither ping out of ppp0 nor > eth2. After restarting shorewall, I could then ping out of ppp0, but > still not eth2. Pinging out eth2 returned the "Destination Host > Unreachable" error. Attached is the shorewall dump after having > restarted shorewall.I see no reason why eth2 wouldn''t work. What ''ping'' command were you using? I assume that you were pinging from the firewall itself?> > 4.4.11 was the latest version that I could find through "aptcache > showpkg shorewall". I was wary of trying to install from the .deb and > manually managing all of the dependencies that might be required. >Roberto Sanchez (the Debian Shorewall maintainer) maintains a Squeeze repository with the latest version of Shorewall. It is linked from the Shorewall Download page. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 13/03/2012 22:42, Tom Eastep wrote:> On 03/13/2012 02:57 PM, Don Tucker wrote: > >>> -Tom >> Just to make sure I understand, are you saying that I do NOT need to >> restart shorewall if pppd doesn''t add a default route for ppp0? > Running 4.4.11.6, if ppp0 is listed in /etc/shorewall/providers then you > need to ''shorewall restart'' when it goes up or down.Just to enhance Tom''s answer. Shorewall is only managing interfaces that are up and have IP addresses *at the point shorewall is started*. So if you bring up a PPP connection then you need to restart shorewall so that it''s aware of it. OR if restarting is a problem (usually not) then use a newer version of shorewall which Tom has kindly added an "enable" and "disable" feature so you can do this without a complete restart. A compromise is to set PPP to dial on demand. That way PPP can be "up" but not dialed into anything (so you can start it nice and early). I concede I''m not 100% sure this doesn''t still botch something, but you can test it... Just trying to clarify that since it might not be immediately obvious! Good luck Ed W ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/
On 3/13/2012 5:42 PM, Tom Eastep wrote:> I see no reason why eth2 wouldn''t work. What ''ping'' command were you > using? I assume that you were pinging from the firewall itself?Yes, pinging from the firewall using "ping -I eth2 8.8.8.8".> >> 4.4.11 was the latest version that I could find through "aptcache >> showpkg shorewall". I was wary of trying to install from the .deb and >> manually managing all of the dependencies that might be required. >> > Roberto Sanchez (the Debian Shorewall maintainer) maintains a Squeeze > repository with the latest version of Shorewall. It is linked from the > Shorewall Download page.Unfortunately, Roberto doesn''t have any main/binary-armel/Packages on his repository, and I am running on an arm system. I looked into upgrading to 4.5.0 from 4.4.11 using the standard Debian repositories for the wheezy release, but that version has a dependency on a version of libc6 that requires a kernel version >= 2.6.26. Unfortunately, I have a custom kernel built for my system, so I''m kind of wedded to the 2.6.21 kernel that I have. Don ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/15/12 5:01 PM, "Don Tucker" <dtucker@arlut.utexas.edu> wrote:>On 3/13/2012 5:42 PM, Tom Eastep wrote: >> I see no reason why eth2 wouldn''t work. What ''ping'' command were you >> using? I assume that you were pinging from the firewall itself? >Yes, pinging from the firewall using "ping -I eth2 8.8.8.8". >> >>> 4.4.11 was the latest version that I could find through "aptcache >>> showpkg shorewall". I was wary of trying to install from the .deb and >>> manually managing all of the dependencies that might be required. >>> >> Roberto Sanchez (the Debian Shorewall maintainer) maintains a Squeeze >> repository with the latest version of Shorewall. It is linked from the >> Shorewall Download page. >Unfortunately, Roberto doesn''t have any main/binary-armel/Packages on >his repository, and I am running on an arm system. I looked into >upgrading to 4.5.0 from 4.4.11 using the standard Debian repositories >for the wheezy release, but that version has a dependency on a version >of libc6 that requires a kernel version >= 2.6.26. Unfortunately, I >have a custom kernel built for my system, so I''m kind of wedded to the >2.6.21 kernel that I have.Shorewall has no binaries so it can be installed on any architecture. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/13/2012 12:29 PM, Tom Eastep wrote:>> and restarting Shorewall, I repeated >> the above test. This time ppp0 appeared in the IP Configuration section >> of the dump. I''ve attached that file as well, in case it is more >> relevant that the previous one. > The problem here is that bringing up ppp0 is plopping a default route > into the main routing table. You need to restart shorewall once ppp0 is > up and running. > > -TomI''m wondering what the effect will be of restarting shorewall after bringing up a new interface if I have a data stream going out of an existing interface. Will this cause the data stream to be interrupted? If not, I''ll just try to get v4.4.11 working, otherwise I''ll be strongly motivated to try to update my kernel and move to v4.5 (which I may not have the time in the project budget for). Don ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/19/2012 07:34 AM, Don Tucker wrote:> On 3/13/2012 12:29 PM, Tom Eastep wrote: >>> and restarting Shorewall, I repeated >>> the above test. This time ppp0 appeared in the IP Configuration section >>> of the dump. I''ve attached that file as well, in case it is more >>> relevant that the previous one. >> The problem here is that bringing up ppp0 is plopping a default route >> into the main routing table. You need to restart shorewall once ppp0 is >> up and running. >> >> -Tom > I''m wondering what the effect will be of restarting shorewall after > bringing up a new interface if I have a data stream going out of an > existing interface. Will this cause the data stream to be interrupted?There is that possibility. ''restart'' deletes all routing table changes then reapplies a new set, based on the current state of the interfaces. So it is theoretically possible to get ''no route to host'' conditions during the restart if a route cache entry expires at exactly the right time. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/19/2012 10:30 AM, Tom Eastep wrote:> On 03/19/2012 07:34 AM, Don Tucker wrote: >> On 3/13/2012 12:29 PM, Tom Eastep wrote: >>>> and restarting Shorewall, I repeated >>>> the above test. This time ppp0 appeared in the IP Configuration section >>>> of the dump. I''ve attached that file as well, in case it is more >>>> relevant that the previous one. >>> The problem here is that bringing up ppp0 is plopping a default route >>> into the main routing table. You need to restart shorewall once ppp0 is >>> up and running. >>> >>> -Tom >> I''m wondering what the effect will be of restarting shorewall after >> bringing up a new interface if I have a data stream going out of an >> existing interface. Will this cause the data stream to be interrupted? > There is that possibility. ''restart'' deletes all routing table changes > then reapplies a new set, based on the current state of the interfaces. > So it is theoretically possible to get ''no route to host'' conditions > during the restart if a route cache entry expires at exactly the right time. > > -TomWould the v4.5 shorewall, that does not require a restart when a new interface is brought up, preserve the pre-existing data stream, or could the same situation arise in that case as well? Don ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/19/2012 08:47 AM, Don Tucker wrote:> On 3/19/2012 10:30 AM, Tom Eastep wrote: >> On 03/19/2012 07:34 AM, Don Tucker wrote: >>> On 3/13/2012 12:29 PM, Tom Eastep wrote: >>>>> and restarting Shorewall, I repeated >>>>> the above test. This time ppp0 appeared in the IP Configuration >>>>> section >>>>> of the dump. I''ve attached that file as well, in case it is more >>>>> relevant that the previous one. >>>> The problem here is that bringing up ppp0 is plopping a default route >>>> into the main routing table. You need to restart shorewall once ppp0 is >>>> up and running. >>>> >>>> -Tom >>> I''m wondering what the effect will be of restarting shorewall after >>> bringing up a new interface if I have a data stream going out of an >>> existing interface. Will this cause the data stream to be interrupted? >> There is that possibility. ''restart'' deletes all routing table changes >> then reapplies a new set, based on the current state of the interfaces. >> So it is theoretically possible to get ''no route to host'' conditions >> during the restart if a route cache entry expires at exactly the right >> time. >> >> -Tom > Would the v4.5 shorewall, that does not require a restart when a new > interface is brought up, preserve the pre-existing data stream, or could > the same situation arise in that case as well?The ''enable'' command does not have that vulnerability. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure