Probably a confusing title (and a bit off-topic argument ?)....

Let's assume I build a number of tunnels between my own site and remote sites.
Each remote LAN has the same subnet (i.e. 192.168.1.0/24) so there will be many machines , each on its own LAN , with the same ip address.

Can I create virtual subnets on my own site to point (route) traffic on each desired remote lan ??

I.e. :

10.0.1.0/24 point to 192.168.1.0/24 offirstremote site/tunnel end
10.0.2.0/24 point to 192.168.1.0/24 ofsecondremote site/tunnel end
10.0.3.0/24 point to 192.168.1.0/24 ofthirdremote site/tunnel end

and so on....

So when I point to 10.0.3.100packets will be routed to 192.168.1.100ofthirdsite

Any solution ?

Thanks

You do not want to try and go that route.


Simply re-IP the other networks so that they are not in the same address space.

Remote LAN subnets cannot be modified at all,
suggestions ?

Your only option is to setup 255 source nats and 255 dst nats with the 10.0.0.x/24 address scheme on each router pointing to their respective 192.168.0.x/24 devices. These will then need to be routed over the VPN. That is also after you create 255 interfaces for the 10.0.0.x addresses to reside.

永远,你将不得不手动管理他们ing into the future when a device's IP changes.

Do you manage these networks? Who decided that you cannot change the IP addressing scheme? If you cannot change the IP addressing scheme, how can you get authorization to setup a VPN?

The purpose could be of remote managing devices that reside on different customers LANs
I cannot ask a customer to change an already working subnet just to satisfy my needs.
The customer instead allow me to install a VPN for that particular need.
I'm already using PPTP calls to bring up the tunnel with customer X and shut it down when complete.
Now there should be the need for an h24 surveillance/status/maintenance of multiple customers, mostly with an identical subnet LAN.
So I have to manage/trace the 192.168.1.200 machine @ customer x, y, z at the same time from my single local machine.

I thought a service/solution like this already existed......

When they are on different addressing schemes, yes, there are automated processes available.

When you are using the exact same addressing scheme at multiple sites, how would your router know to go to site A versus site B based only on an IP that is available at every site?

It would be less painful to go through an IP addressing change now, than to manage the debacle that I typed above - especially if DHCP is involved....

You have a tough set of criteria to make things both seamless AND with zero-touch on the customer's site.
If you have your own VPN appliance at the customer's site then this is pretty simple:

do 1:1 netmap at the customer edge - use 10.x.x.x addressing on your side of the NAT, so each customer has a unique IP from your perspective.
e.g. customer 1 is 10.0.1.0/24, customer 2 is 10.0.2.0/24 - if they need multiple ranges, then simply assign them to customers as needed. Try to keep them as contiguous as possible - so if a customer has 4 different subnets on their side, assign 10.0.4.0/22 to that customer so that you only need one route statement on your side.

At the CPE do 1:1 mapping with the netmap action in the nat table.
Packets going out into the customer's LAN should just get masqueraded to whatever IP the vpn appliance has, so the customer's network doesn't need to worry about your management network's IP addressing. Their network will route back to your device because it has an IP that's already a part of their network.

So the nat table of the CPE appliance might look like this:
[/code]
srcnat / out-interface=mgmt-vpn src-address=192.168.1.0/24 action=netmap to-addresses=10.0.2.0/24
srcnat / out-interface=mgmt-vpn src-address=192.168.32.0/24 action=netmap to-address=10.0.3.0/24
srcnat / out-interface=customer-interface action=masquerade

dstnat / in-interface=mgmt-vpn dst-address=10.0.2.0/24 action=netmap to-addresses=192.168.1.0/24
dstnat / in-interface=mgmt-vpn dst-address=10.0.3.0/24 action=netmap to-addresses=192.168.32.0/24
[/code]

You could even use a very cheap device to do this - the mAP lite. Just disable the wlan1 interface, and use the singe IP interface on the customer's lan as the one plug. Make the mAP lites configuration be such that they phone home with a vpn connection through the customer's LAN.

You could break down the 1:1 mappings to just be for specific IP addresses if you wanted to be that granular.

Thank you for information, I never had the need to use netmap , time to learn.

I'm a little confused about which side to configure with your example,

Take a look at the diagram with only two customers involved and their interfaces name:



What NAT configuration should I use at "myoffice" and what at each customer ??

Thank you !


P.S. all devices are already RouterBoard

In your office, route 10.0.2.0/24 at 172.16.1.2, 10.0.6.0/24 at 182.168.1.6, etc.

That's all that needs to be done in the office router.

In the customer router, that is where you put the netmap rules:
chain=srcnat out-interface=gre1-b action=netmap src-address=192.168.0.0/24 to-address=10.0.2.0/24
chain=dstnat in-interface=gre1-b action=netmap dst-address=10.0.2.0/24 to-address=192.168.0.0/24

Done... so long as your management source is never 192.168.0.0/24 then you'll never have any issues. On your side of the link, just refer to each customer's device by its 10.0.x.x IP. Since the office is 192.168.100.x, and you never use 192.168.100.x at the customers' sites, all routing will work as needed. If a customer DOES have a 192.168.100.x network and you can't convince them to re-number, then you'll need to put a masquerade rule on the office router in their GRE interface:
chain=srcnat out-interface=gre3-C action=masquerade.

FYI netmap is a stateless 1:1 translation technique. A packet will just get the src or dst address changed as it passes through the router. There will be no state map added for this, so you have to have two rules when using netmap - one for each direction through the router. Its primary use is for address migration, but it also lets you do something like this where an entire range of addresses is mapped to another range due to addressing conflicts.

Clear now
Thank you , I'm givin it a try ....

Clear now
Thank you , I'm givin it a try ....

Good luck - oh, and re-reading my last post's advice, I realized there was one thing that was ambiguous:

If a customer DOES have a 192.168.100.x network and you can't convince them to re-number, then you'll need to put a masquerade rule on the office router in their GRE interface:
chain=srcnat out-interface=gre3-C action=masquerade.

我在办公室路由器,意味着你需要放一个masquerade rule on packets going out the GRE interface to this particular customer.

(原因是没有在办公室化妆舞会,the customer LAN would see the source IP address as 192.168.100.x and would consider that to be local, thus the replies would never be sent to the router for transport back to the office. Since the on-site router has 192.168.100.1 in this case, it can't do any masquerading - it would be just as confused as other LAN hosts there - only the office router can tell a convincing lie in this case.)

Thank you for your note
However , knowing customers , I'm almost sure they have their lan subnets other than mine.

I noted instead , I have to insert a routing rule at customer side pointing to my lan subnet using my side gre ip address as gateway , otherwise it doesn't work.

Am I wrong with something ??

Thanks

I noted instead , I have to insert a routing rule at customer side pointing to my lan subnet using my side gre ip address as gateway , otherwise it doesn't work.

Am I wrong with something ??

No, that's normal - you always need to have proper routing. I was just focused on the NAT portion of your solution, and assumed that routing was already taken care of. Good catch.

Then, checked , it works like a charm.....
Thank you

hello ,
In order to follow this discussion more carefully, could you make the image/diagram mentioned in your post of Feb 03,2016 at 7:06 pm available? i am unable to download it.
thanks in advance

In your office, route 10.0.2.0/24 at 172.16.1.2, 10.0.6.0/24 at 182.168.1.6, etc.

That's all that needs to be done in the office router.

In the customer router, that is where you put the netmap rules:
chain=srcnat out-interface=gre1-b action=netmap src-address=192.168.0.0/24 to-address=10.0.2.0/24
chain=dstnat in-interface=gre1-b action=netmap dst-address=10.0.2.0/24 to-address=192.168.0.0/24

Thanks a lot. Just solved my problem with two tunnels <3

Ralf.