Thanks for the replies guys. Fireman2005's reply (see down below) brings out the fundamental issue.
Solaris does indeed use the multiple interfaces in a seemingly random way (well, it really isn't random ... I'm sure there is a very logical approach but to the occasional telnet, ssh, scp, or NFS application it appears random :-). Carson pointed out that it might be a solaris bug for which a patch already exists. However, while there are indeed some references to bugs of this nature on sunsolve 1) we can't always control the remote servers that we interact with (in this particular case I have no admin rights to the NFS server) and 2) I know that IPMP, with non-deprecated (active) IP's on each interface, will try to spread the load across multiple interfaces and so it may not be a bug. I have seen scp's where all the "to" packets go in one interface of the remote server and all the "reply" packets come out the other interface of the remote server. Now, granted, I think that the source IP of the packets coming out the "other" interface should really be that of the interface on which the connection was initiated ... so maybe that is the bug piece ... but none of the sunsolve stuff I saw was this specific. In any event, the ability for ipfilter to have a "multipath lookup table" seems like a nice feature and a fairly simple solution. That said, I could certainly understand if Darren (or whomever) was tired of adding little features. Carson: yes, I believe the remote server is trying to provide maximum bandwidth by having > 1 active IP address. Fireman2005: Thanks for succinctly pointing out the real nature of the problem I was describing. Vincent: Thanks for the heads up on the problems you've had with the UDP keep state. Note that NFS was just one example of the problem. ------------------ Carson replied with: You really only want one active IP address (or are you trying to load-balance the network bandwidth?). That will solve your problem. You should also submit a bug report to Sun, but as I recall the "respond from a different IP address" bug is already fixed - is the server patched up? --------------- fireman2005 replied with: I think the underlying problem is that multi-home Solaris systems (typical NFS servers) kind of use interfaces at random, defeating all sorts of security principles. ---------------- > Vincent replied with:
One of the problems I've found it that UDP keep state doesn't work all that well for me. NFS and particularly AFS, across multiple platforms and OS versions just has weird issues. I gave up on it and removed keep state from all UDP rules. You should also do something about ICMP. [EMAIL PROTECTED] wrote: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
