#10 Add Resource NAT address not on PEP public network

[John A. Sullivan III]

We originally allowed the highly unusual case where someone could NAT a Resource to an address not on the PEP's public network but bound to a public interface, e.g., the PEP may be at 1.1.1.1/24 on eth1 but a Resource could NAT to 3.3.3.3 on eth1.

We then made it possible to bind multiple public IP addresses to the same interface in case the PEP used virtual networks on the same media. However, this now makes it impossible to know which network mask to use for an address not on any of the networks. For example, if we have 1.1.1.1/24 and 2.2.2.1/28 both bound to eth1 and we now try to NAT our resource to 3.3.3.3, what netmask should we use for the address binding, e.g., in Linux ip address add 3.3.3.3/24 dev eth1 or ip address add 3.3.3.3/28 dev eth1. Thus, we must temporarily disable the ability to NAT to an address no on a PEP public network.

The next release of ISCS after the version we are currently developing will handle networks independently of PEPs to allow multiple PEPs to connect to the same network. This will dramatically change the NAT logic but it should make it possible for us to restore this capability by associating the NAT with a network. We can then use that association to determine the network mask.