From: Todd Pytel (tppytelsophrosune.org)
Date: Tue Aug 03 2004 - 13:00:22 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This keeps getting stranger. Someone reminded me off-list to disable PF
on the router, which I hadn't earlier (yes, I realize I should have).
Sure enough, it seems that PF is involved in this - disabling it solves
the problem. But I'll be damned if I can see why. My pf.conf follows -
the only bits I've snipped are the interface and variable definitions at
the top and a bunch of external interface rules at the bottom (again,
none of this traffic is passing through the external interface).

For those just tuning in, the short form of the problem is this - client
workstations (on the $priv segment below) fail an SMB mount at bootup
roughly %50 of the time with a "No route to host" error. Indeed, the
router does send an ICMP Host Unreachable message to the workstation,
even though IP connections to the server's IP (on the $pub segment
below) succeeded just a split-second before and will succeed again just
a few seconds later. The router does not ARP for the server before
sending the ICMP, and the server already had an ARP table entry before
the problematic exchange occurs. Also, for whatever reason, the same SMB
connection always completes successfully if started by hand (mount -a -t
smbfs) after the workstation has finished booting. Disabling PF solves
the problem, but I can't see where the conflict is.

pf.conf:

######################################################################
# Global settings

set block-policy drop

scrub in on $ext all fragment reassemble
scrub in on $pub proto udp fragment reassemble

######################################################################
# NAT settings

# Map the private network to an unused public IP
nat on $ext from $priv:network to any -> $natip

# Rewrite packets from this machine to get a routable address
nat on $ext from ($ext) to any -> $gateway

# Redirect Bittorrent connections to the desktop
rdr on $ext proto tcp from any to $natip port 6881:6889 -> $desktop

######################################################################
# Default policies

# Default block and log incoming traffic
block in log on $ext

# Default block outgoing traffic
block out on $ext

# Default pass on loopback
pass quick on lo0

# Block network and broadcast addresses in either direction on the
# external interface
block quick on $ext from any to $broadcast
block quick on $ext from any to $network

######################################################################
# Internal policies

# We keep state on $ext and $pub, so everything can pass on $priv
pass quick on $priv

# We'll filter outgoing traffic on the external interface, so default
# pass anything to or from the public machines...
pass in on $pub
pass out on $pub

# ...but the public machines cannot initiate connections to the
# private network
block in log on $pub from any to $natnet

# Uncomment the following if we need a nameserver in the lab
pass in on $pub proto tcp from $server to $natnet port = 53 \
                                flags S/SAFR keep state
pass in on $pub proto udp from $server to $natnet port = 53 keep state

# We need state table entries to allow private machines to talk to
# public ones - external connections already have this
pass out on $pub from $natnet to any keep state

# Windows file sharing and communication between the server and
# private network
pass in on $pub proto tcp from $server to $natnet port = 139 \
                                flags S/SAFR keep state
pass in on $pub proto tcp from $server to $natnet port = 445 \
                                flags S/SAFR keep state

# Pass FTP controls to the desktop for Dreamweaver
pass in on $pub proto tcp from $server port 21 to $desktop keep state

######################################################################

Now, the only thing that looks even vaguely suspicious to me is the
scrub on udp over $pub (placed there to solve some Linux NFS problems).
But disabling that line has no effect. Everything else looks harmless.

Also, I should have confirmed before - this is the generic 3.4 kernel.

--
Todd Pytel

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]