Network A to Network C routing

OK, here's the trick, I think.

You want to use the networks entry on the VPN page to specify a subnet that the VPN will service; this does implicit interlan routing.

SOOO: you want on A firewall to specify a subnet for the VPN that includes B and C, but not A. And on the C firewall, you want a VPN that services A and B, but not C (if the VPN network did include the internal network, you'd have interfaces with non-mutually exclusive addresses, which would in turn result in a routing failure; the kernel will have to always pick one interface over the other, and the kernel will ignore the other duplicate network interface that got configured later). 

[We won't specify a network mask for the VPN connections on B; they should default to the specific networks of A and B, respectively, once a connection is established; that's why A can't see C, and vice-versa -the VPN by default only sets up a route for the adjacent network; Astaro's VPN does not support complicated dynamic routing protocols yet -and I can't blame them for not making that a priority, since people's routes would frequently be 'shorting out' due to misconfigurations and redundancies of remote networks between different shops; static routing is a safer way to go; if you get involved with many far-flung dynamic networks, then you need to employ a secure routing protocol and somebody who knows how to manage it...]

Possible solution:

Set A=192.168.1/24; set its VPN to service 192.168.64/25 (that's IP networks 192.168.65-253 -somebody check me on all this).

Set B=192.168.65/24

Set C=192.168.129/24; set its VPN to service 192.168.0/25 (that's IP networks 192.168.0-127).

What I said earlier about the routing (post deleted) was mistaken; you can see why this was difficult for me to remember.

This did work for me on 4; I haven't tried it on 5 yet...

Addenda: the firewall rules (a lot of people get this wrong).

We make a network called Enterprise defined to be 192.168/16 on all three boxes, and a rule on each that says Enterprise Any Enterprise Allow (or more restrictive rules and networks, if you want to regulate interlan activity).

You can see that using a "Class A" 10... private numbering scheme is more advantageous than a "Class B" 192.168... scheme, since you will have more room for such "supernetting" tricks in a bigger WAN.

On another recent post Gert says the VPNs can just be set to support the Enterprise network definition; that they need not be exclusive of the internal network. I thought that when I had done so, it gave me problems, but maybe it was something else; try it and see... If you look at the routing tables, if it works it's because the VPN routes always happen to get defined after the network interface routes (see earlier where I talk about ignoring duplicate network interfaces and "configured later"; Internal packets will always pass out the first local interface route; packets outside that subnet range will pass out the subsequently defined VPN route; if the routes were defined in a different order that would not work, but apparently VPN routes always are insured of getting defined after network interface routes...)

On another recent post Gert says the VPNs can just be set to support the Enterprise network definition; that they need not be exclusive of the internal network. I thought that when I had done so, it gave me problems, but maybe it was something else; try it and see... If you look at the routing tables, if it works it's because the VPN routes always happen to get defined after the network interface routes (see earlier where I talk about ignoring duplicate network interfaces and "configured later"; Internal packets will always pass out the first local interface route; packets outside that subnet range will pass out the subsequently defined VPN route; if the routes were defined in a different order that would not work, but apparently VPN routes always are insured of getting defined after network interface routes...)