IPSec VPN with overlapping networks

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

IPSec VPN with overlapping networks

L2 Linker

To begin with I know the document Configuring IPSec VPN between overlapping networks.

Due to my lack of experience still I am not able to understand how I should create the NAT rules.

My objective is to configure the IPSec tunnel only on "my" side - one that will be accessed and should allow access to some servers in the network. 


Below I put some aqnonymised configuration info: 

  IKE Gateway




IKEv1 only mode

Address type


Local IP Address


Peer IP Address


Exchange mode


IPSec Tunnel Proxy IDs



Local (NAT 1:1 – original subnet )



The overlapping network addresses are

I have to create a NAT rule to show them to the accessing partner as network.


I would be grateful if someone could tell me how to create this NAT rule with static translation.


Thank You a LOT! 🙂

1 accepted solution

Accepted Solutions

L2 Linker

Below is the configuration that finally worked.


Static Route







Security rules


View solution in original post


L6 Presenter

Let's say partners want to access server at Chose an IP you will use for NAT, let's say it's (though any from that network would do).

All you need is a static destination NAT: source, destination, Destination Address Translation (with apropriate zones).


And also you will need a firewall rule to allow access with pre-NAT IP address and post-NAT destination zone.



I would like a rule that will translate any address in into a coresponding address in (>,> etc).

Can it bo done?

@Filip_Fronczak wrote:

I would like a rule that will translate any address in into a coresponding address in (>,> etc).

Can it bo done?

Yes, this is possible.

  • Destination address object:
  • Destination translation address object:

Is this enough or should there be something more?

Do I need on my side a NAT rule to translate the source too or a rule in the other direction?

Sorry for asking basic questions...


to [ LAN_Servers ]; from [ IPSec_xxx ]; source [ any ]; destination [ ]; service any; disabled no; destination-translation

Ignore my last post ... 

The NAT rule shoild look like this

  • Original source:
  • Original destination:
  • Type: Static IP
  • Translated source:
  • Translated destination: none

And what about the other way?

Traffic from the oher side that wants to arrive to servers in our network -

Check the bi-directional checkbox

So, it's this, right?


to [ IPSec_xxx ]; from [ LAN_Servers ]; source [ ]; destination [ ]; source-translation
bi-directional yes; translated-address;

Yes, looks correct.

Something is not right.


The phase-2 config on the connecting party is like this:


config vpn ipsec phase2-interface

    edit "VPN"

        set phase1name "VPN"

        set proposal aes256-sha256

        set dhgrp 14

        set keylifeseconds 3600

        set src-subnet

        set dst-subnet




The tunnel is established but they are not able to ping servers on our side.

I do not see any traffic even in the "Session Browser".

Assuming you log everything; untill you don't see a packet arriving from their side it means they are not sending it correctly.

You can also try sending traffic towards them.

Fist I would suggest you to disable the bi-directional for the source NAT and configure manually destination NAT. The main reason for that is - What does the Bi-directional NAT Feature Provide? My phisosofy is to enable bi-directional only for static NAT going to public. NATing for VPN could be little bit tricky. So I would suggest the following:


## Source NAT

IPSecVPN_xxx-1 {
  to [ IPSec_xxx ]; 
  from [ LAN_Servers ];  
  source [ ]; 
  destination [ ]; 
  source-translation {
    static-ip {
      bi-directional no; translated-address;

#### Destination NAT

IPSecVPN_xxx-2 {
 to [ Untrust ] 
 from [ IPSec_xxx] 
 source [ ] 
 destination [ ] 
 destination-translation {

 Note: that the to zone in your destination NAT should  be zone based on your routing table for If you don't have route for such network, traffic will be routed with default route to outside (or your what ever default is related). if you have route matching this network (for example you need to put the zone following this route)



	• NAT rule must be configured with pre-NAT zones (zones matching the addresses before the NAT)
	• Security rule must be configured with pre-NAT addresses, but post-NAT zones


Having the bidirectional enabled should work indeed, so if the traffic is failing I would suggest:
- Check the rule on the Fortigate at the other end
- Check the routing on the Fortigate at the other end
- Check if encrypted packets are increasing on the Fortigate

- Check for decrypted packets on your end
- As per revious comment - check if you can send traffic
- Check the log to confirm the NAT is applied
- Check for encrypted packets at your end and decrypted packets at Forti end

I am still stuck here. There is not much I can check on the other side. They say that the traffic is entering the tunnel.

I do not see any traffic on my side.

In vRouter I have a static route for directing it to the tunnel.

Should I have anything more there?

Go to Network > IPSec Tunnels

In Status column of the tunnel you have "Tunnel Info"

Click on it.

While they ping does Pkt Decap counter increase?


If yes then you are receiving packets.


Have you overrided last 2 intrazone-default and interzone-default rules to log?

If yes do you see any sessions in Monitor > Traffic ?



Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011
  • 1 accepted solution
  • 23 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!