Hi List, I read this list for nearly two years and learnt a lot, but now i have a very strange problem I can''t solve.. I have a firewall machine running Debian, which connects a small office to the internet via a DSL-line (with pppoe) and which is running Shorewall. It allows all outbound traffic and accepts pptp, openvpn and ssh-connections (on a non-standard port) from the internet. When I first set up that machine, I installed a Shorewall 1.4.X, configured and tested my custom setup, which worked fine. Some months ago I upgraded to version 2.0.15, went through the Upgrade-guide, had a look at all config-files and everything looked fine - my setup was working like charm... We are connected to the Internet with a dynamic DSL-connection, so every 24 hours the ISP shuts down our link and pppd restarts it automatically - shorewall is also restarted. From time to time (every 2-3 months) there seems to be a problem with the DSL-link, the DSL-modem hangs, and pppd stops trying after 10 unsuccesfull connection attempts (btw: is there a way to tell pppd to try infinite times until it succeeds?). When this happens my customer has to power-cycle the DSL-modem, go to the firewall machine and tell the pppd-demon to try again by issung a ''pon'' at the prompt. this is not very convenient, but it works and it does not happen that often. Some days ago, the customer experienced again the problem with the modem, and followed the instructions above. Afterwards the outbound connection worked as usual, but from that moment on I couldn''t connect to firewall from outside anymore. all connection attempts with ssh and pings a silently dropped. So now I''m sitting here in the customers office and try to figure out why shorewall is dropping them - and I have to admitt I have no clue. The configuration has not changed. If I issue a ''shorewall clear'' the connection attempts and the ping works, but if shorewall is running my configuaration(s) the packets are dropped. I tried several different configurations in the /etc/shorewall/policy for net -> all (and even all -> all) traffic (ACCEPT, REJECT, DROPPED) - the packets *always* get dropped. I also moved the /etc/shorewall/rules file out of the way to ensure that there is no misconfiguration in the rules - that didn''t help. I thought, that somehow shorewall is not reading the files I change, but ''shorewall status'' tells me, it''s reading from /etc/shorewall and if I change the configuration from fw -> net and loc -> fw these changes are applied! Since all the packets are dropped I tried to change every occurance of DROP in files under /etc/shorewall to REJECT - that didn''t change anything, the packets are still dropped silently.. The only vague idea I have at the moment is that this is the first modem-related problem since my upgrade to version 2.0.15 and that I missed some changed configuration options then. but since a ''pon'' is only restarting the DSL-link and shorewall, which happens every 24 hours anyway, I doubt that the problem is related to that. I also tried to set up logging, to see what happens to the dropped packets in which chain. but that''s also very strange - I can''t get logging to work, either! I installed ulogd and I think I have the ulogd-support in the kernel - I compiled the kernel myself, and the .config file has a CONFIG_IP_NF_TARGET_ULOG=y - is there a way to tell if it really works, if I don''t have support for /proc/config.gz? I setup ulogd like told on the shorewall homepage, replaced every loglevel in shorewall.conf with ULOG and set the logging to some different rules in the policy and rules file - but nothing gets written to the logfile in defined /etc/ulogd - the file exists (with size zero) and is writeable by root..even if I try to log rules which are apllied (like the fw -> net I mentioned above), nothing gets logged.. This behaviour - dropping all incoming connections and refusing to write log information - is very strange and I have no idea where to check for some errors and misconfiguration - I''m a bit desperate at the moment. Unfortunately I don''t understand netfilter that well to find the place where the incoming packets are dropped from the output of ''shorewall status'' - if anyone can give me a hint by looking at the attached output of ''shorewall status'' or has some other idea what is happening here, I would be *very* thankful! thanks in advance: stephan. ___________________________________________________________________________ stephan beirer invalidenstr 42 10115 berlin/germany theoretical biophysics phon +49 30 2093 8694 room 501 institute of biology http://itb.biologie.hu-berlin.de/~beirer humboldt university of berlin mail s.beirer@biologie.hu-berlin.de
On Monday 09 May 2005 14:00, stephan beirer wrote: At least I can help here:>From time to time (every > 2-3 months) there seems to be a problem with the DSL-link, the > DSL-modem hangs, and pppd stops trying after 10 unsuccesfull > connection attempts (btw: is there a way to tell pppd to try infinite > times until it succeeds?).pass "maxfail 0" as option to pppd, but i don''t know the debian way of doing it. Alex
stephan beirer wrote:> the moment. > > Unfortunately I don''t understand netfilter that well to find the place > where the incoming packets are dropped from the output of ''shorewall > status'' - if anyone can give me a hint by looking at the attached > output of ''shorewall status'' or has some other idea what is happening > here, I would be *very* thankful! >There are no log messages displayed in the output -- do you have the LOGFILE variable in shorewall.conf set to the file where Netfilter messages are being logged? -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
stephan beirer wrote:> Mangle Table > > Chain PREROUTING (policy ACCEPT 72160 packets, 25M bytes) > pkts bytes target prot opt in out source destination > 112 7100 man1918 all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW > 20543 5831K pretos all -- * * 0.0.0.0/0 0.0.0.0/0 > > Chain INPUT (policy ACCEPT 477 packets, 57572 bytes) > pkts bytes target prot opt in out source destination > > Chain FORWARD (policy ACCEPT 71675 packets, 25M bytes) > pkts bytes target prot opt in out source destination > > Chain OUTPUT (policy ACCEPT 326 packets, 152K bytes) > pkts bytes target prot opt in out source destination > 68 8384 outtos all -- * * 0.0.0.0/0 0.0.0.0/0 > > Chain POSTROUTING (policy ACCEPT 71977 packets, 25M bytes) > pkts bytes target prot opt in out source destination > > Chain man1918 (1 references) > pkts bytes target prot opt in out source destination > 0 0 RETURN all -- * * 0.0.0.0/0 255.255.255.255 > 0 0 DROP all -- * * 0.0.0.0/0 169.254.0.0/16 > 0 0 rfc1918 all -- * * 0.0.0.0/0 172.16.0.0/12 > 0 0 rfc1918 all -- * * 0.0.0.0/0 192.0.2.0/24 > 0 0 rfc1918 all -- * * 0.0.0.0/0 192.168.0.0/16 > 0 0 rfc1918 all -- * * 0.0.0.0/0 0.0.0.0/7 > 0 0 rfc1918 all -- * * 0.0.0.0/0 2.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 5.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 7.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 10.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 23.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 27.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 31.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 36.0.0.0/7 > 0 0 rfc1918 all -- * * 0.0.0.0/0 39.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 41.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 42.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 49.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 50.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 58.0.0.0/7 > 0 0 rfc1918 all -- * * 0.0.0.0/0 60.0.0.0/8 > 0 0 rfc1918 all -- * * 0.0.0.0/0 70.0.0.0/7 > 0 0 rfc1918 all -- * * 0.0.0.0/0 72.0.0.0/5 > 0 0 rfc1918 all -- * * 0.0.0.0/0 83.0.0.0/8 > 112 7100 rfc1918 all -- * * 0.0.0.0/0 84.0.0.0/6 <================> > IP Configuration > > 1: lo: <LOOPBACK,UP> 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 > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:02:a5:95:6b:3b brd ff:ff:ff:ff:ff:ff > inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 > 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:50:fc:a2:8e:fd brd ff:ff:ff:ff:ff:ff > 5: tunl0@NONE: <NOARP> mtu 1480 qdisc noop > link/ipip 0.0.0.0 brd 0.0.0.0 > 6: gre0@NONE: <NOARP> mtu 1476 qdisc noop > link/gre 0.0.0.0 brd 0.0.0.0 > 7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 > link/ppp > inet 84.190.138.214 peer 217.0.116.3/32 scope global ppp0-------------- The change that made this stop working was at your ISP -- they started using IP addresses from 84.0.0.0/8 which you are blocking by having the wrong/obsolete rfc1918 file installed. Even though you are running Shorewall 2.0.15, you are using the rfc1918 file from Shorewall 2.0.0 and earlier AND IT IS OUT OF DATE. If you have a file named ''rfc1918'' in /etc/shorewall DELETE IT. If you have put the wrong rfc1918 file in /usr/share/shorewall then replace it with the attached one which is from 2.0.15. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > If you have a file named ''rfc1918'' in /etc/shorewall DELETE IT. If you > have put the wrong rfc1918 file in /usr/share/shorewall then replace it > with the attached one which is from 2.0.15. >Oops -- forgot the attachment. Here it is. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
[Tom Eastep <teastep@shorewall.net> wrote on Mon May 09, 2005 at 07:16:43AM -0700 To Mailing List for Shorewall Users]:> > 6: gre0@NONE: <NOARP> mtu 1476 qdisc noop > > link/gre 0.0.0.0 brd 0.0.0.0 > > 7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 > > link/ppp > > inet 84.190.138.214 peer 217.0.116.3/32 scope global ppp0 > -------------- > > The change that made this stop working was at your ISP -- they started > using IP addresses from 84.0.0.0/8 which you are blocking by having the > wrong/obsolete rfc1918 file installed. Even though you are running > Shorewall 2.0.15, you are using the rfc1918 file from Shorewall 2.0.0 > and earlier AND IT IS OUT OF DATE. > > If you have a file named ''rfc1918'' in /etc/shorewall DELETE IT. If you > have put the wrong rfc1918 file in /usr/share/shorewall then replace it > with the attached one which is from 2.0.15.Tom, thank you a thousand times! it was the left-over rfc1918 from the old 1.4.x configuration.. and shame on me: i read about the changed behaviour several times on the list..:( and also in the "Upgrade Issues" section of the website..but I didn''t realize that I have to delete the old file manually. maybe this is debian-specific, but the debian-documentation in /usr/share/doc/shorewall doesn''t mention that either..maybe I''ll file a bug for the debian package maintainer.. thanks again. and just as a sidenote: shorewall is a great peace of software - thanks for all your work and to everyone on the list who helps with user-support. cheers from berlin: stephan. __________________________________________________________________________ stephan beirer invalidenstr 42 10115 berlin/germany theoretical biophysics phon +49 30 2093 8694 room 501 institute of biology http://itb.biologie.hu-berlin.de/~beirer humboldt university of berlin mail s.beirer@biologie.hu-berlin.de
stephan beirer wrote:> > I also tried to set up logging, to see what happens to the dropped > packets in which chain. but that''s also very strange - I can''t get > logging to work, either! I installed ulogd and I think I have the > ulogd-support in the kernel - I compiled the kernel myself, and the > .config file has a CONFIG_IP_NF_TARGET_ULOG=y - is there a way to tell > if it really works, if I don''t have support for /proc/config.gz?You definitely have the kernel part set up correctly. Shorewall wouldn''t start otherwise.> > I setup ulogd like told on the shorewall homepage, replaced every > loglevel in shorewall.conf with ULOG and set the logging to some > different rules in the policy and rules file - but nothing gets > written to the logfile in defined /etc/ulogd - the file exists (with > size zero) and is writeable by root..even if I try to log rules which > are apllied (like the fw -> net I mentioned above), nothing gets > logged.. >Have you confirmed that ulogd is running? If so, use lsof to see of ulogd really has the log file open (lsof -p <ulogd''s pid>). -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
stephan beirer wrote:> > Tom, thank you a thousand times! it was the left-over rfc1918 from the > old 1.4.x configuration.. > > > and shame on me: i read about the changed behaviour several times on > the list..:( > > and also in the "Upgrade Issues" section of the website..but I didn''t > realize that I have to delete the old file manually. maybe this is > debian-specific, but the debian-documentation in > /usr/share/doc/shorewall doesn''t mention that either..maybe I''ll file > a bug for the debian package maintainer.. >Good idea -- since the Debian package doesn''t manage the contents of /etc/shorewall, Debian users upgrading from versions <= 2.0.0 must manually remove the old file. -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
2005/5/9, stephan beirer <beirer-shorewall@itb.biologie.hu-berlin.de>:> We are connected to the Internet with a dynamic DSL-connection, so > every 24 hours the ISP shuts down our link and pppd restarts it > automatically - shorewall is also restarted. From time to time (every > 2-3 months) there seems to be a problem with the DSL-link, the > DSL-modem hangs, and pppd stops trying after 10 unsuccesfull > connection attempts (btw: is there a way to tell pppd to try infinite > times until it succeeds?).in rp-pppoe.conf CONNECT_TIMEOUT=0 that do the trick. bye
2005/5/9, Cristian Rodriguez <judas.iscariote@gmail.com>:> 2005/5/9, stephan beirer <beirer-shorewall@itb.biologie.hu-berlin.de>: > > > > We are connected to the Internet with a dynamic DSL-connection, so > > every 24 hours the ISP shuts down our link and pppd restarts it > > automatically - shorewall is also restarted. From time to time (every > > 2-3 months) there seems to be a problem with the DSL-link, the > > DSL-modem hangs, and pppd stops trying after 10 unsuccesfull > > connection attempts (btw: is there a way to tell pppd to try infinite > > times until it succeeds?). > > in rp-pppoe.conf > > CONNECT_TIMEOUT=0 > > that do the trick. > > bye >and also there is no real reason to use such older version of shorewall,consider a update to the latest version.
[Tom Eastep <teastep@shorewall.net> wrote on Mon May 09, 2005 at 09:00:57AM -0700 To Mailing List for Shorewall Users]:> Have you confirmed that ulogd is running? If so, use lsof to see of > ulogd really has the log file open (lsof -p <ulogd''s pid>).ok, it''s solved - it was the problem of the ulogd version coming with debian stable (0.97) as already described here: http://lists.shorewall.net/pipermail/shorewall-users/2003-August/008343.html upgrading to ulogd 1.02 from debian testing made it work.. btw: does anybody know what the line logd 1052 root 5u sock 0,0 184266 can''t identify protocol from ''lsof -p <ulogd''s pid>'' means? thanks again, cheers:stephan. ___________________________________________________________________________ stephan beirer invalidenstr 42 10115 berlin/germany theoretical biophysics phon +49 30 2093 8694 room 501 institute of biology http://itb.biologie.hu-berlin.de/~beirer humboldt university of berlin mail s.beirer@biologie.hu-berlin.de
stephan beirer wrote:> [Tom Eastep <teastep@shorewall.net> wrote on Mon May 09, 2005 at 09:00:57AM -0700 To Mailing List for Shorewall Users]: > >>Have you confirmed that ulogd is running? If so, use lsof to see of >>ulogd really has the log file open (lsof -p <ulogd''s pid>). > > > ok, it''s solved - it was the problem of the ulogd version coming with > debian stable (0.97) as already described here: > > http://lists.shorewall.net/pipermail/shorewall-users/2003-August/008343.html > > upgrading to ulogd 1.02 from debian testing made it work.. > btw: does anybody know what the line > > logd 1052 root 5u sock 0,0 184266 can''t identify protocol > > from ''lsof -p <ulogd''s pid>'' means?Probably that''s the Netfilter socket that ulogd uses to get ULOG messages from the kernel. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
[Tom Eastep <teastep@shorewall.net> wrote on Mon May 09, 2005 at 09:03:26AM -0700 To Mailing List for Shorewall Users]:> > and also in the "Upgrade Issues" section of the website..but I didn''t > > realize that I have to delete the old file manually. maybe this is > > debian-specific, but the debian-documentation in > > /usr/share/doc/shorewall doesn''t mention that either..maybe I''ll file > > a bug for the debian package maintainer.. > > > > Good idea -- since the Debian package doesn''t manage the contents of > /etc/shorewall, Debian users upgrading from versions <= 2.0.0 must > manually remove the old file.did submit the bug-report. cheers:stephan. ___________________________________________________________________________ stephan beirer invalidenstr 42 10115 berlin/germany theoretical biophysics phon +49 30 2093 8694 room 501 institute of biology http://itb.biologie.hu-berlin.de/~beirer humboldt university of berlin mail s.beirer@biologie.hu-berlin.de