Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Fabien_34
New Contributor

Site-to-site IPsec VPN with overlapping subnets

Hello,

I am trying to setup site-to-site IPSec tunnels with two customers. Problem : they use the same subnet (common problem when establishing VPN tunnels). Diagram :

 

 

The configuration related to the customer Y tunnel :

 

Phase 1 :

 

config vpn ipsec phase1-interface edit "VPN_Y" set interface "VPN_INTERCO-OUT" set local-gw 46.235.xxx.xxx set peertype any set proposal aes128-sha1 3des-sha1 set comments "C00000843" set dhgrp 2 set remote-gw 46.235.yyy.yyy set psksecret ENC 22Qlkt[...]== next end

 

Phase 2 :

 

config vpn ipsec phase2-interface edit "VPN_Y" set phase1name "VPN_Y" set proposal aes128-sha1 3des-sha256 set dhgrp 2 set keylifeseconds 3600 set src-subnet 10.240.250.8 255.255.255.255 set dst-subnet 10.93.1.0 255.255.255.0 next end

 

NAT source :

 

config firewall ippool edit "NAT_SOURCE_VPN_Y" set startip 10.240.250.8 set endip 10.240.250.8 next end

 

NAT destination :

 

config firewall vip edit "NAT_DEST_Y_LAN" set uuid d23e818a-4ee1-51e8-9896-d94d9ae7ad2b set extip 10.129.7.1-10.129.7.254 set extintf "VPN_INTERCO-IN" set mappedip "10.93.1.1-10.93.1.254" next end

 

Static routes :

 

config router static edit 21 set dst 10.93.1.0 255.255.255.0 set distance 5 set device "VPN_Y" set comment "NET_Y_LAN" next end

 

Firewall policy :

 

config firewall policy edit 13 set name "VPN_Y" set uuid 31e63b7a-47ce-51e8-cf55-ad237dab5cbf set srcintf "VPN_INTERCO-IN" set dstintf "VPN_Y" set srcaddr "GRP_NET _MGT" set dstaddr "NAT_DEST_Y_LAN" set action accept set schedule "always" set service "GRP_ADMIN" set logtraffic all set nat enable set ippool enable set poolname "NAT_SOURCE_VPN_Y" next end

 

The configuration related to the customer Z tunnel :

 

Phase 1 :

 

config vpn ipsec phase1-interface edit "VPN-Z" set interface "VPN_INTERCO-OUT" set local-gw 46.235.xxx.xxx set peertype any set proposal aes128-sha1 3des-sha1 set dhgrp 2 set remote-gw 46.235.zzz.zzz set psksecret ENC 0ZmB1d[...]== next end

 

Phase 2 :

 

config vpn ipsec phase2-interface edit "VPN-Z" set phase1name "VPN-Z" set proposal aes128-sha1 3des-sha1 set dhgrp 2 set keylifeseconds 3600 set src-subnet 10.240.250.100 255.255.255.255 set dst-subnet 10.93.1.0 255.255.255.0 next end

 

NAT source :

 

config firewall ippool edit "NAT_SOURCE_VPN_Z" set startip 10.240.250.100 set endip 10.240.250.100 next end

 

NAT destination :

 

config firewall vip edit "NAT_DEST_Z_LAN" set uuid d7f36d5c-69a3-51e8-db84-0f401ccfe465 set extip 10.129.100.1-10.129.100.254 set extintf "VPN_INTERCO-IN" set mappedip "10.93.1.1-10.93.1.254" next end

 

Static routes :

 

config router static edit 22 set dst 10.93.1.0 255.255.255.0 set device "VPN-Z" set comment "VPN-Z" next end

 

Firewall policy :

 

config firewall policy edit 15 set name "VPN-Z" set uuid b26c4fc6-69a4-51e8-cfbd-416ac9af4bfe set srcintf "VPN_INTERCO-IN" set dstintf "VPN-Z" set srcaddr "all" set dstaddr "NAT_DEST_Z_LAN" set action accept set schedule "always" set service "ALL" set logtraffic all set nat enable set ippool enable set poolname "NAT_SOURCE_VPN_Z" next end

 

The customer Y tunnel is up and running.

 

Tunnel Z is down (I do not have an admin account on this firewall, so no CLI logs - VPN Events says that phase 1 is ok, nothing about the phase 2)

 

Some thoughts : - Destination network of the two routes (tunnel Y and Z) are the same, this may be the cause of the problem - The Fortinet cookbook Site-to-site IPsec VPN with overlapping subnets indicate a route with the external network ("NAT") as destination. I tried this, but the Y tunnel is not working with this route. I have to configure the mapped ("real") network as destination. I do not understand why it does not work as the routing is done after the destination NAT (see packet flow diagram below - source). - I thought about using policy-based tunnel but the source NAT option is not available if the "IPsec" action is selected (source NAT is possible only with the Accpet et Learn options) - I also thought about using policy-basded routing but it looks impossible to me because the source NAT is done after the routing

 

Any help you can give will be greatly appreciated...

 

12 REPLIES 12
rjohnsjr

ericli wrote:

Fabien_34 wrote:

Hello emnoc, I forgot to mention one important point: the two remote firewalls are very basic (VMWare NSX Edge). They can not do nay NAT (source or destination) for tunneled traffic. The source NAT and the destination NAT have to be done on the Fortinet. And I have accomplished this using IP Pool (source NAT) and VIP (destination NAT). The only remlaining problem is with the two routes : is there a way of using the external network instead of the mapped network as destination?

So you need two interfaces to build VPN going to two customers. On two VPN interfaces, you can do NAT to convert two same subnets from two different interfaces to two different subnets.

I have this same exact scenario / issue.  I've tried using two separate VPN interfaces and configured NAT about 10 different ways with no success.  Can you provide clarification how NAT should be applied?  Again - the issue is I cannot NAT at the remote sites and routing the VIP mapped network to the VPN interface won't work. If I route the external or overlapping network, it does, but it breaks routing for the other remote site.

sw2090
SuperUser
SuperUser

Just because there was annother thread about this in this forum ;)

There is an official document on that issue which is to be found here: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33872&sliceId=1...

 

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
WalterW
New Contributor

Was there any solution for this? We have exact the same scenario - in our case it is even worse because we cannot use VDOMs on our end (otherwise it would've been possible using VRFs and another VDOM).

 

The key feature to make a scenario like this working would be being able to use the "external" ip address (before DNAT from VIP is applied) in the policy routing as a matching criteria. This way it would be possible to differentiate to which tunnel the packet needs to get routed.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors