Ping VPN to LAN

mMontana said:

I hope that something i'm gonna write will be understandable.

I'm assuming this scenario...

Local Site

Firewall

LAN1 192.168.1.1/24

L2TP Pool VPN 192.168.2.x/24

NAS Local

LAN  192.168.1.10

Remote Site

NAS Remote

LAN 192.168.1.99

L2TP virtual adapter (refer to your LTP2 Ip Address Pool, i'm assuming 192.168.2.7)

First issue: NAS remote won't ever find NAS local on 192.168.1.10 thought L2TP Tunnel. Without a destination NAT configured into L2TP VPN Connection (under IPSec -> VPN Connection), routing to 192.168.1.0/24 will remain into the same subnet, won't go over VPN.

Second issue: NAS Local will find NAS Remote only on 192.168.2.7, but only because the routing is demanded to the Firewall. Due to first issue, the return path may not work.

Unless there's another arrangement... Make theorical exercises without the whole layout with "according subnetting" (the true one is unnecessary) will lead only to theories... and not solutions.

mMontana said:

Best is quite a big word for that.

Every "working" solution has pros and cons, and maybe some of these might be "too good for not have" or "too bad"/"too many things to do" that people might answer "I cannot accept that".

A customer allowed me to build this working scenario:
a QNAP NAS is using RTRR for offsite backup to another QNAP NAS. VPN is managed via two firewalls, that are providing an IPSec tunnel. The remote site, due to internet with dynamic IP, is the initiator of the tunnel, which is nailed up. But backup is initiated at the local site, for allowing a unified schedule list of backup process from "onsite" NAS to other destinations.

Pros:

• no CPU of the NASes is used for encryption
• any Firewall can be substituted without issues, until subnet is kept as is now
• VPN cyphers can be boosted if newer devices are more CPU driven
• I use native NASes instruments for exchanging data. I might also ad another layer of cypher if i feel necessary
• VPN override the dynamic public ip address problem: the remote site contacts every time possible the local site, making the remote NAS available as backup target (static private remote IP address)
  

Cons:

• 1 more device (remote firewall). This means more money, more power, more boxes, more cables, more things to configure
  
• subnetting had to be built with reasoning and be consistent among devices
• remote Subnet had to be changed (and also the one of the remote ISP router, with proper port forwarding and access rules) => more things to do
  
• remote NAS, if moved to another location, must be paired to the firewall (and kept consistent subnetting)
  
• If network connectivity change, I might have some issues to manage (NAT-T, VPN filtering, more possible issues)
• In case of problems for the backup/sync procedures, I need to check source, destination and firewall logs.
  

75% of problems can be solved via proper design and before implementation.