ncollingridge wrote: It looks pretty much the same to me, assuming your 192.168.1.0 and 192.168.2.0 networks are additional subnets at the far end, which they pretty clearly are. I also assume you pruned the local network entry....
...There's no Route Policy Diagnosis tool within the GUI of either of the models I have, which are a 2860 and a BX2000.

Yes to both. (192.168.1.0 is a vain attempt to reach a Zyxel modem and 192.169.2.0 is "Guest Wifi".)

On the 2860: Expand "Routing" in the left-column, then "Load-Balance/Route Policy". "Diagnose" is just under the Blue :?: on the right-hand side. (But, in any case, I think your Traceroute shows that the outbound stuff is ok)

he also wrote: The return path seems to be coming back via an IP address which is within the DHCP pool, rather than via the router itself. ...
...Is this normal? It seems rather odd to me that all packets coming from the remote end should be sent over the VPN via what I imagine is a virtual IP Address.

I believe so. There's currently nothing intelligent enough to do a Traceroute at the other end of my VPN - but if there was, it would probably show 192.168.100.64 (the first DHCP address usually) in the path. I don't know why it's different in different directions.


In my case this 'odd' IP address is not mentioned in the Routing Table:-

Code:

> ip route status Codes: C - connected, S - static, R - RIP, * - default, ~ - private C~ 192.168.100.254/ 255.255.255.255 is directly connected, VPN-2 S~ 192.168.100.0/ 255.255.255.0 via 192.168.100.254, VPN-2 C 192.168.1.0/ 255.255.255.0 is directly connected, LAN3 C~ 192.168.2.0/ 255.255.255.0 is directly connected, LAN2 C~ 192.168.200.0/ 255.255.255.0 is directly connected, LAN1 >

There's an article here , that claims to address this question, but it goes downhill rapidly after the first paragraph

The Routing diagnosis tool is in a slightly different place than you describe, but I have now found it. It is in its own category in the left-hand menu called Load-Balance/Route Policy, and within this it is the second option, Diagnose.

When I run the tool I get a message pretty similar to yours - "The packet was sent via VPN-3 according to the Static route "10.0.3.0/255.255.255.0 VPN-3", but with the weirdness that it says the packet went via VPN-3, which doesn't exist.

The VPN that exists is definitely VPN-1, and I don't know whether this is a display aberration or an indication of a problem. A VPN with index 3 is not set up anywhere.

I wonder whether this might explain things, though - if the router is forwarding packets out through a non-existent VPN that would explain why they are disappearing. I will try de-activating and re-activating the VPN to see whether that sorts it out.

De- and re-activating the VPN did fix that display problem, but it hasn't sorted out the routing.

On further reflection it was a bit of a red herring anyway - from traceroute I know that packets get to the remote router, the problem is with onward forwarding, or possibly the return path. So the problem may be with some aspect of how the remote router is set up.

Or it could be a bug in the current firmware! But I would expect that there would be more people moaning about it if so.

I must confess to having found the solution, which is good news even if it is a bit embarrassing! The Remote Network IP was set incorrectly on the remote router - it was 10.0.1.0 instead of 10.0.0.0.

That entirely explains it - the packets were getting through but no response was getting back, as the router didn't know what to do with anything intended for IP addresses in the 10.0.0.0 subnet - it would only send packets down the VPN if they were destined for IP addresses in the 10.0.1.0 subnet.

A friend has said that this is a reason he doesn't use 10.0.x.x subnets, but instead favours 192.168.x.x, because there is less potential for confusion with all the zeros...

Thanks to hornbyp for his generous attempts to help with the problem. I have learnt a lot about how this all works as a result of going through it all. Hopefully this post will be usfeul to others as it does provide some information that I have not found elsewhere.

One thing that I think I should add which I don't think I have covered before is that the Local Network IP field in TCP/IP Network Settings for LAN-LAN VPNs should obviously be the subnet address rather than the address of the router. The manual is misleading in this respect in what it shows.

Also, for a device on the local subnet to communicate across the VPN its network settings should obviously just be correct for the local subnet. Any attempt to connect to a device the other side of the VPN will be routed there by the router, and packets from the device at the far end will get back because the remote router knows that anything for the local subnet comes back across the VPN. Obvious, I know, but I feel it is worth saying!

You just need to migrate from PPTP -> L2TP/IPSec now :wink:

Wait till you see how many permutations of settings there are to play with ... my first attempts yielded a VPN that wasn't actually encrypted - I never did figure out why that was even allowed.