IPSec VPN with overlapping subnets

[NKL]

Hi all, I'm trying to connect two sites through IPSec VPN, that are using the same ip subnet (let's say 192.168.100.0/24) for their local LAN. Both sites a running a FortiOS 5.2.7. The goal is that devices on Site1 can communicate with devices on Site2, although their ip subnets overlap. I'm aware that there are both a Fortinet-doc (http://docs.fortinet.com/...erlapping-subnets.pdf) and a cookbook recipe (http://cookbook.fortinet....-overlapping-subnets/) for that. Unfortunately, both don't seem to work or match my requirement. As for the doc, at the beginning, it sounds like the solution to my problem. But only very late, in "Results", it is explained that Site1 and 2 will actively have to communicate with a mapped ip range. And the cookbook recipe does not even seem to be complete at all, that is VIPs being created but never used in the recipe. Has anyone a working solution to my requirement and is willing to share his/her config with me?

[ede_pfau]

hi,

I've read through the Cookbook recipe and it looks correct. Of course, you will have to create at least one policy from tunnel to LAN into which you insert the VIP as the destination address. No policy, no traffic. Seems to be so basic that Keith (the author) left it out.

Staying with the diagram in the recipe, yes, you communicate with the other LAN using the 'fake' addresses - how else? If you use 192.168.1.x you address a local host; if you use 10.21.101.x (same x!!) you address the remote host with the same (hence, overlapping) address. In the remote location you address 10.31.101.x to contact a remote host.

So, by using VIPs on both sides, you drop using the original address space (192.168.1.x) because it is ambiguous. The VIPs introduce new, distinct address spaces for both LANs. Configuring the local DNS will help your users a lot to cope with this.

[NKL]

I still feel like there is something missing:

If I understand correctly, the VIPs created in the cookbook have to be applied to the inbound policies for traffic leaving the tunnel in direction of the internal lan. So, what the VIPs are doing is translate a 10.x-address into a 192.x-address. I understand the concept.

But obviously, before that, there should have happened another translation from 192.x-address to 10.x-address. I believe, there has to be another set of VIPs for outbound traffic from internal lan to tunnel. How else would the "source" Fortigate know that it should "snag" traffic, that is directed to a 192.x-address that is not in its site, and should send it over the tunnel?

[ede_pfau]

If you address a remote host, you would use the translated 10.x address. The VIP should translate the traffic in the other direction automatically.

Care to try it?

[NKL]

ede_pfau wrote:

If you address a remote host, you would use the translated 10.x address.

And that's what we don't want. We want to address the remote hosts 192.x-address.

I managed to do it for one remote host:

On the "source" Fortigate, this requires outbound VIP (internal lan to tunnel), translating the remote hosts 192.x-address to a 10.0.3.x-address. Plus on the "source" Fortigate, this communication needs to be "NAT" by an IP pool, translating the source clients 192.x-address to a 10.0.2.x-address.

On the "destination" FortiGate, an inbound VIP (tunnel to internal lan) is translating the 10.0.3.x-address of the remote host to its 192.x-address.

So, in total, per hosts, that needs to reachable, it requires 1x VIP + 1x IP pool on the source Fortigate, and 1x VIP on the destination Fortigate. But doing so for multiple hosts is overkill. And I had hoped, the above mentioned docs and cookbook-recipe would provide a more simple solution.

[MikePruett]

Yeah, in situations like this I have always just used NAT to assist. Makes things cleaner for me.

[ede_pfau]

I understand what you did with one host. But thi s will only work as long as you don't have to address a larger number of hosts. Not to mention that you have to "know" that 192.168.1.11 is in Cleveland but 192.168.1.20 in Baltimore. And other users have to know that as well.

IMHO - impractical. That's why the duplicate network range is completely substituted.

If you want to stay on that road you could configure the VIPs not only with a host address but an address range ("192.168.1.[10-50]") if you cannot use a network mask. This way, you wouldn't need any additional VIPs.

[sw2090]

Hiho,

I am running into quite the same issue.

 I have One FGT100E and one 60E. Behind both is the same subnet (192.168.1.0/24).

I set up a Tunnel and VIP accoarding to the howto in the cookbook (http://cookbook.fortinet.com/vpn-overlapping-subnets/). However my tunnel does not even come up completely (the howto says the tunnel should come up after doing what is said there). It gets stuck in phase2 when it want's to send IKE keepalive packets because FGT2 does not get an answer on those from FGT1. 

I think this is due to missing address translation. FGT2 sends IKE keepalive to FGT2 using FGT1's LAN Address (out of 192.18.1.xx). FGT1 will then route the answer wrong  since 192.168.1.xx belongs to local interface. As it was written above I too am mising the translation. FGT2 should send IKE Keepalive to FGT1 using the mapping (i.e. dnat with the vip ips) in my thoughts.

I found something about missing policies and tried to add them without any improvement.

Also some naming in the howto is irritating. He mentions "internet- facing interface" and then selects port1. Other threafs and pages in the net say you have to use the wan port here. 

I am stuck completely for now and appreciaty any help.

cheers

Sebastian

[NKL]

I never got it working with the forementioned approach. For me, VXLAN was the way to go: [link]https://forum.fortinet.com/tm.aspx?m=155208[/link] Though I cannot say anything regarding performance, as we were only doing it in a test-environment. It worked, but seems to require some finetuning (MTU sizes etc.).

[sw2090]

unfortunately VXLAN will not do the trick here for several reasons.

a) I cannot ad port1 (my Lan) to the vswitch because its already in use in some policies and routings

b) we do have the same subnets on both side. What you do would in our case result in several ip address conflicts because the ip exists on both sides. This will only work once you somewhat "Part" the subnet and use one part on side 1 and the other on side 2.