On Sat, Aug 9, 2014 at 3:40 PM, Martin T <m4rtn...@gmail.com> wrote: > On Sat, Aug 9, 2014 at 6:33 AM, Tom H <tomh0...@gmail.com> wrote: >> On Fri, Aug 8, 2014 at 11:47 AM, Martin T <m4rtn...@gmail.com> wrote: >>> >>> I moved the script from /etc/init.d to /etc/network directory and >>> changed the shebang line from /bin/bash to /bin/sh. /bin/sh on my >>> system points to /bin/dash. Thanks for those tips! >>> >>> Content of firewall rule-files can be seen here: >>> >>> # cat /etc/firewall.conf /etc/firewall6.conf >>> # Generated by iptables-save v1.4.8 on Tue Jul 1 10:41:45 2014 >>> *filter >>> :INPUT DROP [17:1605] >>> :FORWARD ACCEPT [0:0] >>> :OUTPUT ACCEPT [259:30520] >>> -A INPUT -s 10.10.10.0/24 -j ACCEPT >>> -A INPUT -s 8.8.8.8/32 -j ACCEPT >>> -A INPUT -s 8.8.4.4/32 -j ACCEPT >>> COMMIT >>> # Completed on Tue Jul 1 10:41:45 2014 >>> # Generated by ip6tables-save v1.4.8 on Tue Jul 1 10:41:56 2014 >>> *filter >>> :INPUT DROP [10518:992304] >>> :FORWARD DROP [0:0] >>> :OUTPUT DROP [0:0] >>> COMMIT >>> # Completed on Tue Jul 1 10:41:56 2014 >>> >>> If I comment out just the "iptables-restore .." line from >>> firewall-script and leave the "ip6tables-restore .." line uncommented, >>> the machine also boots without problems, i.e. it's the IPv4 iptables >>> rules which seem to cause the statd to fail. I modified the IPv4 >>> rules(/etc/firewall.conf file) in a following manner: >>> >>> # cat /etc/firewall.conf >>> # Generated by iptables-save v1.4.8 on Fri Aug 8 17:08:22 2014 >>> *filter >>> :INPUT DROP [1:146] >>> :FORWARD ACCEPT [0:0] >>> :OUTPUT ACCEPT [50:7006] >>> -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT >>> -A INPUT -s 8.8.8.8/32 -i eth0 -j ACCEPT >>> -A INPUT -s 8.8.4.4/32 -i eth0 -j ACCEPT >>> -A INPUT -i lo0 -j ACCEPT >>> COMMIT >>> # Completed on Fri Aug 8 17:08:22 2014 >> >> Your problem's probably that there's no lo0 (a BSD loopback device >> name?). It's lo. > > Yes, I erroneously used "lo0" instead of "lo" in iptables rules. I use > FreeBSD on daily basis :) However, once I allowed traffic to loopback > interface and started NFS("/etc/init.d/nfs-common start"), I saw some > traffic on loopback interface: > > 4 8 560 ACCEPT all -- lo * 0.0.0.0/0 > 0.0.0.0/0 > > During the statd start following traffic is seen on loopback interface: > > 20:39:48.789936 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56 > 20:39:48.790044 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28 > 20:39:48.790221 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56 > 20:39:48.790250 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28 > 20:39:48.790649 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56 > 20:39:48.790759 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28 > 20:39:48.791156 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56 > 20:39:48.791278 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 > (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28 > > Once I save the iptables rules and restart the machine, it boots up > without issues. Thanks! In addition, I will look into > iptables-persistent package. > > However, last but not least, in which situations one firewalls > loopback interface? Or is it a best practice just to allow everything > through the loopback interface like I did?
Please bottom-post. You're welcome. I've always allowed lo - and I've never seen anyone else disallow it. But now that you've asked I feel like checking what apf, arno, and ufw set by default. I can't see them disallowing lo but they might have lo-to-lo-only rules. Your dump above shows that it's 127.0.0.1 communicating to 127.0.0.1 so in statd's case it's feasible. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=syauxmyzngmivgdvzxyosd3kdo1ydbhto8stfcrg-a...@mail.gmail.com