Cisco Firewall Translation, RPC Portmapper, and NFS

I've posted before about problems using NFS with a Firewall which occur because of RPC. I think the correct way to solve the problem is to configure the NFS server so that RPC services like nlockmgr, rquotad, and mountd are hard coded. On a RedHat based system this comes down to uncommenting the following in /etc/sysconfig/nfs:

 RQUOTAD_PORT=875 
 LOCKD_TCPPORT=32803
 LOCKD_UDPPORT=32769
 MOUNTD_PORT=892
 STATD_PORT=662

and then configuring your firewall to allow only the above ports through in addition to RPC:tcp/udp 111 and NFS:tcp/udp 2049, for NFS.

Today I learned that if you are using a Cisco firewall it is possible to not do the above but to enable inspect rpc so that when port mapper tells the client to use random ports for services like nlockmgr, rquotad, and mountd, that the firewall will then dynamically open the same random port exclusively between the NFS client and NFS server. This surprised me as it seems odd to imagine a server asking the firewall to open a port because it wants to use it. What also surprised me is that for FWSM versions older than 3.2, this won't work if you use xlate-bypass. So, if you thought along the lines of "I don't need NAT, let's turn off xlates" and enabled xlate-bypass then you will break sunrpc. I am personally in favor of not using xlates nor sunrpc.

Freedom Box Foundation

I posted about Eben Moglen's Freedom in the Cloud Talk. There is now a Feedom Box Foundation with a kickstarter project.

RedHat Cloud Offerings: Update

I previously posted about RedHat Cloud Offerings and emphasized what my organization is lacking: Satellite, RHEV-M, and MRG Grid.

We're now running Satellite and will be registering all of our servers to use it. We've also been able to use Satellite alone to kickstart a VM on our KVM servers without touching the hypervisors. We're going to keep experimenting with Satellite and roll it into production very soon.

We're less interested in RHEV-H and RHEV-M since we are already happy with KVM running on RHEL and prefer to use our command line tools for management as opposed to the "vmware-like" RHEV-M GUI. We're also less interested in MRG Grid since HPC is not our focus.

We are interested in Deltacloud but in a development sense only. We don't expect it to be production-ready for a while. For now we're going to use a by-the-hour EC2 account with our development KVM cluster and see what it's like creating and migrating VMs between EC2 and our cluster (or private cloud (if you must)).

me, make, meet

I evolved a variation of the calendar scheduling described in me, make, meet when I was in college. Glad to see others have a similar system. Some people thought I was weird for scheduling so much of my day.

iptables state and cisco firewalls

RedHat's {G,T}UI allows one to easily run iptables to allow connections only on certain ports. So if you allowed only HTTPS the following rule would be added to /etc/sysconfig/iptables:

- -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

The above however is for NEW connections only. However, a rule like the following is also added by RedHat's tool which allows anything related to an existing state entry to pass:

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

This all seems reasonable but I'm having a problem where packets are in an INVALID state and are getting blocked by iptables (confirmed with an iptables log). The workaround that my colleague came up with is to drop state out of the equation by simply having:

- -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT

The same colleague also found a blog post on Cisco PIX mangled packets and iptables state tracking which offers are much more satisfying explanation. We're looking into this further.