Allowing OpenVPN Clients to See Site-to-Site Devices

Brailyn

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 10.0.8.0/24 subnet. They can communicate with the server LAN, 10.0.0.0/24 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 10.8.8.0/30 network. LAN devices can chat each way. The remote LAN is 10.1.1.0/24.

Unfortunately the 10.8.8.0/30 and 10.0.8.0/24 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 10.8.8.0/24 network to the "LAN Networks" in my client-to-site config and it would allow clients to ping 10.8.8.1 (beginning of tunnel) but not 10.8.8.2 (end of tunnel).

Any help with this would be appreciated.

viragomann

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.

chpalmer

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

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

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

chpalmer

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.

Brailyn

I'm hoping it is a firewall rule. I tried to allow source 10.0.8.0/24 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 10.0.8.0/24 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 10.0.0.0/24 and 10.8.8.1 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" 10.1.1.254... 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.

chpalmer

Maybe Im confused…

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

chpalmer

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

Brailyn

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: http://www.brocade.com/content/dam/common/documents/content-types/configuration-guide/vyatta-openvpn-3.5r3-v01.pdf

My Vyatta config:


interfaces{
 openvpn vtun0 {
        description swift-to-stoon
        encryption aes256
        hash sha256
        local-address 10.8.8.2 {
        }
        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-address 10.8.8.1
        remote-host site-A-public-DNS.com
        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 10.0.0.0/24 {
            next-hop-interface vtun0 {
            }
        }
    }
}

chpalmer

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 10.0.0.0/24,10.0.8.0/24 {

Client (mobiles) side should have this option somewhere also. -route 10.0.0.0/24,10.1.1.0/24

Hub in the middle (10.0.0.0/24 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.

chpalmer

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

VPN.jpg_thumb

Brailyn

I added this to Vyatta (remote site B):


set protocols static interface-route 10.0.0.0/24 next-hop-interface vtun0

to get:


 static {
     interface-route 10.0.0.0/24 {
         next-hop-interface vtun0 {
         }
     }
+    interface-route 10.0.8.0/24 {
+        next-hop-interface vtun0 {
+        }
+    }
 }

I added this to Viscosity (remote client):

Route=10.1.1.0
Mask/Bits=24
Gateway=Default
Metric=Default

I added both the 10.0.0.0/24 and 10.1.1.0/24 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 10.1.1.0 255.255.255.0″;

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!

chpalmer

:)

No problem!