Hi, everybody: First -- thanks to everyone who tried to help me out on this one. It is most appreciated. I apologise if my questions or responses rubbed anyone the wrong way. It wasn't intended.
I want to recap the situation because I think that, indeed, what I want to do can't be done. I have a security association between a carp alias address (call it $alias) and a private IP address (call it $remote_private_IP) at the remote end. It is in tunnel mode. The ipsec man page says: > 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. This would explain why, when I ping -I from the carp alias on the IPsec gateway itself to the remote private IP, I get replies. If I add a binat rule in pf.conf: binat pass log on $enc_if from $internal_host to any -> $alias Then the ping -I stops working on the IPsec gateway. This is true even if I add a static route, like so: route add $remote_private_IP $alias Going by the contents of man 4 ipsec, this just isn't going to work. The IPsec flow matching is happening before NAT, so it has to come from $alias before it even gets processed by pf. This means that it will be necessary to do the required NAT on other hardware -- this is probably advisable in the long run, anyway, as I anticipate more such requests in the future. Thanks, -Stephen-
