Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 2095 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Network A to Network C routing

D1g1tal
Thanks to all in advance for any help you can provide.

I have 3 offices, all running ASL v5.

Network A - 192.168.1.0/24
Network B - 192.168.2.0/24
Network C - 192.168.3.0/24

There is a VPN connecting Network A to B and another connecting Network B to C.

I need to be able to monitor the VPN between Network B and C from Network A.  I have some pinging tools that will send emails upon failures alerting that the VPN has gone down.  

My problem is this....I can't get traffic from Network A to Network C.  What do I have to do at network A, B and C in order to get traffic from my pc on network A, through the VPN to network B and then through the vpn to network C and send a response?  I'm lost.

Any help would be much appreciated.

Thanks


This thread was automatically locked due to age.
  • 0
    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...
  • 0 in reply to SecApp
    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.
  • 0 in reply to SecApp
    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...)