Hi guys,
Using the 2002 HOWTO as inspiration, I decided that
four rules as a starting point
(there were others but I don't think they
are relevant -- keep reading)
would be nice to allow a machine of mine to be able to
initiate access (things like NFS, telnet, whatever) to other
servers and yet protect itself from being probed by
other machines on the network.
I'm on Solaris 10 11/06 using the built in ipfilter ...
pass out quick on bge1 proto udp from 199.22.33.5 to any keep state
pass out quick on bge1 proto tcp from 199.22.33.5 to any keep state
block in log from any to any
block out log from any to any
These actually worked just fine ... except when they didn't :-)
The problem is NOT ipfilter's fault.
I issue the mount command to do an NFS mount of a remote filesystem.
The remote server is running IPMP - each of the two NIC's
on the remote server has a test IP address
(deprecated, non-failover) and an active/usable IP address.
My mount command specifies one of the two active IP addresses
By snoop'ing my interface I see my machine send off a
PORTMAP C GETPORT ... packet to
the IP address I specified but (sometimes) the
remote NFS server decides to reply using its alternate IP
address which means that the packet is not seen as being
part of the conversation I initiated and so is dropped.
Any ideas that would allow me to continue to benefit from
the elegance of the 'keep state' lines above?
If it were possible to tell ipfilter (in a config file)
to treat a set of addresses as one entity with regards to
state then the problem would be solved.
In other words ...
- my machine sends a packet to X and this is noted
in the state table so (in the case of UDP) a packet
sent back to me from X will be allowed (in the next
60 seconds or whatever)
- remote machine responds but uses IP address Y
- ipfilter checks its "multipath aware table" that
says X and Y are really the same server and
so lets the packet from Y through just as if it
had come from X.
I know that in a non-ipmp environment this behavior would be
awful but here such a lookup table seems somewhat reasonable.
Thoughts?
Cheers,
Chris
