Two Gateways on a Single Network: VPN into One Gateway with Limited Access

Not sure about tinc but IPSEC is almost mandatory. No serious business would trust PPTP.

Not sure how IPSEC affects routing. A tunnel is a tunnel is a tunnel regardless of the encryption. You'll be running into the same issues re: split tunnel or not, getting customers to understand the concept / oh look a particular customer's LAN IP clashes with the VPN pool you've picked, etc.

Sounds like you're aiming at SME market (individual servers, direct login etc.) so that rules out more sophisticated solutions, but I'll list two possible approaches anyway

• some kind of VPN concentrator that allows profiles. All customers login to VPN concentrator then depending on their profile/group/whatever vendor teminology, get permissions to use protocol X to IP Y (ie their own server).

• Cisco ASR1000V virtual routers - each customer gets one, you can then run direct IPSEC tunnels (with VTIs so makes routing appear easy) or even direct MPLS back to the customers so the router appears as just another branch in their topology, then allocate your VNICs VLANs etc. on the inside so they get a nice virtual 'branch'.

• a smaller scale version of the above, we've used monowall to great effect for this purpose (i.e. each customer gets a layer 3 virtual device that acts as a router/firewall, they VPN into this device and get access to their VLANs only), however then each router/firewall needs their own public IP address.

Re: your current approach, you do realise then each server needs a public IP or you have a complicated and convoluted system of NATs where each customer's VPN path gets allocated a single port or similar.

I'd recommend getting a full time networker in to look over any design / proposal you have, it sounds like you're coming at it from a server background.

The problem you are seeing is normal behavior. When you use object groups to define the tunnel traffic, the ACL gets expanded to a regular ACL with multiple entries. For example, this ACL

access-list outside_cryptomap extended permit ip 192.168.11.0 255.255.255.0 object-group DM_INLINE_NETWORK_1  

becomes

access-list outside_cryptomap extended permit ip 192.168.11.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list outside_cryptomap extended permit ip 192.168.11.0 255.255.255.0 192.168.50.0 255.255.255.0

Each line in the ACL creates a Securty Association (SA) for the VPN.

Because you are using dynamic VPNs, the SA doesn’t get created until the remote router sees traffic that matches the ACL entry. You apparently have devices on the 192.168.0.0 network that are talking to the 192.168.11.0 network, and this creates the SA for that entry.

But you don’t have any devices on the 192.168.50.0 network talking to 192.168.11.0, so the SA never gets built. With no SA, you can’t send traffic from 192.168.11.0 to 192.168.50 0. Once you ping from 192.168.50.0 to 192.168.11.0, the SA is created and you can send traffic in either direction.

To make this work the way you want, you have three choices:

1. Go back to static VPNs. The SAs are always up.
2. Find some way to generate traffic on the 192.168.50.0 network. Anything will do.
3. Readdress your networks so that you have one ACL entry that covers both networks at the remote end. You will have only one SA, which will be created as soon as traffic flows.