I''m trying to get a multiple provider configuration working. I believe I''m having a problem because I bring some virtual interfaces up after Shorewall has been started. Is this to be expected? I have two firewall machines in a fail over configuration. When one firewall goes down, (e.g. to change the firewall rules or install patches), the other one takes over a set of virtual IP addresses such as the default route IP for a couple networks and the IP of the external name server. If I only have one gateway and nothing in the providers file, this fail over works great. When I hook up the other Internet line and configure the providers file, I have trouble. I can reach the real external IP of the firewall, but the external virtual IP of the name server does not respond. My internal hosts that have a default route of an internal virtual IP on the firewall can get out to the Internet fine. However, if an external host tries to reach a server on my DMZ, (which is handled by a NAT rule on the firewall), the traffic is blocked. I did a shorewall restart after a fail over and this seemed to solve my connectivity problems meaning both the external virtual IP on the firewall as well as the hosts behind the NAT all respond. However, this causes another problem. On my ancient hardware, a shorewall restart takes about 10 minutes to complete. When I don''t use the providers file, I can just start Shorewall on system boot and I don''t have to change anything even after a fail over. Is this possible with a providers file? I have used shorewall save when I had a proxy ARP configuration so I could quickly do a shorewall reload after a fail over, but the documentation seems to suggest that the providers set up does not work with shorewall save. Thanks, Karyl ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Monday 07 November 2005 13:50, Karyl F. Stein wrote:> I''m trying to get a multiple provider configuration working. I believe > I''m having a problem because I bring some virtual interfaces up after > Shorewall has been started. Is this to be expected?I wouldn''t think that would be a problem unless bringing up these virtual interfaces is dropping routes. But the symptoms that you describe don''t sound like that''s happening. See http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html for a explanation of why ''virtual interfaces'' are a figment of the deprecated ifconfig utility''s imagination.> > I have two firewall machines in a fail over configuration. When one > firewall goes down, (e.g. to change the firewall rules or install > patches), the other one takes over a set of virtual IP addresses such as > the default route IP for a couple networks and the IP of the external name > server. If I only have one gateway and nothing in the providers file, > this fail over works great. When I hook up the other Internet line and > configure the providers file, I have trouble. I can reach the real > external IP of the firewall, but the external virtual IP of the name > server does not respond. My internal hosts that have a default route of > an internal virtual IP on the firewall can get out to the Internet fine. > However, if an external host tries to reach a server on my DMZ, (which is > handled by a NAT rule on the firewall), the traffic is blocked.So do you have any evidence that it is Shorewall that is "blocking" this traffic? Do you see ''Shorewall'' log messages? Have to looked at this ''blocked'' traffic with a traffic sniffer like Ethereal?> > I did a shorewall restart after a fail over and this seemed to solve my > connectivity problems meaning both the external virtual IP on the firewall > as well as the hosts behind the NAT all respond. However, this causes > another problem. On my ancient hardware, a shorewall restart takes about > 10 minutes to complete. When I don''t use the providers file, I can just > start Shorewall on system boot and I don''t have to change anything even > after a fail over. Is this possible with a providers file? I have used > shorewall save when I had a proxy ARP configuration so I could quickly do > a shorewall reload after a fail over, but the documentation seems to > suggest that the providers set up does not work with shorewall save.It should work fine if you are running the latest 2.4 code. But you really need to understand WHY traffic is ''blocked'' (whatever that means) -- it could be a stale ARP cache in one of the upstream routers and drinking coffee for 10 minutes might be as effective at correcting the problem as doing a ''shorewall restart''. If you want my help, I''ll need ''shorewall status'' output when your router isn''t working and when it is working. Be sure to post this output as compressed attachments. -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
> On Monday 07 November 2005 13:50, Karyl F. Stein wrote: >> I''m trying to get a multiple provider configuration working. I believeI''m having a problem because I bring some virtual interfaces up after Shorewall has been started. Is this to be expected?> > I wouldn''t think that would be a problem unless bringing up thesevirtual> interfaces is dropping routes. But the symptoms that you describe don''tsound> like that''s happening. See > http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html for aexplanation of why ''virtual interfaces'' are a figment of the deprecated ifconfig utility''s imagination. I''ve done some more debugging work on this. The first thing I did is go through the Shorewall configuration files and take out everything except what I thought was necessary for this to work. I then cleaned out the /var/lib/shorewall cache directory and rebooted the computer. This started Shorewall and then the high availability software (heartbeat). Once the server took over all the IP addresses defined by heartbeat, I tested connectivity. Internal and DMZ hosts were able to go out the firewall to the DMZ using a virtual IP on the firewall as the default route. External hosts were able to hit a virtual IP on the firewall that was tied to a NAT rule. In other words, I was able to reach the web and mail servers on the DMZ from an external host using NAT. This connection also worked from the local network. The only issue I found was that external hosts were NOT able to reach the name server running on a virtual IP on the firewall. External hosts could query the name server using the real external IP of the firewall. I ran tcpdump on the external interface when trying to reach the external virtual IP. I saw the packets arrive with the correct source and destination addresses, but that was it. Nothing was logged saying that the packets were dropped or rejected, (Shorewall logging is turned on for both of those cases in the policy file). I don''t know if this is related or not, but I did see ARP requests for my network address (68.267.285.72). I don''t know why that would occur since that IP should not be assignable to a host, (my first usable IP is 68.267.285.73, the firewalls are on 68.267.285.74 and 75, and the virtual IP of the external name server is 68.267.285.76). At this point, I did a shorewall status and a shorewall save. I then did a service shorewall reload. When everything came back up, ALL connectivity worked. I backed up the files created during the last shorewall status and shorewall save, and repeated those steps. Attached, find status.nowork.gz and status.work.gz. As far as the restore file, the working one has the following lines added to it: qt ip rule del from 68.167.185.76 ip rule add from 68.167.185.76 table 1 qt ip rule del from 68.167.185.77 ip rule add from 68.167.185.77 table 1 qt ip rule del from 68.167.185.78 ip rule add from 68.167.185.78 table 1 The 76, 77, and 78 addresses are the virtual IPs, with 76 being serviced directly by the firewall, and 77 and 78 are NAT rules to hosts on the DMZ. One more note is that when I rebooted the machine another time and it started Shorewall with the -f flag using the last files created with shorewall save when the firewall was working completely, no external connectivity worked on any of the virtual IPs (name server or NAT hosts). I did a service shorewall reload and then everything started working again.
On Tuesday 08 November 2005 11:24, Karyl F. Stein wrote:> > qt ip rule del from 68.167.185.76 > ip rule add from 68.167.185.76 table 1 > qt ip rule del from 68.167.185.77 > ip rule add from 68.167.185.77 table 1 > qt ip rule del from 68.167.185.78 > ip rule add from 68.167.185.78 table 1So it looks like that when the standby firewall takes over and the addresses are added, these routing rules need to be added by the takeover script. ip rule add from 68.167.185.76 table 1 ip rule add from 68.167.185.77 table 1 ip rule add from 68.167.185.78 table 1 -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 it looks like that when the standby firewall takes over and the > addresses > are added, these routing rules need to be added by the takeover script. > > ip rule add from 68.167.185.76 table 1 > ip rule add from 68.167.185.77 table 1 > ip rule add from 68.167.185.78 table 1 > > -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.keyThanks, Tom, that seems to have gotten everything working. There is a little lag between entering these rules and the traffic flowing, but if you wait about 30 seconds, things kick in. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
Karyl F. Stein wrote on 09/11/2005 13:03:16:> > So it looks like that when the standby firewall takes over and the > > addresses > > are added, these routing rules need to be added by the takeoverscript.> > > > ip rule add from 68.167.185.76 table 1 > > ip rule add from 68.167.185.77 table 1 > > ip rule add from 68.167.185.78 table 1 > > > > -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 > > Thanks, Tom, that seems to have gotten everything working. There is a > little lag between entering these rules and the traffic flowing, but if > you wait about 30 seconds, things kick in. >Maybe if you issue an "ip route flush cache" after entering the new rules the lag would be smaller? HIH, -- Eduardo Ferreira
----- Original Message ----->> So it looks like that when the standby firewall takes over and the >> addresses >> are added, these routing rules need to be added by the takeover script. >> > > >Thanks, Tom, that seems to have gotten everything working. There is a >little lag between entering these rules and the traffic flowing, but if >you wait about 30 seconds, things kick in.Check the archives, Friday, September 30, 2005 Re: [Shorewall-users] shorewall + Squid + Two ISP setup Where I talk about some proc settings that you can play with, might help Jerry ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Wednesday 09 November 2005 07:38, Jerry Vonau wrote:> ----- Original Message ----- > > >> So it looks like that when the standby firewall takes over and the > >> addresses > >> are added, these routing rules need to be added by the takeover script. > > > >Thanks, Tom, that seems to have gotten everything working. There is a > >little lag between entering these rules and the traffic flowing, but if > >you wait about 30 seconds, things kick in. > > Check the archives, > > Friday, September 30, 2005 > Re: [Shorewall-users] shorewall + Squid + Two ISP setup > Where I talk about some proc settings that you can play with, might help >Gratuitous ARP might also help cut down the delay -- see the Proxy ARP doc for information. -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
> On Wednesday 09 November 2005 07:38, Jerry Vonau wrote: >> Check the archives, >> >> Friday, September 30, 2005 >> Re: [Shorewall-users] shorewall + Squid + Two ISP setup >> Where I talk about some proc settings that you can play with, might help >> > > Gratuitous ARP might also help cut down the delay -- see the Proxy ARP doc > for > information. > > -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.keyAs it turns out, if I''m just a little patient, everything kicks in without having to do the ip route add statements. I am sending a gratuitous ARP, but will look at some of the other suggestions people gave. Thanks. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php