DNAT before IPSEC VPN

[sanket1611]

Hello,

We have a requirement to create a simple IPSec VPN to another customer who is also using a Fortigate firewall at their end.

However, due to a conflict of subnets in our environment, I need to destination NAT their subnet before it hits the IPSec VPN. 

Is this even possible? I was of the view that the remote end would have to NAT their subnet that conflicts with our environment and provide us with a new subnet that we can use to route over IPSec VPN. However, the remote end customer is adamant that this should be done at our end.

So in other words, I need to do a DNAT before the traffic hits the IPSec VPN tunnel from our end.

Can someone please help with this?

Thanks.

[ede_pfau · Accepted solution]

You need to do both: destination NAT for traffic to the tunnel, and source NAT for traffic from the tunnel.

DNAT is done via VIP, SNAT by ip pool. But you can use VIPs for both.

You've got 2 policies in which you put the NAT into effect.

The egress policy needs a VIP as the destination address, attached to the tunnel interface. Don't use "port forwarding" in it. This way, reply traffic (from remote to your LAN) will be source NATted automatically.

The second policy (ingress) will have to source NAT the remote traffic, and will have to do DNAT to the reply traffic. So this will need a bit of trying out until you get it done (sorry, lack of time).

One last thought: you should NAT 1:1, say a /24 subnet to a /24 subnet. And the (virtual) NAT subnet needs to be known on your FGT, so install a route to it, pointing to the tunnel.

[ede_pfau · Accepted solution]

You need to do both: destination NAT for traffic to the tunnel, and source NAT for traffic from the tunnel.

DNAT is done via VIP, SNAT by ip pool. But you can use VIPs for both.

You've got 2 policies in which you put the NAT into effect.

The egress policy needs a VIP as the destination address, attached to the tunnel interface. Don't use "port forwarding" in it. This way, reply traffic (from remote to your LAN) will be source NATted automatically.

The second policy (ingress) will have to source NAT the remote traffic, and will have to do DNAT to the reply traffic. So this will need a bit of trying out until you get it done (sorry, lack of time).

One last thought: you should NAT 1:1, say a /24 subnet to a /24 subnet. And the (virtual) NAT subnet needs to be known on your FGT, so install a route to it, pointing to the tunnel.

[sanket1611]

Thank you for providing some good details there.

ede_pfau wrote:

The second policy (ingress) will have to source NAT the remote traffic, and will have to do DNAT to the reply traffic. So this will need a bit of trying out until you get it done (sorry, lack of time).

Although I did lose it a bit in above statement when you mentioned DNAT to reply traffic for second policy (ingress).

[sanket1611]

Further to this, if I may add, and I think it is important piece of the question that I should have stated earlier:

- We need to NAT since the original subnet at remote end is a Reserved subnet for our environment.

So, if I were to do DNAT at our end like is being suggested in above post, wouldn't it still mean that my Reserved subnet will effectively be blocked for use in future for the purpose it is reserved for?  I mean, say if the customer destination subnet across this VPN tunnel is 192.168.1.0/24 and if it is a Reserved subnet in our environment for internal use, would using DNAT like being suggested, keep the 192.168.1.0/24 available to us when we need in future? To me it seems that by doing DNAT at our end, we would still have to map new subnet that we decide to use (say 10.1.1.0/24) to our Reserved subnet (192.168.1.0/24) and hence the reserved subnet won't be available for future use.

Henceforth I thought the only way to do this if the customer at remote end does a NAT for their 192.168.1.0/24 subnet to another range (say 10.1.1.0/24 again), and inform us of what to route to via the VPN tunnel.

[ede_pfau · Accepted solution]

It's not so complicated.

On your side, you only operate with the 10.1.1 subnet. Every host address (like 10.1.1.222) is translated 1:1 into an address in 192.168.1 (like 192.168.1.222). That is, the remote address range is not visible on your side, and can therefore be used for other purposes.

You will have to learn new addresses for the remote hosts, or rather, your DNS.

OTOH, in order that routing on the remote side still be working, your source addresses need to be NATted as well. It might just happen that you use an address from 192.168.1, and that would be confused on the remote side with a local address (and thus not routed back into the tunnel).

So, the remote side will have to deal with, say, the 10.100.1 subnet if it addresses your LAN.

There is a write-up in the Knowledgebase (https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33872) which contains a WORD document with screenshots. This might help to visualize the setup.

Unfortunately, [strike]it contains a grave error in the setup of the second FGT (FG-311B). The VIP on this side must have an 'external IP' of 172.16.201.x, not 172.16.200.x (as this is used on the remote side).[/strike] I was too dumb to understand it properly...worked it through and it will work as documented.

I would strive to use subnet ranges for the 'virtual' subnets as distinct as can be, like for a VPN between a FG-40C and a FG-311B 172.16.40.x and 172.16.31.x, resp.

---------

about DNAT: a VIP not only exchanges the destination IP, but for reply traffic going into the other direction it automatically replaces the source address, so that the 'hidden' server behind the VIP really is hidden. That's what I meant.

[sanket1611]

Thank you very much for your detailed response again.

The Source IP at our end will be a Public IP so that shouldn't be a problem as far as source NAT requirements are concerned.

The rest of it, I will implement it tomorrow morning and let you know how I go, but seems clear to me now.

[Thanigai1980]

Hi Sanket,

Does it worked for you?

Thanks,

Thanigai.R