Skip to main content
sanket1611
sanket1611
New Member
May 15, 2019
Solved

DNAT before IPSEC VPN

  • May 15, 2019
  • 6 replies
  • 14297 views

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.

    Best answer by ede_pfau

    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.

    6 replies

    ede_pfau
    SuperUser
    ede_pfauAnswer
    SuperUser
    May 15, 2019

    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
    sanket1611Author
    New Member
    May 21, 2019

    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
    sanket1611Author
    New Member
    May 21, 2019

    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.

     

     

    Terms & ConditionsAccessibility statement