Custom Config help needed: Multiple subnets *ANSWERED*



  • Hi Folks,

    Here's my scenario:

    MAIN Site (OpenVPN Server)

    Data Subnet (LAN): 10.100.100.0/24
    Voice Subnet (Opt1): 10.100.200.0/24
    VPN Subnet: 10.10.10.0/24

    Custom Config: engine cryptodev; push "route 10.100.200.0 255.255.255.0"

    REMOTE SITE

    Subnet:10.100.101.0/24

    I would like for the remote site to be able to access both Data and Voice Subnets. Obvioulsy, the push command alone is not enough to accomplish this.  What kind of magic do I need to allow remote sites access to both subnets?


  • Rebel Alliance Developer Netgate

    Is this a PKI setup or a Shared Key setup?

    If it's shared key, you can't push routes. Just add the same statement (route blah blah) without the push on the custom config of the client side.



  • @jimp:

    Is this a PKI setup or a Shared Key setup?

    If it's shared key, you can't push routes. Just add the same statement (route blah blah) without the push on the custom config of the client side.

    It's site-to-site PKI

    So server side would be:

    route [client subnet]; push "[server subnet1]"; push "[server subnet2]"
    

    I'm assuming local and remote subnet field would be "blank" in this case.


  • Rebel Alliance Developer Netgate

    No, if it's PKI then you can push and you fill out local and remote networks normally. You really should just need the proper routes then. Most people don't do PKI for site-to-site which is why I mentioned the other limitation.

    If you have Site A with subnets 1 and 2, and site B with subnet 3, you'd just need:

    Site A Server:
    Local Network, 1
    Remote Network 3
    Custom options, push route to 2

    Site B client:
    Nothing special needed

    If that doesn't work, then it isn't an OpenVPN routing problem.

    The custom options you mentioned would be functionally equivalent, as the remote network option just adds a route statement behind the scenes, and the local network box just adds a push route statement.



  • @jimp:

    No, if it's PKI then you can push and you fill out local and remote networks normally. You really should just need the proper routes then. Most people don't do PKI for site-to-site which is why I mentioned the other limitation.

    Thanks, the information you provided helped tremendously.  Now that I understand the routing and limitations of shared key, it all makes perfect sense.  Everything works as expected now.


Locked