Hi: Hi folks -- remember me? I finally resolved my problem of doing NAT before IPsec by putting a second device on the internal network of a redundant CARP firewall.
Nevertheless -- I am facing an avalanche of VPN requests and a need to NAT them. The more traffic goes through this internal NAT device, the less the redundant firewall matters -- the NAT is another "single point of failure". I could do CARP NAT boxes, but you can see that the amount of equipment and complexity of the configuration is rapidly increasing. I remain convinced that it is best to do this on one piece of hardware. I think the suggestion of a patch to allow a sysctl parameter to change the processing order is a valuable one, and I am willing to put forward some development funds to help make it happen. Let's refer again to man 4 ipsec: > NAT can also be applied to enc# interfaces, but special care should be > taken because of the interactions between NAT and the IPsec flow match- > ing, especially on the packet output path. Inside the TCP/IP stack, > packets go through the following stages: > > UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF > UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF > > With IF being the real interface and UL/R the Upper Layer or Routing > code. The [X] stage on the output path represents the point where the > packet is matched against the IPsec flow database (SPD) to determine if > and how the packet has to be IPsec-processed. If, at this point, it is > determined that the packet should be IPsec-processed, it is processed by > the PF/NAT code. Unless PF drops the packet, it will then be IPsec-pro- > cessed, even if the packet has been modified by NAT. What I'd be looking for here is a sysctl parameter that would change the above to: > UL/R -> PF/NAT(enc0) -> [X] -> IPsec -> PF/NAT(IF) -> IF > UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF So -- again, I'd be willing to contribute a reasonable sum to development of such a patch, with the understanding that it would become part of the distribution in future. Cheers, -Stephen-
