[Solved] Allowing local traffic through Iptables

vendion · 2011-01-07 20:37:35

I am setting up as system as a home server and two of the processes that I am running on it is Samba and NFs for network storage. I can mount and access both shares locally on the system, but on the LAN I am getting timeout errors. The problem seems to be coming from my firewall (iptables), because when I have it turned off I can mount the share from a system on my LAN, but get timeout errors when iptables is running.

Here is my /etc/hosts.allow:

#
# /etc/hosts.allow
#
sshd:   ALL
nfsd:   192.168.1.0/255.255.255.0
rpcbind:        192.168.1.0/255.255.255.0
mountd: 192.168.1.0/255.255.255.0
samba:  192.168.1.0/255.255.255.0
vsftp:  ALL
# End of file

Here is my Iptables rule list:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1525  187K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    3   120 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
 2225  214K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 state NEW 
  869  119K UDP        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW 
  989 58916 TCP        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x02 state NEW 
  869  119K REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
  988 58856 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-proto-unreachable 
    0     0 ACCEPT     all  --  *      *       192.168.1.0/24       0.0.0.0/0                                                                                   
                                                                                
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)                                
 pkts bytes target     prot opt in     out     source               destination                                                                                 
                                                                                
Chain OUTPUT (policy ACCEPT 4748 packets, 666K bytes)                           
 pkts bytes target     prot opt in     out     source               destination                                                                                 
                                                                                
Chain TCP (1 references)                                                        
 pkts bytes target     prot opt in     out     source               destination                                                                                 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80                                                              
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:20                                                              
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21                                                              
    1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22                                                              
                                                                                
Chain UDP (1 references)                                                        
 pkts bytes target     prot opt in     out     source               destination                                                                                 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53

That said here is what happens when I try to mount the NFS share

(With firewall running)
vendion ~ $ sudo mount -t nfs loki:/srv/nfs /mnt/nfs
Password: 
mount.nfs: Connection timed out
(With firewall off)
vendion ~ $ sudo mount -t nfs loki:/srv/nfs /mnt/nfs
Password: 
vendion ~ $ mount
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=353025,mode=755)
/dev/disk/by-uuid/c248a2d9-7fd9-48a4-ad49-551246f36bee on / type jfs (rw,relatime)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda7 on /home type ext4 (rw,commit=0)
loki:/srv/nfs on /mnt/nfs type nfs (rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3)

Anything that sticks out to anyone that I need to do?

Last edited by vendion (2011-01-21 04:50:21)

madeye · 2011-01-07 22:08:41

It looks like you need to open the ports samba is listening on.
Perhaps this can help you: http://troy.jdmz.net/samba/fw/

Damnshock · 2011-01-07 22:18:27

Here is what I use on my home server:

# Allow Samba access from local network
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 445 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 445 -j ACCEPT

(it's a centos server thus the strange chain)

Regards

vendion · 2011-01-08 03:30:33

Well that was NFS not samba even though both fail. Isn't there away to have iptables allow all local traffic on the LAN? No need to really filter my own traffic I'm sure I can trust myself enough. XP In anycase if that is not possible then I will open the the ports up manually.

Damnshock · 2011-01-08 11:33:53

vendion wrote:

Well that was NFS not samba even though both fail. Isn't there away to have iptables allow all local traffic on the LAN? No need to really filter my own traffic I'm sure I can trust myself enough. XP In anycase if that is not possible then I will open the the ports up manually.

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -j ACCEPT

Should do the trick.

However, I encourage you not to be so trustworthy. You might trust yourself but... what if someone breaks into your wifi? or if a virus gets into a windows machine? or a trojan? or... you get it, right?

The correct behaveour (can someone spell this for me correctly please?) for a firewall is to block *everything* by default. From then on, allow whatever you need to

Damnshock

fukawi2 · 2011-01-09 12:27:21

Damnshock wrote:

The correct behaveour (can someone spell this for me correctly please?) for a firewall is to block *everything* by default. From then on, allow whatever you need to

Yes -- the holes should be as small as possible. In this example, you ideally want a hole to allow *only* CIFS and NFS traffic from *only* the hosts that need to use it, rather than allowing everything from all local machines.

vendion · 2011-01-10 05:53:16

(I thought I replied to this tread already...)

Well I don't have wifi, atleast not one that I keep turned off (usually log into the router and turn off the wireless when I don't need it). I also don't have a widows box so I don't have to worry there.

I do agree that a firewall should block as much as possible, only have ports that are absolutely needed open but in my case this is a bit overkill.

In any case for some reason allowing all LAN traffic with

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -j ACCEPT

doesn't do the trick (See Iptables output in my OP) before posting I tried adding a rule that accepted everything when its source is from my LAN. I already added rules for each port needed for NFS and Samba and that does seem to be working so that is fine with me.

fukawi2 · 2011-01-10 07:16:57

Your original rules had the ACCEPT for your local network *after* the unconditional DROP rules, so the packets were never getting to the ACCEPT before being DROPPED. You would need to move the subnet ACCEPT up, or add it to the "TCP" chain.

vendion · 2011-01-10 14:28:41

Ok not being very good at Iptables, I'm lucky this is the only problem I have had with it , how would I move the rule up so that it would be before the drop rule?

fukawi2 · 2011-01-10 22:06:24

INSERT the rule at the very top:

iptables -I INPUT

INSERT the rule at line 3, pushing all others below it 'down' one position:

iptables -I INPUT 3

This would put it between these 2 rules:

    3   120 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
 2225  214K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Last edited by fukawi2 (2011-01-10 22:07:07)

YeTr2 · 2011-01-11 21:59:58

Edit your /etc/iptables/iptables.rules file after running /etc/init.d/iptables save

Since you are dropping the packets you have not specified to accept by default, you could just remove the reject lines. Frivolous rules don't make for fast iptables.

The syntax of this file should be pretty easy to follow. After making your changes, you can use /etc/init.d/iptables restart, or iptables-restore /etc/iptables/iptables.rules

You could probably get rid of the TCP/UDP chains if you use -m multiport
Also, -m state --state has be depricated in favor of -m conntrack --ctstate
If you are going to allow ping from the world, you might want to put a rate limit on it. -m limit --limit 5/s

I am on freenode if you have any other questions.

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

-A POSTROUTING -o ppp0 -j MASQUERADE
-A PREROUTING -i ppp0 -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 6112 -j DNAT --to-destination 10.21.1.1
-A PREROUTING -i ppp0 -p udp -m conntrack --ctstate NEW -m udp -m multiport --dports 6112 -j DNAT --to-destination 10.21.1.1
-A PREROUTING -i ppp0 -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 8088 -j DNAT --to-destination 10.150.1.1
-A PREROUTING -i ppp0 -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 40022,46881,65100:65300 -j DNAT --to-destination 10.150.1.2
-A PREROUTING -i ppp0 -p udp -m conntrack --ctstate NEW -m udp -m multiport --dports 46881 -j DNAT --to-destination 10.150.1.2

COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i ppp0 -p icmp -m limit --limit 5/s -j ACCEPT
-A INPUT -i ppp0 -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 20:22,80,113,5901:5902,8080,9997,36890,49300:49500 -j ACCEPT
-A INPUT -i ppp0 -p udp -m conntrack --ctstate NEW -m udp -m multiport --dports 123,517:518 -j ACCEPT

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -d 10.0.0.0/8 -i ppp0 -j ACCEPT
-A FORWARD -s 10.0.0.0/8 -i eth0 -j ACCEPT
-A FORWARD -d 10.0.0.0/8 -i eth0 -j DROP
-A FORWARD -d 172.16.0.0/12 -i ppp0 -j ACCEPT
-A FORWARD -s 172.16.0.0/12 -i br0 -j ACCEPT
-A FORWARD -d 172.16.0.0/12 -i br0 -j DROP
-A FORWARD -d 10.0.0.0/8 -i br0 -j ACCEPT
-A FORWARD -d 172.16.0.0/12 -i eth0 -j ACCEPT

COMMIT

vendion · 2011-01-21 04:49:59

Thank you everyone for the help, everything is now working the way I want it to and I also took YeTr2's warning about -m state --state and converted my ruleset over to the new syntax.

fukawi2 · 2011-01-21 23:42:44

YeTr2 wrote:

Also, -m state --state has be depricated in favor of -m conntrack --ctstate

Google isn't giving me anything for that... Can you link me to a reference showing that the STATE module is depreciated?

Arch Linux

#1 2011-01-07 20:37:35

[Solved] Allowing local traffic through Iptables

#2 2011-01-07 22:08:41

Re: [Solved] Allowing local traffic through Iptables

#3 2011-01-07 22:18:27

Re: [Solved] Allowing local traffic through Iptables

#4 2011-01-08 03:30:33

Re: [Solved] Allowing local traffic through Iptables

#5 2011-01-08 11:33:53

Re: [Solved] Allowing local traffic through Iptables

#6 2011-01-09 12:27:21

Re: [Solved] Allowing local traffic through Iptables

#7 2011-01-10 05:53:16

Re: [Solved] Allowing local traffic through Iptables

#8 2011-01-10 07:16:57

Re: [Solved] Allowing local traffic through Iptables

#9 2011-01-10 14:28:41

Re: [Solved] Allowing local traffic through Iptables

#10 2011-01-10 22:06:24

Re: [Solved] Allowing local traffic through Iptables

#11 2011-01-11 21:59:58

Re: [Solved] Allowing local traffic through Iptables

#12 2011-01-21 04:49:59

Re: [Solved] Allowing local traffic through Iptables

#13 2011-01-21 23:42:44

Re: [Solved] Allowing local traffic through Iptables

Board footer