PPTP access with defind DHCP-Server 7.503

Not sure what your question is.  You will have problems if you use the same DHCP server for both the VPN and your internal network.  It's best to use the standard "VPN Pool (PPTP)" instead.

Cheers - Bob

hello BAlfson
thank you for answer

you solved a similar problem for me that i've in may 2009 with 6.315

to your question:

i don't care which way i'm using.
when i'm defining in the PPTP configuration the VPN Pools (PPTP) then i cannot connect to computers in the "remote" lan (192.168.101.X)

so i tried the same way as in 6.315 and define in the PPTP configuration "DHCP Server", 
and this server is in the  LAN 192.168.100.X

But with this configuration no computers in the LAN 192.168.100.X are visible!

There was a bug that existed prior to V7.500 that enabled that to work in 6.513.

Now, set the IP address assignment to "VPN Pool (PPTP)".  Then add the "VPN Pool (PPTP) to the VPN:

• Add "VPN Pool (PPTP)" to 'Local networks' in your VPN Connection
  
• In the remote Astaro, add a new network definition with the IP range of the local "VPN Pool (PPTP)"
  
• Also on the remote Astaro, add the new definition to the 'Remote Networks' in the remote ASG's Remote Gateway definition for the local Astaro.

Does that resolve your problem?

Cheers - Bob

hello

problem solved, astaro 2nd level support installs a patch in our system, now it 
works perfect.

thanks for your efforts!!

Interesting!  Last December, I received the following from Astaro Support along with an extract of tcpdump:

Because the DHCP server is leasing IPs on the same network as the internal network, it is causing hosts on the internal network to ARP for the MAC address of the l2tp client.  ARP traffic will not route through the l2tp tunnel.
[...]
In the above capture, you will not find the ARP traffic, because L2TP network is a segregated network from the LAN.  Thus, the LAN will not ARP for the MAC, but rather will forward it to the default gateway, the ASG.

I wonder if they have decided to make this a permanent feature.  It does seem like it should be able to respond to an ARP request with the MAC of the Internal interface (or whatever interface the request arrives on).

Cheers - Bob

There was a bug that existed prior to V7.500 that enabled that to work in 6.513.

Now, set the IP address assignment to "VPN Pool (PPTP)".  Then add the "VPN Pool (PPTP) to the VPN:

• Add "VPN Pool (PPTP)" to 'Local networks' in your VPN Connection
  
• In the remote Astaro, add a new network definition with the IP range of the local "VPN Pool (PPTP)"
  
• Also on the remote Astaro, add the new definition to the 'Remote Networks' in the remote ASG's Remote Gateway definition for the local Astaro.

Does that resolve your problem?

I've a similar problem; before I upgraded to 7.503, using the local DHCP server to hand out PPTP and L2TP addresses worked fine. Now they don't. I've switched to using the VPN Pool, and now the clients that're using the VPN as the default gateway are working fine, but split-tunnel clients don't know anything about the route back to the internal network.

On my other VPN networks, I use RIP1 (because the Windows clients have a RIP1 listener) to get the remote networks 'learned', but I don't see how I can get that going here.

What's the trick to getting split-tunnel working?

Hi, Jim,

Have you filled out the 'Advanced' section in 'Remote Access'?

Cheers - Bob

Have you filled out the 'Advanced' section in 'Remote Access'?

I have, but that doesn't affect routing at the client. They "know" their DNS hosts are "inside", but they can't get there according to the routing table.

In this instance, the L2TP client gets 10.242.3.3, no gateway (again: split tunnel in use at the client side--the PPTP/L2TP client on XP is configured to NOT use the default gateway on the remote network) on the connection, so it thinks it must use the local default gateway to reach the "inside" LAN.

Given that the "inside" is a private address space, I wouldn't expect this to work.

The routing table on the client clearly shows the problem: the VPN address shows up, but the remote site isn't listed.

Sorry, I wasn't paying attention.  In IPsec and SSL VPNs, you can limit the 'Local networks' to your internal networks, and thus offer only a split tunnel.  To have a "Full" tunnel, use "Any" or Internet" and your internal networks.

In L2TP and PPTP, the decision about split tunnel is made in the client.  In the case of Windows, bring up the Properties of the Connection, go to the 'Networking' tab, highlight TCP/IP, click Properties, Click Advanced, and then, for a split tunnel, deselect 'Use default gateway on remote network'.

Was that the trick you were looking for?

Cheers - Bob

Not sure what your question is.  You will have problems if you use the same DHCP server for both the VPN and your internal network.  It's best to use the standard "VPN Pool (PPTP)" instead.
Cheers - Bob

Here's the disconnect: when using the remote DHCP server, the VPN client "knows" the route to the ASG's network, whether using the local or remote gateway (split or full tunnel). When using the "VPN Pool" (regardless of connectivity type), the only way to automatically reach the ASG's network is to use a full tunnel (default route is the ASG, which then routes packets appropriately). When using PPTP or L2TP with the client set to create a split tunnel, the client's local gateway is the default route; ideally, this means that "general" traffic goes out the "normal" way, and traffic destined for the other side of the VPN goes out through the VPN interface. However, for this to succeed, the client must have some way to "learn" that the route to the remote site is via the VPN tunnel.

With my non-ASG VPN solutions, I've always handled this by a) installing the RIP listener on the client and b) enabling RIP-I broadcasts on the VPN interface. Without some sort of routing protocol (that is understood by both sides of the link!), the only other way to get this working is with static route entries. This is annoying if you're a seasoned user and understand how to make this work; it's a non-starter for someone that isn't sophisticated.

Unfortunately, I don't see a way to do this on the ASG (routing protocol that works on the ASG AND Windows XP/7 clients), which is why I'd like to get back to using the remote DHCP host instead.