Allowing OpenVPN Clients to See Site-to-Site Devices

  • Hello,

    I have two OpenVPN servers. One is site-to-site and the other is client-to-site.

    When clients connected while on the road they are put in the subnet. They can communicate with the server LAN, just fine, even the DNS works too! The Server LAN can communicate to those connected clients as well.

    My site-to-site connection is tunnelled through a network. LAN devices can chat each way. The remote LAN is

    Unfortunately the and network cannot connect to each other. I feel this is a trivial issue that you guys will probably shake your heads at… but I could not find any post that made this very clear to me.

    I added the network to the "LAN Networks" in my client-to-site config and it would allow clients to ping (beginning of tunnel) but not (end of tunnel).

    Any help with this would be appreciated.

  • I assume, you do not NAT at VPN subnets.
    So at server assign an interface to each VPN server, then add firewall rules to each VPN interface to permit traffic.

  • I added the network to the "LAN Networks" in my client-to-site config and it would allow clients to ping (beginning of tunnel) but not (end of tunnel).

    This is your tunnel.  You don't need rules for it.  did you mean

    If you haven't yet- Build a firewall rule on the remote site OpenVPN tab that allows to LAN net.

  • Just to add-  I cannot ping the "B" side of any of my OpenVPN tunnels from my "A" side either.  But I can reach the "B" side LANS no problem.

  • I'm hoping it is a firewall rule. I tried to allow source in and I still cannot ping the other side of the tunnel. Maybe my rules are not in the right order…

    ERLite "B" rules

    Order  Description                                            Source                          Dest                    Protocol          Action  Comment
    1 allow established session to the router                                                                              all              accept  default
    2 drop invalid state all                                                                                                                drop    default
    3 Remote Admin                                                                                port 443,2020          tcp              accept  These are working well
    4 OpenVPN                                                      port 1194                      port 1194              udp              accept  Not sure if I need these anymore.
    5 Homesite "A"  OVPN Clients address                                                                      all              accept  Newly added. Did not work. Check order?

    Sorry the table is all messed. It won't format correctly in the forum.

    Still can only ping and while "on the road".

    "But I can reach the "B" side LANS no problem. " I tried pining the B side LAN gateway while "on-the-road" no luck.

    To answer viragomann, I only let the default OpenVPN configurator touch NAT. I have not changed anything in there.
    Where are these firewall rules you are talking about? I see the OpenVPN leaf in the Firewall Rules page allows anything to talk to anything.

  • Maybe Im confused…

    Why do you need to reach the "B" side tunnel IP?

  • What does the Remote Site VPN config look like at "IPv4 Remote Network(s)-"?

  • I do not need to ping the "B"side of the tunnel. I was just doing that to see if I was getting closer to the "B" side LAN.

    I'm not sure If I was clear, but the "B" network is formed with a Vyatta device:p

    It's config may allow for alternate networks, but I'm not sure… looking at it's documentation found here:

    My Vyatta config:

     openvpn vtun0 {
            description swift-to-stoon
            encryption aes256
            hash sha256
            local-address {
            local-port 1194
            mode site-to-site
            openvpn-option "--ping 10"
            openvpn-option "--ping-restart 20"
            openvpn-option "--user nobody"
            openvpn-option "--group nogroup"
            openvpn-option "--verb 5"
            openvpn-option "mssfix 1450"
            openvpn-option "tun-mtu 1500"
            openvpn-option "tun-mtu-extra 32"
            openvpn-option --comp-lzo
            openvpn-option --float
            openvpn-option --ping-timer-rem
            openvpn-option --persist-tun
            openvpn-option --persist-key
            protocol udp
            remote-port 1194
            shared-secret-key-file /config/auth/secret

    Just below that config I see something that may help this issue… thoughts?

    protocols {
        static {
            interface-route {
                next-hop-interface vtun0 {

  • Ok- got it.  :)

    Each end of a VPN needs to have the IP's it is expected to route to.  In the case of your Remote side it should look like-

    interface- route, {

    Client (mobiles) side should have this option somewhere also. -route,

    Hub in the middle ( network) will only have the other side of the VPN on each config.  Mobile network on mobile VPN and remote network on site to site VPN.

  • Heres a picture of one of my sites pointing at three others through my hub site.

  • I added this to Vyatta (remote site B):

    set protocols static interface-route next-hop-interface vtun0

    to get:

     static {
         interface-route {
             next-hop-interface vtun0 {
    +    interface-route {
    +        next-hop-interface vtun0 {
    +        }
    +    }

    I added this to Viscosity (remote client):


    I added both the and networks to my "A" hub on PfSense.

    I added the following to the export config advanced settings window for my .ovpn iPhone config:

    push “route″;

    YES!!!! IT ALL WORKS!!!!
    Now to get the DNS working in Vyatta.

    Your answer was so good it was almost poetic:)

    You sir, are a genius!

  • :)

    No problem!

Log in to reply