S2S IPSEC VPN using NAT

[Matlu]

Hello, world.

I currently have an IPsec VPN in the process of deployment, but we have a question.

The intention is that once the tunnel is built, the remote peer will reach our server, pointing to a NAT IP.

Real SRV IP: 10.7.5.10
IP NAT: 192.168.50.10
Service: 443

Destination Segment: 172.16.20.0/24

Could you comment me, what would be the correct NAT structure that we should create in the SmartConsole, please.

In addition to that, if I work with a NAT IP on my side, is it necessary that the NAT IP is "put" in my VPN DOMAIN!
Or in the VPN DOMAIN, is it enough that my Real IP of the server is there?

Thank you for your comments.

Regards.

[genisis__]

I believe you may need to add both the real subnet (10.7.5.x) and the NAT subnet (192.168.50.10) to the local encryption domain.
The remote vpn domain (172.16.20.x) would be assigned to the remote VPN device object; both the local and remote GWs would be configured in a VPN community and this community would be assigned to the firewall ruleset. 

Your outbound rule would contain the real IP as the source.
The remote end would have our source as the NAT IP.

If you do a fw ctl chain, you will see the inbound and outbound chains. I believe when leaving the firewall it goes through the firewall ruleset, then NAT and then through the tunnel.

Been a while since I did any tunnels with NAT so you will need to check it.

[the_rock]

Hey bro. I think what @genisis__ said makes sense.

Andy

[the_rock]

Also bro, make sure below option inside VPN community is NOT checked.

Andy

 

[genisis__]

I did not mention that as this is enabled by default, but yes this is required.

[Matlu]

Hello,

So, I understand that the security policy, at the moment of creating it, in the ORIGIN field, must go my REAL IP, correct?

In the VPN DOMAIN, from my side (CP), I must enter both the REAL IP and the NAT IP ????

If this is not clear 😕

If I do this, to enter both IPs, both the real IP and the NAT IP, it does not generate any conflict?

In this case, I should create a DNAT, right, based on my scenario, of course, in which I want them to reach me, pointing to a fake IP. 

Greetings.

[the_rock]

Based on my experience and what TAC suggested before, I would say yes, both real and natted IP in the enc domain.

Andy

[genisis__]

So, I understand that the security policy, at the moment of creating it, in the ORIGIN field, must go my REAL IP, correct?

- I believe so, assuming the local GW is the initiator.

In the VPN DOMAIN, from my side (CP), I must enter both the REAL IP and the NAT IP ????

- Yes I believe so, because you are ensuring both subnets are tagged to the local gateway for VPN decisions, you can of course test this as well.

If I do this, to enter both IPs, both the real IP and the NAT IP, it does not generate any conflict?

- Not in the scenario we are talking about.

In this case, I should create a DNAT, right, based on my scenario, of course, in which I want them to reach me, pointing to a fake IP.

- No DNAT required as the destination IP is the 172.16.x address, which is not in your VPN domain (This should be added to the VPN Domain of the remote gateway object).   If you had to target a DNAT, I would say try to get the remote end to deal with this, it would make your side less complicated.

[PhoneBoy]

Your local encryption domain must include the client's real IPs.
This is because the local encryption domain is used to determine what IPs are "interesting" to the remote end of the VPN tunnel (and thus be encrypted).
The way the remote VPN gateway sees the traffic (i.e. the result of NAT) must also be included in the encryption domain as this is what the IPsec SAs will be negotiated using. 

[genisis__]

I don't think I've ever added a clients real IP into our local VPN domain, I've always added that to a VPN domain which is then assigned to the remote VPN device's object hence the local gateway knows its not part of its own domain, but it is part of VPN domain for a remote gateway.

[PhoneBoy]

This is definitely required for Domain-Based VPNs.
For Route-Based VPNs, I don't believe it is required.