I've been working on the pf configuration for my home firewall (which
has a single static public IP address, hides half a dozen other systems
behind NAT, and is being upgraded to OpenBSD 4.2), and have come up with
some questions for which I can't find answers in the documentation.
(I've searched the mailing list archives and (re)read the 4.2 pf FAQ,
the 4.2 man pages for pf(4), bpf(4), ip(4), inet(3), netintro(4),
socket(2), route(4), connect(2), bind(2), ifconfig(8), ftp-proxy(8),
ftp(1), pf.conf(5) and the man page for the 4.2 package for ftpsesame.)
The pf FAQ states that for the 'urpf-failed' source "the source IP
address of the packet is looked up in the routing table. If the
outbound interface found in the routing table entry is the same as the
interface that the packet just came in on, then the uRPF check passes";
this is basically what I'd expect, but I haven't found confirmation of
it in any of the man pages. [Also, what happens if the interface found
by the lookup is not a hardware interface?]
This should mean that this rule
block drop in log quick from urpf-failed to any
would make this rule
block drop in log quick from no-route to any
redundant, and would also eliminate the need for all 'antispoof' rules.
Are these inferences correct?
'ftp-proxy' will handle FTP connections to external servers from the
systems behind the firewall, but I don't see any way to make it also
handle connections from the firewall itself. The best tool I've found
for that is 'ftpsesame' (in packages), despite the fact that it
apparently suffers from race conditions when setting up rules, but I
don't see any obvious way to configure it to only process the FTP
control connections which have not already been dealt with by ftp-proxy.
'ftpsesame' uses bpf (which apparently, but I haven't been able to
confirm this, sees inbound packets before pf does and sees outbound
packets after pf is finished with them) with, by default, a filter to
select only TCP packets directed to port 21. Since tags and other
metadata added by pf are apparently not available to the bpf filter, I
don't see any way of distinguishing between control connections from
systems behind the firewall that are being handled via ftp-proxy and
those originating from the firewall itself. If there's something I'm
missing, or if there's a better tool than ftpsesame to use, I'd love to
hear about it -- since I'd really like to make FTP 'just work'
everywhere.
I actually do have one idea about how to handle FTP, but it raises
another question for which I can't find an answer. I have a second
static IP address available which I could add as an alias on the
external interface (I've been planning to use it that way as a secondary
MX for spamd) and direct ftp-proxy to use that alias as its source
address -- so that ftpsesame could select only those connections from
the main address. But I'd need to control which of the two addresses
was used for each outbound connection since, while most of the resources
I use on the net don't care where a connection comes from, a few do.
This isn't a problem for anything behind the firewall (since nat / rdr /
binat rules specify the external address) and shouldn't be a problem for
incoming connections (since they will use the original destination
address as the source address for return traffic), but I can't find any
information about what source address is used by default on outgoing
connections when one or more aliases are present on the external
interface. Is there some way of marking one of the addresses assigned
to an interface as preferred, so that programs needing a source address
for a new connection on an interface will use it unless told to do
otherwise? I may be able to get by with just understanding which alias
will be chosen as the source address when a program uses INADDR_ANY, but
that doesn't seem to be documented either. I need to know how this is
designed to work rather than just how it appears to work at the moment,
since a 'solution' which might change when I upgrade (or even just
reboot) is not acceptable.
Thanks in advance for either direct answers or pointers to relevant bits
of documentation that I've missed.
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
