Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[zhero]

Hello

I have a number of site-to-site VPNs between using dfl800 and 860  devices established for my clients. This is a hosted application and I need for the entire address range on the client's network to be able to hit my site. I've encountered a situation where I have overlapping VPN subnets. Several of my clients share the same internal address space (e.g. 192.168.1.x), so I've only been able to establish a VPN to one of them. What are some workarounds for this issue? Should I look at outside NATing or some way to translate the client IPs? Any other suggestions?

regards

Giorgio

[zhero]

a schema in attach




Uploaded with ImageShack.us

regards

[vkropotov]

Hello. The information was taken from another forum.

Same network on both sides of an IPsec tunnel

Postby Peter »

Problem:

I want to establish an IPsec tunnel to a remote office, but the local network there conflicts with the local network at the central office. How can i solve this problem without changing the network on either side?

Solution:

This is possible to solve by address translating the network on both sides to something else when these networks need to talk to each other. Lets say that the conflicting network is 192.168.1.0/24, we create a "fake" network that only exists between these 2 sites. So instead of connecting to the remote host 192.168.1.50 we connect to 172.16.1.50. This modification can be done automatically.

How to accomplish this.

Example:

      Main Office:

Local Network: 192.168.1.0/24
Externa IP: 1.1.1.1

      Remote Office:

Local Network: 192.168.1.0/24
External IP: 2.2.2.2

      Main Office IPsec:

Name: Stockholm_IPsec
Local Network: 172.16.1.0/24
Remote Network: 172.16.2.0/24
Remote Gateway: 2.2.2.2

      Main Office route:

Stockholm_IPsec 172.16.2.0/24
[core] 172.16.1.0/24

      Remote Office IPsec:

Name: Gothenborg_IPsec
Local Network: 172.16.2.0/24
Remote Network: 172.16.1.0/24
Remote Gateway: 1.1.1.1

      Remote Office route:

Gothenborg_IPsec 172.16.1.0/24
[core] 172.16.2.0/24

      Main Office Rules:

Outbound: SAT lan 192.168.1.0/24 Stockholm_IPsec 172.16.2.0/24 SETSRC 172.16.1.0/24
Outbound: Allow lan 192.168.1.0/24 Stockholm_IPsec 172.16.2.0/24

Inbound: Sat Stockholm_IPsec 172.16.2.0/24 Any 172.16.1.0/24 SETDEST 192.168.1.0/24
Inbound: Allow Stockholm_IPsec 172.16.2.0/24 Any 172.16.1.0/24

Note: You can not select i.e 172.16.1.0/24 as Source or destination network on the
SAT rule's address translation tab, you need to type 172.16.1.0 and it will translate
correctly from the correct sourceip and destip. 192.168.1.50 becomes 172.16.1.50 etc.

Note-2: The reason why we [Core] route the 172.16.x.x network is because this network will not exist behind any physical interface. It exists in the Core only (so to speak).

The same rules but the other way around on the remote office.

This enables the same network to still exist on both sides, when clients want to connect to hosts on beyond the IPsec tunnel they use the 172.16.x.x address instead of 192.168.x.x and thus we have bypassed the problem and there is no need to change the local network on either side.

Example flow:

Host 192.168.1.93 on the Main office wants to reach an FTP server on the Remote Office. This FTP server has the IP 192.168.1.55 on the remote office. Host 192.168.1.93 then connects to 172.16.2.93 which will traverse the IPsec tunnel then address translated from 172.16.2.93 to 192.168.1.93 in order to match the machine on the remote office local network.