PIX | odd netmask on nat statement

This is the standard pre-CIDR behaviour.

Any bit in the mask that is 0 is allowed to vary from the base address. With 255.255.240.192, that would be the last four bits of the third octet (a range of 16), and the last 6 bits of the fourth octet (a range of 64). Or to put it another way, it is like a /20 except that the first two bits of the last octet must match the ones in the sample IP address.

I've seen people do something like this when they want to give some internal addressing structure but without the hastle of having multiple actual IP ranges (which would require a router.) For example, you might find that the local IP addresses have been constructed so that all the printers are in a group that matches the pattern that is -not- permitted.

On the PIX, you need to be a bit careful with IP masks that do not follow the traditional "classfull" (Class A/ Class B/ Class C) pattern: there are a couple of places where if you leave out the netmask from the statement, that it will figure out which IP class the address falls into and use the default mask for that class. In particular, "ip address pool" has this behaviour, which can present difficulties for VPNs. It wasn't until 6.3 that the PIX could send the netmask over the Cisco VPN client, so the PIX and the client could end up disagreeing.

Very cool approach :) ...

In 6.3(3), the "ip pool" command doesn't accept a mask whereas in 6.3(5) it does. Very strange.

Regards

fw