Quote:
Originally Posted by kbp
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
