I am trying to force (all) traffic over one isp. I have the following in tcrules: 1 eth0 70.61.215.87/29 2 eth1 216.176.235.184/29 1:P 0.0.0.0/0 1 $FW I want everything unless otherwise directed from eth2 out over eth0 If I don''t have the first 2 lines there port forwarding does not work. Have I got this all wrong? ------------------------------------------------------------------------------
Mark Rutherford wrote:> I am trying to force (all) traffic over one isp. > I have the following in tcrules: > > 1 eth0 70.61.215.87/29 > 2 eth1 216.176.235.184/29 > 1:P 0.0.0.0/0 > 1 $FW > > I want everything unless otherwise directed from eth2 out over eth0 > If I don''t have the first 2 lines there port forwarding does not work.Then you are doing something wrong.> > Have I got this all wrong? >Yes -- in the tcrules file *last match determines the mark value* ------------------------------------------------------------------------------
Ok, well the thing about the top 2 lines was inaccurate. It does work regardless of those. However, it still matters not what I put in there. If I take those out and leave 1:P 0.0.0.0/0 1 $FW In tcrules it changes nothing, breaks nothing. still routes everything over isp 2 Shorewall Guy wrote:> Mark Rutherford wrote: > >> I am trying to force (all) traffic over one isp. >> I have the following in tcrules: >> >> 1 eth0 70.61.215.87/29 >> 2 eth1 216.176.235.184/29 >> 1:P 0.0.0.0/0 >> 1 $FW >> >> I want everything unless otherwise directed from eth2 out over eth0 >> If I don''t have the first 2 lines there port forwarding does not work. >> > > Then you are doing something wrong. > > >> Have I got this all wrong? >> >> > > Yes -- in the tcrules file *last match determines the mark value* > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Ok, well the thing about the top 2 lines was inaccurate. > It does work regardless of those. > > However, it still matters not what I put in there. > If I take those out and leave > > 1:P 0.0.0.0/0 > 1 $FW > > In tcrules it changes nothing, breaks nothing. > still routes everything over isp 2There is a FAQ about that... If the FAQ doesn''t help then we''re going to have to get a real problem report from you and not a couple of lines out of one configuration file. Please see http://www.shorewall.net/support.htm#Guidelines ------------------------------------------------------------------------------
I sent along with my first message the output of shorewall dump
The issue is that we have to transmit files via SFTP and it has to
originate from a certain address.
Otherwise, everything works as intended.
People can browse the internet, port forwarding works, etc etc.
If that dump is no good I can make another.
Here is the output of ''ip addr show''
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:0a:5e:22:ec:fd brd ff:ff:ff:ff:ff:ff
inet 70.61.215.98/24 brd 70.61.215.255 scope global eth0
inet 70.61.215.99/29 brd 70.61.215.103 scope global eth0:0
inet 70.61.215.100/29 brd 70.61.215.103 scope global secondary eth0:1
inet 70.61.215.101/29 brd 70.61.215.103 scope global secondary eth0:2
inet 70.61.215.102/29 brd 70.61.215.103 scope global secondary eth0:3
inet6 fe80::20a:5eff:fe22:ecfd/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:0a:5e:22:ed:0e brd ff:ff:ff:ff:ff:ff
inet 216.176.235.186/29 brd 216.176.235.191 scope global eth1
inet 216.176.235.187/29 brd 216.176.235.191 scope global secondary
eth1:0
inet 216.176.235.188/29 brd 216.176.235.191 scope global secondary
eth1:1
inet 216.176.235.189/29 brd 216.176.235.191 scope global secondary
eth1:2
inet 216.176.235.190/29 brd 216.176.235.191 scope global secondary
eth1:3
inet6 fe80::20a:5eff:fe22:ed0e/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:02:b3:03:d9:f7 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.2/24 brd 10.1.1.255 scope global eth2
inet6 fe80::202:b3ff:fe03:d9f7/64 scope link
valid_lft forever preferred_lft forever
5: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
And... ip route show
70.61.215.96/29 dev eth0 proto kernel scope link src 70.61.215.99
216.176.235.184/29 dev eth1 proto kernel scope link src 216.176.235.186
10.1.1.0/24 dev eth2 proto kernel scope link src 10.1.1.2
70.61.215.0/24 dev eth0 proto kernel scope link src 70.61.215.98
default
nexthop via 216.176.235.185 dev eth1 weight 1
nexthop via 70.61.215.97 dev eth0 weight 1
default via 216.176.235.185 dev eth1
Shorewall Guy wrote:> Mark Rutherford wrote:
>
>> Ok, well the thing about the top 2 lines was inaccurate.
>> It does work regardless of those.
>>
>> However, it still matters not what I put in there.
>> If I take those out and leave
>>
>> 1:P 0.0.0.0/0
>> 1 $FW
>>
>> In tcrules it changes nothing, breaks nothing.
>> still routes everything over isp 2
>>
>
> There is a FAQ about that...
>
> If the FAQ doesn''t help then we''re going to have to get a
real problem
> report from you and not a couple of lines out of one configuration file.
> Please see http://www.shorewall.net/support.htm#Guidelines
>
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
------------------------------------------------------------------------------
Mark Rutherford wrote:> I sent along with my first message the output of shorewall dump > The issue is that we have to transmit files via SFTP and it has to > originate from a certain address. > Otherwise, everything works as intended. > People can browse the internet, port forwarding works, etc etc.I guess I''m lost then as to what problem you are having. So please a) shorewall reset b) Do whatever it is that breaks for you; be sure to create a NEW CONNECTION. c) Take a shorewall dump and forward it d) Tell us: a) What the SOURCE IP address was b) What the destination IP address was c) What the application was (UDP/TCP, dest port number) d) What you expected to happen e) What you believe actually happened and why you believe that. I can tell you that you don''t have the necessary masq entries to make packet marking work from the firewall itself -- is that related to your problem? Thanks ------------------------------------------------------------------------------
Ok, I hope this is it... I did the reset as requested and we tried the connection. A machine on the local network is trying to connect to 208.60.147.148 from 10.1.1.67 on port 22 (tcp) The machine on the other end is expecting us to connect from 70.61.215.98 Basically, I think the remote system just ignores us because we are firewalled out. The sftp client just simply fails to connect. If I drop the other network and we only have the one provider going we connect just fine, but then we are not firewalled out of the remote system. I have asked the operator of that system to allow our /29s and they scoffed... so I have to figure this out. Shorewall Guy wrote:> Mark Rutherford wrote: > >> I sent along with my first message the output of shorewall dump >> The issue is that we have to transmit files via SFTP and it has to >> originate from a certain address. >> Otherwise, everything works as intended. >> People can browse the internet, port forwarding works, etc etc. >> > > I guess I''m lost then as to what problem you are having. > > So please > > a) shorewall reset > b) Do whatever it is that breaks for you; be sure to create a NEW > CONNECTION. > c) Take a shorewall dump and forward it > d) Tell us: > > a) What the SOURCE IP address was > b) What the destination IP address was > c) What the application was (UDP/TCP, dest port number) > d) What you expected to happen > e) What you believe actually happened and why you believe that. > > I can tell you that you don''t have the necessary masq entries to make > packet marking work from the firewall itself -- is that related to your > problem? > > Thanks > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Ok, I hope this is it... > I did the reset as requested and we tried the connection. > A machine on the local network is trying to connect to 208.60.147.148 > from 10.1.1.67 on port 22 (tcp) > The machine on the other end is expecting us to connect from 70.61.215.98 > Basically, I think the remote system just ignores us because we are > firewalled out. > The sftp client just simply fails to connect. > If I drop the other network and we only have the one provider going we > connect just fine, but then we are not firewalled out of the remote system. > > I have asked the operator of that system to allow our /29s and they > scoffed... so I have to figure this out.There is no mystery: Routing Rules 0: from all lookup 255 1000: from all iif eth1 lookup Twc 1001: from all iif eth2 lookup Nuvox <============10001: from all fwmark 0x1 lookup Nuvox 10002: from all fwmark 0x2 lookup Twc 10.1.1.67 connects through eth2. So the above flagged rule sends the connection through Nuvox: Table Nuvox: 216.176.235.185 dev eth1 scope link src 216.176.235.186 216.176.235.184/29 dev eth1 proto kernel scope link src 216.176.235.186 10.1.1.0/24 dev eth2 proto kernel scope link src 10.1.1.2 default via 216.176.235.185 dev eth1 <=========== It goes out through eth1 with a 216.176.... source IP. So it is working exactly as you have configured it. ------------------------------------------------------------------------------
I am at a loss as to what I need to change. I tried inverting the priority numbers in route_rules and changing the order of the entries in the file and it seems to have no effect. Shorewall Guy wrote:> Mark Rutherford wrote: > >> Ok, I hope this is it... >> I did the reset as requested and we tried the connection. >> A machine on the local network is trying to connect to 208.60.147.148 >> from 10.1.1.67 on port 22 (tcp) >> The machine on the other end is expecting us to connect from 70.61.215.98 >> Basically, I think the remote system just ignores us because we are >> firewalled out. >> The sftp client just simply fails to connect. >> If I drop the other network and we only have the one provider going we >> connect just fine, but then we are not firewalled out of the remote system. >> >> I have asked the operator of that system to allow our /29s and they >> scoffed... so I have to figure this out. >> > > There is no mystery: > > Routing Rules > > 0: from all lookup 255 > 1000: from all iif eth1 lookup Twc > 1001: from all iif eth2 lookup Nuvox <============> 10001: from all fwmark 0x1 lookup Nuvox > 10002: from all fwmark 0x2 lookup Twc > > 10.1.1.67 connects through eth2. So the above flagged rule sends the > connection through Nuvox: > > Table Nuvox: > > 216.176.235.185 dev eth1 scope link src 216.176.235.186 > 216.176.235.184/29 dev eth1 proto kernel scope link src 216.176.235.186 > 10.1.1.0/24 dev eth2 proto kernel scope link src 10.1.1.2 > default via 216.176.235.185 dev eth1 <===========> > It goes out through eth1 with a 216.176.... source IP. > > So it is working exactly as you have configured it. > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> I am at a loss as to what I need to change. > I tried inverting the priority numbers in route_rules and changing the > order of the entries in the file and > it seems to have no effect.Your rule for eth1 at pri 1000 is nonsense. Your rule for eth2 at pri 1000 should specify the other provider (assuming that you want all traffic from eth2 to go out through the other provider). ------------------------------------------------------------------------------
Ouch! Ok, I got it now... that took too long to register. Problem now is that the port forwarding traffic is not working. I am trying to connect to port 21 on 216.176.235.187 from (oustside) 70.60.208.84 It never connects and simply times out. If I force the traffic back thru that network it works again. I attached a new dump Shorewall Guy wrote:> Mark Rutherford wrote: > >> I am at a loss as to what I need to change. >> I tried inverting the priority numbers in route_rules and changing the >> order of the entries in the file and >> it seems to have no effect. >> > > Your rule for eth1 at pri 1000 is nonsense. > Your rule for eth2 at pri 1000 should specify the other provider > (assuming that you want all traffic from eth2 to go out through the > other provider). > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Ouch! Ok, I got it now... that took too long to register. > Problem now is that the port forwarding traffic is not working. > I am trying to connect to port 21 on 216.176.235.187 from (oustside) > 70.60.208.84 > It never connects and simply times out. > If I force the traffic back thru that network it works again. > > I attached a new dumpTry changing your route_rule at pri 1000 to pri 11000. ------------------------------------------------------------------------------
No change. Should I send another dump? Shorewall Guy wrote:> Mark Rutherford wrote: > >> Ouch! Ok, I got it now... that took too long to register. >> Problem now is that the port forwarding traffic is not working. >> I am trying to connect to port 21 on 216.176.235.187 from (oustside) >> 70.60.208.84 >> It never connects and simply times out. >> If I force the traffic back thru that network it works again. >> >> I attached a new dump >> > > Try changing your route_rule at pri 1000 to pri 11000. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> No change. > Should I send another dump?What you have now should be correct. I personally have no more ideas. ------------------------------------------------------------------------------
Shorewall Guy wrote:> Mark Rutherford wrote: >> No change. >> Should I send another dump? > > What you have now should be correct. I personally have no more ideas. >But if you send another one, maybe someone else will see something... ------------------------------------------------------------------------------
Thanks for taking a crack at it. Here is the updated dump. I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy. Shorewall Guy wrote:> Shorewall Guy wrote: > >> Mark Rutherford wrote: >> >>> No change. >>> Should I send another dump? >>> >> What you have now should be correct. I personally have no more ideas. >> >> > > But if you send another one, maybe someone else will see something... > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Thanks for taking a crack at it. > Here is the updated dump. > I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy.Sigh -- I wanted you to CHANGE THE PRIORITY to 11000, not duplicate the rule. *It never makes any sense to have exactly the same rule with two different priorities* ------------------------------------------------------------------------------
On Wed, 2008-12-31 at 15:58 -0500, Mark Rutherford wrote:> Thanks for taking a crack at it. > Here is the updated dump. > I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy. > > > Shorewall Guy wrote: > > Shorewall Guy wrote: > > > >> Mark Rutherford wrote: > >> > >>> No change. > >>> Should I send another dump? > >>> > >> What you have now should be correct. I personally have no more ideas. > >> > >> > > > > But if you send another one, maybe someone else will see something... > >This looks funny.... Routing Rules 0: from all lookup 255 1000: from all iif eth2 lookup Twc <<<<<<<<< 1000: from all iif lo lookup Nuvox 10001: from all fwmark 0x1 lookup Nuvox 10002: from all fwmark 0x2 lookup Twc 11000: from all iif eth2 lookup Twc <<<<<<<<<< 20000: from 216.176.235.186 lookup Nuvox 20001: from 216.176.235.187 lookup Nuvox 20002: from 216.176.235.188 lookup Nuvox 20003: from 216.176.235.189 lookup Nuvox 20004: from 216.176.235.190 lookup Nuvox 20256: from 70.61.215.98 lookup Twc 20257: from 70.61.215.99 lookup Twc 20258: from 70.61.215.100 lookup Twc 20259: from 70.61.215.101 lookup Twc 20260: from 70.61.215.102 lookup Twc 32766: from all lookup main 32767: from all lookup default The original rule didn''t get cleared when you changed the route_rule from 1000 to 11000 or do you have both rules present? Just my 2 cents, Jerry ------------------------------------------------------------------------------
I am seeing something here that may explain my troubles. When you said that it was duplicated and I saw that it was in the dump... it was not in the file. I was changing it from one to the other but the entries in the file were never there at the same time with the same priority. I don''t know if this is getting cleared or not. I rebooted the system and left it with the values as suggested and it seems to be working fine now.... Traffic is going out over Twc and port forwarding to the inside is working over both isps so I am at a loss. Should the system be rebooted whenever working with these rules? Shorewall Guy wrote:> Mark Rutherford wrote: > >> Thanks for taking a crack at it. >> Here is the updated dump. >> I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy. >> > > Sigh -- I wanted you to CHANGE THE PRIORITY to 11000, not duplicate the > rule. *It never makes any sense to have exactly the same rule with two > different priorities* > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Shorewall Guy wrote:> Mark Rutherford wrote: >> Thanks for taking a crack at it. >> Here is the updated dump. >> I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy. > > Sigh -- I wanted you to CHANGE THE PRIORITY to 11000, not duplicate the > rule. *It never makes any sense to have exactly the same rule with two > different priorities*And if you did just change the priority rather than duplicate the rule, then we must have a bug -- you can fix the problem by executing this command as root: ip rule delete from all iif eth2 lookup Twc pri 1000 And while you are at it, you can also do this one: ip route delete default via 216.176.235.185 dev eth1 ------------------------------------------------------------------------------
Mark Rutherford wrote:> I am seeing something here that may explain my troubles. > When you said that it was duplicated and I saw that it was in the > dump... it was not in the file. > I was changing it from one to the other but the entries in the file were > never there at the same time with the same priority. > I don''t know if this is getting cleared or not.Hell -- I should have noticed that you are using Shorewall 3.2. That old version works very badly when you are changing your configuration on the fly.>From the Shorewall 3.x Multi-ISP Documentation:Warning If you are running a Shorewall version prior to 3.4.0, entries in /etc/shorewall/providers permanently alter your firewall/gateway''s routing; that is, the effect of these changes is not reversed by shorewall stop or shorewall clear. To restore routing to its original state, you may have to restart your network. This can usually be done by /etc/init.d/network restart or /etc/init.d/networking restart. Check your distribution''s networking documentation.> > I rebooted the system and left it with the values as suggested and it > seems to be working fine now.... > Traffic is going out over Twc and port forwarding to the inside is > working over both isps so I am at a loss.> Should the system be rebooted whenever working with these rules?See above. You really should consider upgrading to Shorewall 4 and switching to Shorewall-perl. See the Shorewall Download page for a source of Debian Etch packages. ------------------------------------------------------------------------------
Jerry Vonau wrote:> > This looks funny.... > > Routing Rules > > 0: from all lookup 255 > 1000: from all iif eth2 lookup Twc <<<<<<<<< > 1000: from all iif lo lookup Nuvox > 10001: from all fwmark 0x1 lookup Nuvox > 10002: from all fwmark 0x2 lookup Twc > 11000: from all iif eth2 lookup Twc <<<<<<<<<< > 20000: from 216.176.235.186 lookup Nuvox > 20001: from 216.176.235.187 lookup Nuvox > 20002: from 216.176.235.188 lookup Nuvox > 20003: from 216.176.235.189 lookup Nuvox > 20004: from 216.176.235.190 lookup Nuvox > 20256: from 70.61.215.98 lookup Twc > 20257: from 70.61.215.99 lookup Twc > 20258: from 70.61.215.100 lookup Twc > 20259: from 70.61.215.101 lookup Twc > 20260: from 70.61.215.102 lookup Twc > 32766: from all lookup main > 32767: from all lookup default > > The original rule didn''t get cleared when you changed the route_rule > from 1000 to 11000 or do you have both rules present?It''s a Shorewall 3.2 thing.... ------------------------------------------------------------------------------
Time to upgrade... I will do that. I will have to see about getting newer packages (this is a Debian) I guess I was bitten by a few bugs. I really appreciate the help guys. Shorewall Guy wrote:> Mark Rutherford wrote: > >> I am seeing something here that may explain my troubles. >> When you said that it was duplicated and I saw that it was in the >> dump... it was not in the file. >> I was changing it from one to the other but the entries in the file were >> never there at the same time with the same priority. >> I don''t know if this is getting cleared or not. >> > > Hell -- I should have noticed that you are using Shorewall 3.2. That old > version works very badly when you are changing your configuration on the > fly. > > >From the Shorewall 3.x Multi-ISP Documentation: > > Warning > > If you are running a Shorewall version prior to 3.4.0, entries > in /etc/shorewall/providers permanently alter your > firewall/gateway''s routing; that is, the effect of these changes > is not reversed by shorewall stop or shorewall clear. To restore > routing to its original state, you may have to restart your > network. This can usually be done by /etc/init.d/network restart > or /etc/init.d/networking restart. Check your distribution''s > networking documentation. > > >> I rebooted the system and left it with the values as suggested and it >> seems to be working fine now.... >> Traffic is going out over Twc and port forwarding to the inside is >> working over both isps so I am at a loss. >> > > >> Should the system be rebooted whenever working with these rules? >> > > See above. > > You really should consider upgrading to Shorewall 4 and switching to > Shorewall-perl. See the Shorewall Download page for a source of Debian > Etch packages. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Well, I did the upgrade and now I have had a total failure. None of the port forwarding is working, and trying to browse to any website times out (squid runs on the firewall) I can traceroute out, RPD out, etc.... I ended up with version 4.0.15 Should I try to remove it and go back to 3.3 or try to figure out what happened here? I changed no configs.. and I said no when the package manager asked if it could. Mark Rutherford wrote:> Time to upgrade... I will do that. > I will have to see about getting newer packages (this is a Debian) > I guess I was bitten by a few bugs. > > I really appreciate the help guys. > > > Shorewall Guy wrote: > >> Mark Rutherford wrote: >> >> >>> I am seeing something here that may explain my troubles. >>> When you said that it was duplicated and I saw that it was in the >>> dump... it was not in the file. >>> I was changing it from one to the other but the entries in the file were >>> never there at the same time with the same priority. >>> I don''t know if this is getting cleared or not. >>> >>> >> Hell -- I should have noticed that you are using Shorewall 3.2. That old >> version works very badly when you are changing your configuration on the >> fly. >> >> >From the Shorewall 3.x Multi-ISP Documentation: >> >> Warning >> >> If you are running a Shorewall version prior to 3.4.0, entries >> in /etc/shorewall/providers permanently alter your >> firewall/gateway''s routing; that is, the effect of these changes >> is not reversed by shorewall stop or shorewall clear. To restore >> routing to its original state, you may have to restart your >> network. This can usually be done by /etc/init.d/network restart >> or /etc/init.d/networking restart. Check your distribution''s >> networking documentation. >> >> >> >>> I rebooted the system and left it with the values as suggested and it >>> seems to be working fine now.... >>> Traffic is going out over Twc and port forwarding to the inside is >>> working over both isps so I am at a loss. >>> >>> >> >> >>> Should the system be rebooted whenever working with these rules? >>> >>> >> See above. >> >> You really should consider upgrading to Shorewall 4 and switching to >> Shorewall-perl. See the Shorewall Download page for a source of Debian >> Etch packages. >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Well, I did the upgrade and now I have had a total failure. > None of the port forwarding is working, and trying to browse to any > website times out (squid runs on the firewall) > I can traceroute out, RPD out, etc.... > I ended up with version 4.0.15 > Should I try to remove it and go back to 3.3 or try to figure out what > happened here? > I changed no configs.. and I said no when the package manager asked if > it could.You''d probably better reinstall 3.2 -- It is New Year''s Eve and I, for one, am not going to stay home and help you figure out what is wrong. ------------------------------------------------------------------------------
I am with you there. I don''t want to stay here either :) Shorewall Guy wrote:> Mark Rutherford wrote: > >> Well, I did the upgrade and now I have had a total failure. >> None of the port forwarding is working, and trying to browse to any >> website times out (squid runs on the firewall) >> I can traceroute out, RPD out, etc.... >> I ended up with version 4.0.15 >> Should I try to remove it and go back to 3.3 or try to figure out what >> happened here? >> I changed no configs.. and I said no when the package manager asked if >> it could. >> > > You''d probably better reinstall 3.2 -- It is New Year''s Eve and I, for > one, am not going to stay home and help you figure out what is wrong. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------
Mark Rutherford wrote:> Well, I did the upgrade and now I have had a total failure. > None of the port forwarding is working, and trying to browse to any > website times out (squid runs on the firewall) > I can traceroute out, RPD out, etc.... > I ended up with version 4.0.15 > Should I try to remove it and go back to 3.3 or try to figure out what > happened here? > I changed no configs.. and I said no when the package manager asked if > it could. >Although, you might try rebooting. If you simply upgraded, that would do a "shorewall restart" which will leave a complete mess considering that you upgraded across two major releases. ------------------------------------------------------------------------------
I tried that before I dropped a message. I just went back to 3.2.6 and things started to work again like magic, again with no changes to any config files. There must be a difference but I am happy that it at least works this much. Let''s pick this one up after the holidays.. it will be there... :) Thanks again, I don''t think I would have kept my sanity this long. Happy new year to all. Shorewall Guy wrote:> Mark Rutherford wrote: > >> Well, I did the upgrade and now I have had a total failure. >> None of the port forwarding is working, and trying to browse to any >> website times out (squid runs on the firewall) >> I can traceroute out, RPD out, etc.... >> I ended up with version 4.0.15 >> Should I try to remove it and go back to 3.3 or try to figure out what >> happened here? >> I changed no configs.. and I said no when the package manager asked if >> it could. >> >> > > Although, you might try rebooting. If you simply upgraded, that would do > a "shorewall restart" which will leave a complete mess considering that > you upgraded across two major releases. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------