We''ve just upgraded to a new firewall machine, and a new version of Shorewall. We''re now on 2.04; previous version was 1.3.9b (!). So I''m pretty sure whatever problems we''re having are related to the big version jump. We''re using config files that exactly match our old (working) configuration (IOW, these are things which _were_ working on the old machine). Many (almost all, really) of the translations work flawlessly. But there are two that don''t, and I''m not sure where to start trying to figure this out. Here''s an example of a working rule: DNAT net:$USER_BUDDY loc:$IN_DEV1_HTTP tcp 80 - $EX_DEV1 and here''s one of the non-working ones: DNAT net:$USER_BUDDY loc:$IN_TEST_HTTP tcp 80 - $EX_TEST As you can see, they''re remarkably similar. $USER_BUDDY is the IP address of my home machine. $IN_DEV1_HTTP and $IN_TEST_HTTP are the internal addresses of two different Apache servers. $EX_DEV1 and $EX_TEST are two IP addresses that are aliased to eth0. (Specifically, here they are from the params file: USER_BUDDY=68.50.32.222 # Home IN_DEV1_HTTP=10.1.1.12:8010 IN_TEST_HTTP=10.1.1.12:8000 EX_TEST=66.92.174.230 # testing.thingeek-ffx.com EX_DEV1=66.92.174.231 # dev-1.thinkgeek-ffx.com if it matters.) Now, I can get to testing (i.e., .230) from _inside_ the firewall, but not from outside. OTOH, I can get to dev-1 (i.e., .231) from both places. The fact that I can get in from inside leads me to believe there''s nothing wrong with the DNS, the IP aliasing, or the Apache server itself. But I do _not_ see any packets getting dropped in the logfile (that is, I see _lots_ of packets getting dropped, just not any of _these_ particular packets). The other rule that doesn''t work is an rsync rule: DNAT net:$USER_EXODUS loc:$IN_TEST_RSYNC tcp 873 - $EX_TEST Unlike with the HTTP rule, I don''t have any working rsync rules to contrast it with, but I''m pretty sure it''s the same situation. In both cases, attempts to connect just timeout. Another thing I thought was a bit odd was that when I tried to rsync from a host that is _not_ allowed, I _still_ didn''t see any logging for those packets, although I expected that I would. Perhaps my expectations are confoozled. Anyways, sorry for the long message but hopefully that''s enough info to make it clear. Let me know if I can provide anything further. TIA for anyone with any thoughts. -- Buddy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Buddy Burden wrote:> We''re using config files that exactly match our old (working) > configuration (IOW, these are things which _were_ working on the old > machine).Buddy -- any time that you upgrade between major Shorewall releases, there is the possibility of incompatible behavior. I try to document these cases in the release notes (in the section entitled "Upgrade Issues") and on the web site (see the "Upgrade Issues" link in the left frame); note though that since you are upgrading from a release that hasn''t been supported in over 18 months, you will have to read the Upgrade Issues on the Shorewall 1.4 web site (link at the top of the home page''s main frame).> > Anyways, sorry for the long message but hopefully that''s enough info to > make it clear. Let me know if I can provide anything further.http://shorewall.net/support.htm makes it very clear what I require to help you. In case there is any doubt in your mind, you ARE having a connection problem so you should pay attention to the sub-bullet that begins THIS IS IMPORTANT! Also -- there is no Shorewall version 2.04 so include the EXACT output of "shorewall version". - -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmr39O/MAbZfjDLIRAr5MAKC0Q6OcP/7Usg5sBtRRP4QDMHcd0wCfZdTH WzeHr6OwNuUPUfai3/CJu8M=mas7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> note though that since you are upgrading from a release that > hasn''t been supported in over 18 months,Correction -- "...over 8 months..." - -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmr7lO/MAbZfjDLIRAhUCAKCd3zC3VfcViwmdVAOvGzlrHG+9ZACgkvC5 Vwa7IvNBXaLFzgVqI0Znsjs=NBnu -----END PGP SIGNATURE-----
Buddy Burden wrote:> We''ve just upgraded to a new firewall machine, and a new version of > Shorewall. We''re now on 2.04; previous version was 1.3.9b (!). So > I''m pretty sure whatever problems we''re having are related to the big > version jump.<problems, etc> Ok. Two things, 1) Check the errata like: ftp://ftp.shorewall.net/pub/shorewall/2.0/shorewall-2.0.9/releasenotes.txt There are syntactical things that have changed, especially across big version jumps. Dig around there in different versions, especially in the 1.3-1.4 and 1.4-2.0 jump. 2) Last, I would strongly suggest submitting a real problem report, read carefully: http://www.shorewall.net/support.htm This details stuff needed for the list to be more helpful. Your submission leaves many things unknown to us so we cannot even start to imagine where the problem might be, unless of course you have the luck of Tom working telepathically from experience, though we all much prefer a real problem report. Alex Martin http://www.rettc.com
Buddy Burden wrote:> We''ve just upgraded to a new firewall machine, and a new version of > Shorewall. We''re now on 2.04; previous version was 1.3.9b (!). So > I''m pretty sure whatever problems we''re having are related to the big > version jump.Sorry I missed this, but for big version jumps, read through http://www.shorewall.net/errata.htm Alex Martin http://www.rettc.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Martin wrote:> Buddy Burden wrote: > >> We''ve just upgraded to a new firewall machine, and a new version of >> Shorewall. We''re now on 2.04; previous version was 1.3.9b (!). So >> I''m pretty sure whatever problems we''re having are related to the big >> version jump. > > > Sorry I missed this, but for big version jumps, read through > http://www.shorewall.net/errata.htm >And http://www.shorewall.net/upgrade_issues.htm -- but when upgrading from 1.3.9b, Buddy also needs http://www.shorewall.net/1.4/upgrade_issues.htm -- 1.3.9b was released over two years ago -- that is an eternity in the history of Shorewall. - -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmsEXO/MAbZfjDLIRAqGtAJ9AvHPvcG+QRqxGL9tJ92lR9lUvPgCeLvSC qj5xoup8M2VcQ2AFviHg6sc=5EY3 -----END PGP SIGNATURE-----
Tom,> I try to document > these cases in the release notes (in the section entitled "Upgrade > Issues") and on the web site (see the "Upgrade Issues" link in the left > frame); note though that since you are upgrading from a release that > hasn''t been supported in over 18 months, you will have to read the > Upgrade Issues on the Shorewall 1.4 web site (link at the top of the > home page''s main frame).Sorry; I should have mentioned that we''ve gone through all these. I ran through them again just now; I don''t see anything that would apply here, although certainly there''s a lot of info there and it''s always possible I missed something. I also ran through all the FAQ''s before I posted and didn''t see anything relevant.> Also -- there is no Shorewall version 2.04 so include the EXACT output > of "shorewall version".Sorry again; simple typo. Should be 2.0.4. Okay, I packed up all our config files (i.e., contents of /etc/shorewall) plus an ip.addr.txt (output of ''ip addr show''), an ip.route.txt (output of ''ip route show''), and a status txt (output of ''shorewall status'' directly after the failure of an rsync). You can get the bundle from http://www.barefoot.net/staff/buddy/files/shorewall-conf.tgz Thanx for taking the time to look at this for us. Let me know if I''ve missed anything I should have included. -- Buddy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Buddy Burden wrote:> Tom, > >> I try to document >> these cases in the release notes (in the section entitled "Upgrade >> Issues") and on the web site (see the "Upgrade Issues" link in the left >> frame); note though that since you are upgrading from a release that >> hasn''t been supported in over 18 months, you will have to read the >> Upgrade Issues on the Shorewall 1.4 web site (link at the top of the >> home page''s main frame). > > > Sorry; I should have mentioned that we''ve gone through all these. I ran > through them again just now; I don''t see anything that would apply here, > although certainly there''s a lot of info there and it''s always possible > I missed something. I also ran through all the FAQ''s before I posted > and didn''t see anything relevant. > >> Also -- there is no Shorewall version 2.04 so include the EXACT output >> of "shorewall version". > > > Sorry again; simple typo. Should be 2.0.4. > > Okay, I packed up all our config files (i.e., contents of > /etc/shorewall) plus an ip.addr.txt (output of ''ip addr show''), an > ip.route.txt (output of ''ip route show''), and a status txt (output of > ''shorewall status'' directly after the failure of an rsync). You can get > the bundle from > > http://www.barefoot.net/staff/buddy/files/shorewall-conf.tgz > > Thanx for taking the time to look at this for us. Let me know if I''ve > missed anything I should have included. >I might have been able to see something more had you carefully followed the instructions associated with the output of "shorewall status" but given that three hours elapsed between the time that the Netfilter counters were last reset and when you obtained the "shorewall status" output, the counters are not useful (and I suspect that you also didn''t try one of the failing connections). Be that as it may, I don''t see anything wrong with the ruleset that Shorewall is generating. You will need to debug one of the failing connections using the tips in FAQs 1a and 1b. If you are still stuck then please post the results of the test along with "shorewall status" output obtained as in the instructions. One note -- you have the wrong rfc1918 file -- the file you are using is for Shorewall 2.0.0 and earlier. Simply delete the file from /etc/shorewall (the correct file is in /usr/share/shorewall). - -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBm33kO/MAbZfjDLIRAoBlAJwJXdgQDcwGGis30x7LHQqqtUdAiACeMkhu zizCulx3GevAeNALBNTFT40=+Qky -----END PGP SIGNATURE-----
On Wed, 2004-11-17 at 08:35 -0800, Tom Eastep wrote:> > Be that as it may, I don''t see anything wrong with the ruleset that > Shorewall is generating. You will need to debug one of the failing > connections using the tips in FAQs 1a and 1b. If you are still stuck > then please post the results of the test along with "shorewall status" > output obtained as in the instructions.Had any luck sorting this out? -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,> Had any luck sorting this out?According to FAQ 1b), I need to analyze the packets. So I installed ethereal, but I haven''t had a chance to figure out how to use it yet. The only other thing I''ve noticed is that the only two things which don''t work are both bound to the same external IP address (they''re two different names in DNS, so I didn''t notice that immediately). Furthermore, they''re the _only_ two services bound to that IP (well, except for the https, but that presumably has the same problem as the http). So basically all my other IP aliases work, but that one doesn''t. ifconfig reports that it looks exactly like all the others (which work), and I also tried changing the its order in the alias list (it had been first), but no change. And although the two services are bound to the same external IP, they end up getting routed to two different internal IPs, so it''s apparently not an issue with a particular box inside the firewall. So I''m off to learn how to use ethereal, it seems. -- Buddy
On Thu, 2004-11-18 at 16:58 -0500, Buddy Burden wrote:> > The only other thing I''ve noticed is that the only two things which > don''t work are both bound to the same external IP address (they''re two > different names in DNS, so I didn''t notice that immediately).If they also are associated with the same internal server, it could be that the server''s default gateway was inadvertently changed and you didn''t notice. -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,> If they also are associated with the same internal server, it could be > that the server''s default gateway was inadvertently changed and you > didn''t notice.Nope, as I said, the two services are going to two different boxes internally. -- Buddy
Hi there, Well i have 2 problems: #1->i use amule in my firewall to download some stuff which uses port 4662/tcp for connections from other clients...the problem is that when i completly close amule others clients stays hanged to my 4662 port as i can see with the shorewall status command,then in a matter of days i will get some thing like this in sylog: Nov 18 13:48:15 caroxo kernel: ip_conntrack: table full, dropping packet. Nov 18 13:48:20 caroxo kernel: ip_conntrack: table full, dropping packet. Nov 18 13:48:26 caroxo kernel: ip_conntrack: table full, dropping packet. Nov 18 13:48:31 caroxo kernel: ip_conntrack: table full, dropping packet. Nov 18 13:48:35 caroxo kernel: ip_conntrack: table full, dropping packet. ....and the machine becomes unsusable and unreacheable. I have noticed that at boot the following in the syslog: Nov 19 10:48:34 caroxo kernel: ip_conntrack version 2.1 (2047 buckets, 16376 max) - 332 bytes per conntrack Nov 19 10:49:58 caroxo kernel: ip_conntrack version 2.1 (2047 buckets, 16376 max) - 332 bytes per conntrack ...in which i understand 16376 is the number of connections avaliable in the kernel table and is the maximum amount of connections that the box permits.... Any ideas? iptables version : 1.2.9 shorewall version:2.0.1 kernel 2.6.3-19 from mandrake OS:Mandrake Linux 10.0 Note:I have 2 machines with mandrake 10.0 with the same problem. Problem #2 I have openvpn serving 2 vpns to another 2 machines this is my network config: tun0:192.168.200.1 tun1:192.168.201.1 eth0:192.168.9.1 eth1:192.168.10.1 eth2:[public_ip] VPNs are working fine and are stable but i cant ping to the other end of tun0 from eth0 but i can ping eth1:192.168.10.200 from eth0:192.168.9.200 (as an example)...cant ping from the other end of tun0 to the other end of tun1 and vice-versa zones: tun0 vpn1 tun1 vpn2 Policy: vpn1 vpn2 ACCEPT vpn2 vpn1 ACCEPT Any ideas on this matter? Thanks.... Paulo Martins
On Fri, 2004-11-19 at 12:09 +0000, paulo wrote:> #1->i use amule in my firewall to download some stuff which uses port 4662/tcp > for connections from other clients...the problem is that when i completly > close amule others clients stays hanged to my 4662 port as i can see with the > shorewall status command,then in a matter of days i will get some thing like > this in sylog: > Nov 18 13:48:15 caroxo kernel: ip_conntrack: table full, dropping packet. > Nov 18 13:48:20 caroxo kernel: ip_conntrack: table full, dropping packet.I would recommend removing the ACCEPT rule for port 4662 when you shut down amule. Your alternative is to increase the size of your conntrack table; instructions may be found in the list archives.> > Note:I have 2 machines with mandrake 10.0 with the same problem. > > Problem #2 > I have openvpn serving 2 vpns to another 2 machines this is my network config: > tun0:192.168.200.1 > tun1:192.168.201.1 > eth0:192.168.9.1 > eth1:192.168.10.1 > eth2:[public_ip] > VPNs are working fine and are stable but i cant ping to the other end of tun0 > from eth0 but i can ping eth1:192.168.10.200 from eth0:192.168.9.200 (as an > example)...cant ping from the other end of tun0 to the other end of tun1 and > vice-versa > zones: > tun0 vpn1 > tun1 vpn2 > Policy: > vpn1 vpn2 ACCEPT > vpn2 vpn1 ACCEPT > > Any ideas on this matter?You haven''t given us enough information to help you. If you submit a complete problem report (see http://shorewall.net/support.htm and pay attention to the part labeled THIS IS IMPORTANT!), we will try to help. -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
Em Sexta, 19 de Novembro de 2004 16:14, o Tom Eastep escreveu:> On Fri, 2004-11-19 at 12:09 +0000, paulo wrote: > > #1->i use amule in my firewall to download some stuff which uses port > > 4662/tcp for connections from other clients...the problem is that when i > > completly close amule others clients stays hanged to my 4662 port as i > > can see with the shorewall status command,then in a matter of days i will > > get some thing like this in sylog: > > Nov 18 13:48:15 caroxo kernel: ip_conntrack: table full, dropping packet. > > Nov 18 13:48:20 caroxo kernel: ip_conntrack: table full, dropping packet. > > I would recommend removing the ACCEPT rule for port 4662 when you shut > down amule. Your alternative is to increase the size of your conntrack > table; instructions may be found in the list archives.is there a way to drop all of these connections on the fly without blocking the access to port something like a bash script run at regularly scheduled times when amule is not running?
On Fri, 2004-11-19 at 16:32 +0000, paulo wrote:> > is there a way to drop all of these connections on the fly without blocking > the access to port something like a bash script run at regularly scheduled > times when amule is not running?Here is what I would do: a) add a zone called ''amule'' at the beginning of /etc/shorewall/zones: amule Amule Virus/Worm/Trojan/DOS Factory b) Enable dynamic zones in /etc/shorewall/shorewall.conf: DYNAMIC_ZONES=Yes c) Add this policy near the front of /etc/shorewall/policy: amule all CONTINUE d) In /etc/shorewall/rules, add the appropriate rules from the ''amule'' zone to enable connections. If amule is running on the firewall: ACCEPT amule fw tcp 4662 e) When starting amule: shorewall add <external-if>:0.0.0.0/0 amule f) When stopping amule: shorewall delete <external-if>:0.0.0.0/0 amule Note: Dynamic zones are currently broken in 2.2.0 Beta * -- I''ll be releasing Beta 4 shortly that contains a fix. -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
Em Sexta, 19 de Novembro de 2004 17:22, o Tom Eastep escreveu:> On Fri, 2004-11-19 at 16:32 +0000, paulo wrote: > > is there a way to drop all of these connections on the fly without > > blocking the access to port something like a bash script run at regularly > > scheduled times when amule is not running? > > Here is what I would do: > > a) add a zone called ''amule'' at the beginning of /etc/shorewall/zones: > > amule Amule Virus/Worm/Trojan/DOS Factory > > b) Enable dynamic zones in /etc/shorewall/shorewall.conf: > > DYNAMIC_ZONES=Yes > > c) Add this policy near the front of /etc/shorewall/policy: > > amule all CONTINUE > > d) In /etc/shorewall/rules, add the appropriate rules from the ''amule'' > zone to enable connections. If amule is running on the firewall: > > ACCEPT amule fw tcp 4662 > > e) When starting amule: > > shorewall add <external-if>:0.0.0.0/0 amule > > f) When stopping amule: > > shorewall delete <external-if>:0.0.0.0/0 amule > > Note: Dynamic zones are currently broken in 2.2.0 Beta * -- I''ll be > releasing Beta 4 shortly that contains a fix. > > -TomWell....it blocks acess to port 4662/tcp but also disables my box to the outside world since the machine cant connect to anywhere outgoing eth1 when i run:shorewall add eth1:0.0.0.0/0 amule P.S:This is the shorewall version 2.0.1 Regards. Paulo Martins
On Mon, 2004-11-22 at 03:52 +0000, paulo wrote:> > -Tom > > Well....it blocks acess to port 4662/tcp but also disables my box to the > outside world since the machine cant connect to anywhere outgoing eth1 when i > run:shorewall add eth1:0.0.0.0/0 amule >Then you did something wrong. -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 Sun, 2004-11-21 at 19:56 -0800, Tom Eastep wrote:> On Mon, 2004-11-22 at 03:52 +0000, paulo wrote: > > > > -Tom > > > > Well....it blocks acess to port 4662/tcp but also disables my box to the > > outside world since the machine cant connect to anywhere outgoing eth1 when i > > run:shorewall add eth1:0.0.0.0/0 amule > > > > Then you did something wrong.On second thought, you probably also need this policy: amule all CONTINUE -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 Sun, 2004-11-21 at 19:56 -0800, Tom Eastep wrote: > > On Mon, 2004-11-22 at 03:52 +0000, paulo wrote: > > > > -Tom > > > > > > Well....it blocks acess to port 4662/tcp but also disables my box to > > > the outside world since the machine cant connect to anywhere outgoing > > > eth1 when i run:shorewall add eth1:0.0.0.0/0 amule > > > > Then you did something wrong. > > On second thought, you probably also need this policy: > > amule all CONTINUE >The policy is there....when i run:shorewall add eth1:0.0.0.0/0 amule the syslog shows a all2all:reject when atempting to outbound eth1 traffic....What i think is happening -->when the shorewall add command is issued all traffic outbound eth1 is directed to amule zones which if it is the case then all traffic from fw to amule zone is reject because there is no policy matching that traffic. My policy file: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL amule all CONTINUE net all DROP info vpn $FW ACCEPT $FW vpn ACCEPT loc vpn ACCEPT vpn loc ACCEPT vpn1 $FW ACCEPT $FW vpn1 ACCEPT # Regards, Paulo Martins
On Mon, 2004-11-22 at 16:13 +0000, paulo wrote:> > On Sun, 2004-11-21 at 19:56 -0800, Tom Eastep wrote: > > > On Mon, 2004-11-22 at 03:52 +0000, paulo wrote: > > > > > -Tom > > > > > > > > Well....it blocks acess to port 4662/tcp but also disables my box to > > > > the outside world since the machine cant connect to anywhere outgoing > > > > eth1 when i run:shorewall add eth1:0.0.0.0/0 amule > > > > > > Then you did something wrong. > > > > On second thought, you probably also need this policy: > > > > amule all CONTINUESorry -- I meant: all amule CONTINUE Yesterday was a very long day... (12 straight hours of server building) -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