[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS and iptables during bootup



On Sat, Aug 9, 2014 at 3:40 PM, Martin T <m4rtntns@gmail.com> wrote:
> On Sat, Aug 9, 2014 at 6:33 AM, Tom H <tomh0665@gmail.com> wrote:
>> On Fri, Aug 8, 2014 at 11:47 AM, Martin T <m4rtntns@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.


Reply to: