If you would like to take this to the Forum .. I might be able to help.
Following this on a mailing list is not easy.

This Forum:
https://forums.openvpn.net/server-administration-f4.html

See the Rules at the top of the page
Regards.



----- Original Message ----- 
From: "Jeff Boyce" <jbo...@meridianenv.com>
To: <openvpn-users@lists.sourceforge.net>
Sent: Tuesday, November 24, 2015 8:13 PM
Subject: Re: [Openvpn-users] Can't ping another box behind OpenVPN server


> Thanks for that option, and the specific command relative to my network,
> although I am less comfortable with making changes in iptables than
> addressing this directly through proper routing, and I would like to
> avoid the disadvantage you mentioned.  But out of curiosity, I have also
> seen reference to using MASQ in iptables for accessing boxes behind the
> VPN server, is the SNAT command you provide just a different variation
> of that?
>
> Ok, back to my primary issue which is still not resolved.  I am
> confident this is a routing issue, and not a specific problem with
> OpenVPN, but I hope someone here can educate me and improve my knowledge
> of routing.
>
> From my original VPN setup (described in the original post) I have made
> one change, and that is to add a route on my default gateway (PfSense
> box) to redirect the VPN network traffic back out the VPN box, which
> should send it back through the tunnel to the point of origin.  But
> clearly I must be mistaken about my routing somewhere. I will summarize
> my topology again and the current routing tables.
>
> Remote client network 192.168.123.0/24
> VPN network 10.9.8.x
>
> VPN Server 10.9.8.1
> Server LAN network 192.168.112.0/24
> VPN Server LAN IP 192.168.112.50
>
> DNS/DHCP Server 192.168.112.51
> Gateway/Firewall/Router 192.168.112.11
>
> Note that my network router and the VPN are not on the same box. The
> current routing table for the gateway/router box (PfSense) shows:
>
> [2.1.2-RELEASE][ad...@pfgateway.mei.lan]/root(1): netstat -rn
> Routing tables
>
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> default            xxx.yy.190.17      UGS         1 663197177   bge0
> 10.9.8.0/24        192.168.112.50     UGS         0        0    rl0
> xxx.yy.190.16/28   link#1             U           0 49927480   bge0
> xxx.yy.190.18      link#1             UHS         0        0    lo0
> xxx.yy.190.19      link#1             UHS         0        0    lo0 =>
> xxx.yy.190.19/32   link#1             U           0        0   bge0
> xxx.yy.190.20      link#1             UHS         0        0    lo0 =>
> xxx.yy.190.20/32   link#1             U           0        0   bge0
> xxx.yy.190.21      link#1             UHS         0        0    lo0 =>
> xxx.yy.190.21/32   link#1             U           0        0   bge0
> xxx.yy.190.22      link#1             UHS         0        0    lo0 =>
> xxx.yy.190.22/32   link#1             U           0        0   bge0
> 127.0.0.1          link#6             UH          0      560    lo0
> 192.168.112.0/24   link#2             U           0 848109484    rl0
> 192.168.112.11     link#2             UHS         0 99857580    lo0
>
> The network and routing information for the VPN box shows:
> [root@sequoia ~]# ifconfig
> eth0      Link encap:Ethernet  HWaddr aa:bb:00:9D:B2:49
>           inet addr:192.168.112.50  Bcast:192.168.112.255
> Mask:255.255.255.0
>           inet6 addr: fe80::5054:ff:fe9d:b249/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:188054402 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:169321935 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:36069946217 (33.5 GiB)  TX bytes:47188246310 (43.9 GiB)
>
> < snip lo >
>
> tun0      Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>           inet addr:10.9.8.1  P-t-P:10.9.8.2  Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:9066254 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:7591995 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:1029571120 (981.8 MiB)  TX bytes:1210868888 (1.1 GiB)
>
> [root@192.168.112.50 ~]# route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 10.9.8.2        *               255.255.255.255 UH    0 0        0 tun0
> 192.168.112.0   *               255.255.255.0   U     0 0        0 eth0
> 10.9.8.0        10.9.8.2        255.255.255.0   UG    0 0        0 tun0
> link-local      *               255.255.0.0     U     1002 0        0 eth0
> default         pfgateway.mei.l 0.0.0.0         UG    0 0        0 eth0
>
> My goal is to be able to access a box (or two) behind the VPN server.
> Currently (still after making the one routing change) when trying to
> ping from a Windows client connected to the VPN server to a box behind
> the VPN server I get the following:
>
> C:\>ping 192.168.112.53
> Pinging 192.168.112.53 with 32 bytes of data:
> Reply from 10.9.8.1: Destination host unreachable.
>
> Again, direct cc's are welcome as I only get the daily digest of this
> mailing list.  Thanks.
>
> Jeff
>
>
> On 11/21/2015 2:55 AM, Morten Christensen wrote:
>> Den 19-11-2015 kl. 22:09 skrev jbo...@meridianenv.com:
>>> Greetings -
>>>
>>> I have a working OpenVPN server that I can access remotely, but now I
>>> want
>>> to access another box behind the OpenVPN server from the remote
>>> client.  I
>>> have read the how-to's and FAQ on the OpenVPN website, and I believe
>>> that
>>> I need to make one change which is described by this statement: add a
>>> route in the default gateway for the VPN network IP subnet pointing
>>> to the
>>> OpenVPN machine.
>>
>> In addition to the  fine advice's you have got until now there is a
>> simple solution, to use Snat.
>>
>> It could be a line like this in /etc/rc.local on the openvpn-server
>> (my example is ubuntu-based):
>> iptables -t nat -A POSTROUTING -s 10.8.9.0/24 -j SNAT --to 192.168.112.50
>>
>> Disadvantage is, that the vpn-clients will be kind of anonymous on
>> your network.
>>
>>> My topology
>>>
>>> Remote client network 192.168.123.0/24
>>> VPN network 10.8.9.x
>>>
>>> VPN Server 10.9.8.1
>>> Server LAN network 192.168.112.0/24
>>> VPN Server LAN IP 192.168.112.50
>>>
>>
>> -- 
>> Morten Christensen
>>
>>
>
> -- 
>
> Jeff Boyce
> Meridian Environmental
> www.meridianenv.com
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple 
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users 


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to