LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   NFS routing out wrong Interface (http://www.linuxquestions.org/questions/linux-networking-3/nfs-routing-out-wrong-interface-4175447551/)

jkaidor 01-28-2013 10:13 AM

NFS routing out wrong Interface
 
Hello,

I'm trying to mount a remote NFS volume from my Slackware 13.1(IIRC) server. No matter what I do, it fails with "Operation Not Permitted" ( just *what* does that mean *exactly*, anyway? ). After tearing my hair for over it for a few hours, I
tried looking at the syslog output while attempting to mount. There I saw complaints to the effect that localnet addresses were being put out on the external interface.

These error messages were being produced by my very own super-paranoid firewall script ( which I adapted from David Ranch's TrinityOS work ). The firewall not only filters incoming packets, but also outgoing ones. There are specific rejections for local packets ( 10.*.*.*, 192.168.*.*, 172.168.*.* - all decoded to the appropriate # of bits ) going out the "real Internet" interface.

I just turned off the firewall, and the mount worked. So the problem is the firewall. Well, not really. Why on earth is the system trying to pump a 10-net
address out the external interface, anyway? BTW, the mount continues to work when I turn the firewall back on. So there is a workaround - I could write a script to
turn the firewall off, do the mounts, and turn it back on again. YUCK!

Anybody have a clue as to where to look? The Linux kernel is version 2.6.37.6.
Here's the output of netstat -r:

-------------- snip -------------------
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.120.200.2 * 255.255.255.255 UH 0 0 0 tun0
10.120.200.0 10.120.200.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 10.120.102.220 255.255.255.0 UG 0 0 0 eth0
69.12.159.0 * 255.255.255.0 U 0 0 0 eth1
10.120.102.0 * 255.255.255.0 U 0 0 0 eth0
10.100.0.0 10.120.200.2 255.255.0.0 UG 0 0 0 tun0
loopback * 255.0.0.0 U 0 0 0 lo
69.0.0.0 * 255.0.0.0 U 0 0 0 eth1
default 69-12-159-1.dsl 0.0.0.0 UG 0 0 0 eth1
-------------- endsnip ----------------
The remote NFS is a dlink DNS323 running fonz fun_plug and the kernel-level nfsd.
I used to IP address of the DNS323 in my mount command to preclude any DNS
foolishness:
mount -t nfs 10.120.102.43:/mnt/HD_a4 /mnt/dns323/HD_a4

If I didn't know better, I'd suspect a kernel routing bug. But I *do* know better. I know that the Linux kernel networking stack is one of the most robust pieces of software in the world. I once thought I had found a bug there - I peppered the stack with printk's, and traced it to ---- a bug in my Windows machine having to do with crappy VPN software that my company had provided.

The plot sickens. I just tried mounting the second drive on the DNS323 - WITH the firewall still enabled - and it WORKED. Without me fixing anything! Gaak!

- Jerry Kaidor

kbp 01-28-2013 05:06 PM

That fact that it keeps working after starting the firewall may indicate that you're matching a
Code:

... -m state --state RELATED,ESTABLISHED ..
rule with your existing connection and that initial connections (SYN) are being blocked by your rules.

jkaidor 01-29-2013 08:00 AM

Quote:

Originally Posted by kbp (Post 4879354)
That fact that it keeps working after starting the firewall may indicate that you're matching a
Code:

... -m state --state RELATED,ESTABLISHED ..
rule with your existing connection and that initial connections (SYN) are being blocked by your rules.

Here is the exact area that it's failing ( when it fails ):

------------- snip ------------------
# used in the OUTPUT chain

firewall_reject_local_dests_table()
{
iptables -F reject_local_dests
iptables -N reject_local_dests
iptables -A reject_local_dests -d 10.0.0.0/8 -j LOG --log-prefix "REJECT_LOCAL_DESTS0: "
iptables -A reject_local_dests -d 10.0.0.0/8 -j REJECT

iptables -A reject_local_dests -d 192.168.0.0/16 -j LOG --log-prefix "REJECT_LOCAL_DESTS1: "
iptables -A reject_local_dests -d 192.168.0.0/16 -j REJECT

iptables -A reject_local_dests -d 172.168.0.0/12 -j LOG --log-prefix "REJECT_LOCAL_DESTS2: "
iptables -A reject_local_dests -d 172.168.0.0/12 -j REJECT
iptables -A reject_local_dests -j RETURN
}
--------------- endsnip ---------------------------


... This table that is called thusly:
#----------------------------
# Specific OUTPUT rejections
#----------------------------
# Reject outgoing traffic to the INTERNAL net from the REMOTE interface,
# stuffed routing; deny & log
iptables -A OUTPUT -o $EXTIF -j reject_local_dests

...So for all packets going to the EXTERNAL interface, the reject_local_dests table is activated.

Inside that table, we already know that it's an OUTPUT packet at the EXTERNAL interface. So the only thing that's being checked is the
IP address. It doesn't care about the protocol, the destination or source port or the TCP state.

If I decide to pursue this, I'll be looking at the source to mount.nfs. I suspect that there may be some low level API to the kernel networking stack
that allows arbitrary packets to be output from any interface, and that mount.nfs is using this for some reason that I don't understand - not really being
familiar with the NFS protocol.

- Jerry


All times are GMT -5. The time now is 11:05 PM.