VPN client - can't ping internal network

Cryptochrome, I don't believe that the Astaro has an inability to assign proper routing, just that there's a misconfiguration.

Scott, don't you think that the spoofing problem is because he has fixed a misconfiguration with something like a masq rule and is seeing an unintended consequence of that?

Cheers - Bob

Bob, I've had a case open with Astaro Support about this and they confirm it. The ASG is not able to tell a PPTP client which routes to use to reach the internal network. It just can't. 

That was true vor all version prior to 8.2. I guess it's also true for 8.2.

In V5, V6 & V7, I've not seen a failure to route to networks that are subnets of interface objects.  Do you mean manually-created routes, or the normal routing done as a part of the VPN?

Cheers - Bob

Cryptochrome, I don't believe that the Astaro has an inability to assign proper routing, just that there's a misconfiguration.

Scott, don't you think that the spoofing problem is because he has fixed a misconfiguration with something like a masq rule and is seeing an unintended consequence of that?

Cheers - Bob

In V5, V6 & V7, I've not seen a failure to route to networks that are subnets of interface objects.  Do you mean manually-created routes, or the normal routing done as a part of the VPN?

Cheers - Bob

What I mean is this:

Internal Network: 10.10.1.0/24
L2TP IP Pool: 10.242.2.0/24
VPN configuration: add automatic packet filter rules

Client connects to ASG, authenticates, gets IP address from the pool, for example 10.242.2.10. ASG assigns itself 10.242.2.1 (L2TP server address).

Client can ping 10.242.2.1 (ASG L2TP server address). 

Client can not ping or transmit any other traffic to 10.10.1.x.

Checking client's routing table reveals there is no route for 10.10.1.0/24 in it's routing table. Hence it can not talk to that subnet.

The same is true for PPTP.

Only solution: Manually add route on the client. This is confirmed by Astaro support. Other solution is to use IP addresses from the local subnet (10.10.1.0/24) to assign to clients. You will have to turn off IP snooping protection, which - of course - is not an option at all.

This effectively disables VPN access for any iOS device because you can't set routes on iOS.

I just confirmed with my iPhone connected via L2TP to Astaro V7.511.  I accessed Outlook web access on our internal server with http://server.domain.local/exchange/.

Is that an example of what won't work in your situation?

Cheers - Bob

I just confirmed with my iPhone connected via L2TP to Astaro V7.511.  I accessed Outlook web access on our internal server with http://server.domain.local/exchange/.

Is that an example of what won't work in your situation?

Cheers - Bob

Yes, thanks Bob. Have you configured your L2TP client to route ALL traffic through the VPN or just specific (split tunneling)?

Of course it will work if you just set a default route to your VPN (which might happen on iOS, not sure). 

Anyways, we can discuss this to oblivion: Astaro support confirmed my findings.

Well, I normally would accept Support's conclusion, but this contradicts my personal observations, and I'm well-known as a skeptic! [:)]

I know of no way to set static routes (especially persistent ones!) in the iPhone.  If the resource one is trying to reach is internal, then I don't understand how it could matter if the iPhone client is set to "split" (I do have it set that way though).

In any case, I appreciate your participation here.

Cheers - Bob

Bob, what IP addresses do you assign to your iPhone? Some from the same network that's behind the ASG? Or a completely (not routed) subnet?

Our Astaro L2TP over IPsec server is configured to use the default 10.242.3.0/24 VPN Pool (L2TP).

That's a great question, in fact.

Before V7.502, you could assign IP addresses using your internal (not the Astaro) DHCP server.  When that stopped working, Astaro Support said that it should not have worked in the first place because the ARP requests for a non-local IP would go unanswered.  At first, I agreed with that, but I did make a suggestion that the Astaro should be able to answer ARP requests for IPs in use by a VPN.  Perhaps they enabled that, and some other update now has interrupted that capability.

In any case, I remember the same phenomenon at the end of 2009, and the fix was to change from internal DHCP to using the default VPN Pool (L2TP) which assignes IPs outside of any local subnet.

Another possible issue is the ease of binding networks to specific interfaces (this will be curtailed, maybe already in V8.2).  Please go through your Network definitions to be sure that they all (except the supplied Internet definition) are bound to > instead of a specific, physical interface.

Cheers - Bob

Bob, what you describe is called proxy arp, and yes, the Astaro support mentioned it could work with proxy arp. However, proxy arp is only supported on physical interfaces. If you bind "virtual" interfaces to your internet facing interface and try to connect to one of those, proxy arp won't work. That's what we use here.

While it is supposed to work, it doesn't. 

To make a long story short: If I add a route manually on the client, everything works. And that's where the problem has to be solved. The ASG has to provide those routes during PPTP/L2TP negotiations, something that is specified in the according RFCs. Astaro just don't support it.

As for binding networks to specific interfaces vs. ANY - care to elaborate on that? What difference would it make?

It sounds like you have a solid grounding in TCP/IP and (I'm guessing) Cisco products.  That helps to understand and work with Astaro, but it also "blinds" you to some of the idiosyncracies of Astaro configuration - as well as some of the elegance (I'm an old math guy) inherent in WebAdmin since V7.

I would suggest that Support's answer is not as you've interpreted it.  I know that none of my clients are experiencing what you've described, but no one uses their internal DHCP server to assign addresses for PPTP and L2TP clients.

Binding a network definition to a specific, physical interface can cause random routing problems with NAT and VPNs.  I have confirmed that with my own clients and with several issues reported here over the last few years, but I can't explain why it occurs.  One client had your problem in December 2009, and I solved it by switching the VPN Pool definition back to bind to >, which is the default.

Cheers - Bob