DNAT inside Domain based VPN

[Ryan_Ryan]

Hi all,

sk116097 tells us if we need to dnat inside a vpn we must use route based and not domain based, I am wondering if that is really true or if there is a workaround to achieve this?

My setup is identical to the one pictured in the sk, I have added both the pre and post NAT address to the satellite encryption domain, the interesting thing is, my logs say the traffic is encrypted and the destination IP is natted which makes me hopefull, however the traffic doesn't actually make it through the tunnel. The remote end doesn't see it using a packet capture and the local checkpoint gateway only shows little "i" in fwmonitor.

I am doing the same traffic in reverse,  in that case hide natting the source IP through the tunnel and that does work fine which I suspect means my setup is correct and it just wont work -  But I really hope there is some other solution than a vti.

Flow #1 - doesnt work
pre nat - src: 10.0.0.100 dst: 10.0.0.10
post nat - src: 10.0.0.100 dst: 30.0.0.1(s)

Flow #2 - does work
pre nat - src: 30.0.0.1 dst: 10.0.0.100
post nat - src: 10.0.0.10(H) dst: 10.0.0.10

gateway a encryption domain: local-10.0.0.100/32 remote-30.0.0.1/32,10.0.0.10/32
gateway b encryption domain: local-30.0.0.1/32 remote-10.0.0.100/32

I have tried adding 10.0.0.10/32 to gateway b local domain but it didn't make a difference

[PhoneBoy]

It’s actually in the SK itself: “In order to trigger an encryption decision in domain-based VPN, the source and destination must be included in the respective encryption domains and only in them.”
That suggests you should be able to add the DNAT IP into the Encryption Domain for the remote end.
I assume the remote end would need to make a similar configuration change.

Otherwise, this seems like it’s operating as designed.

[Ryan_Ryan]

thanks, I was struggling to read that SK, it was written rather oddly, I am not sure what they mean by "and only in them" essentially I did try that already, on the vpn peer I included the post and pre nat IP and the same on the Checkpoint, the peer is a Cisco so I could tell easily that there were no hits on the SA with the NAt IP.

I am wondering if they mean that I should not have the real IP in the encryption domain, only the NAT IP? the real IP is part of a subnet so bit harder to exclude that to test it.  

[PhoneBoy]

Did you make the same change on the local definition of the remote encryption domain?
You should not need to exclude the "real" IP, only add the NAT one.

[Ryan_Ryan]

yes I did, the NAT Ip (10.0.0.10) was added to the remote gateways local side, I also have the real IP. It did establish an SA but no packets matching.

[PhoneBoy · Accepted solution]

Packets routed via a Domain-Based VPN bypass the functions that perform DNAT.
Which means your only option to make this work is a route-based VPN.

[Ryan_Ryan]

ok thank you that settles it then!