Page 1 of 1
[Solved] Accessing client side lan
Posted: Thu Jun 23, 2016 9:44 am
by headhunter942135
I'm trying to set up OpenVPN server but having trouble getting access to the other computers attached to the client network. Here is the scenario :
The OpenVPS server is hosted on a VPS ( with expample IP address 64.255.183.119 ). Clients that connects to the server also uses the server's Internet
Client A ( 192.168.1.10 ) connects to the VPN server and shares it's subnet ( 192.168.1.0/24 ) with all other clients which maybe connected to the VPN
Client B ( 192.168.20.20 ) connects to the VPN and wants to access an IP address in Client A's subnet but client B doesn't want to share the other IP addresses on it's own subnet ( 192.168.20.0/24 ).
I'm not able to ping or access any machines on the Client A ( 192.168.1.0/24 ) aside from Client A's own ip address ( either is 192.168.1.10 or 10.8.0.6 which is the OpenVPN assigned address ). From Client A I can ping the OpenVPN server.
Here is the server configuration file
Code: Select all
server.conf
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.235.0 255.255.255.0
client-to-client
push "route 192.168.235.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
key-direction 0
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
persist-key
persist-tun
status openvpn-status.log
verb 3
And here is the file for Client A
Re: Accessing client side lan
Posted: Thu Jun 23, 2016 10:37 am
by TinCanTech
headhunter942135 wrote:iroute 192.168.1.0 255.255.255.0
The server config needs this
route
HOWTO: Expanding the scope of the VPN to include additional machines
Re: Accessing client side lan
Posted: Thu Jun 23, 2016 1:59 pm
by headhunter942135
So if the server has an IP subnet of 10.17.15.0/24, I would need to add something like
Code: Select all
push "route 10.17.15.0 255.255.255.0 "
Re: Accessing client side lan
Posted: Thu Jun 23, 2016 2:20 pm
by TinCanTech
That would allow access from the client to the server LAN ..
Re: Accessing client side lan
Posted: Sat Jun 25, 2016 4:43 am
by headhunter942135
Corrected the server.conf file.
Code: Select all
server.conf
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.1.0 255.255.255.0
client-to-client
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
key-direction 0
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
persist-key
persist-tun
status openvpn-status.log
verb 3
and here is the corresponding ccd for client A
With the changes still can't get another computer on the same subnet as client A to access the server ( or the server to recognize the other computer on computer A's subnet ).
Client A has the following IP address 192.168.1.99 ( local address ) and 10.8.0.6 ( the address assigned by OpenVPN ). There is another computer on the same subnet as client A with local address 192.168.1.160.
On 192.168.1.160, I added the route 10.8.0.0/24 via 10.8.0.6
From the server I can ping 192.168.1.99 and 10.8.06 but if I try to ping 192.168.1.160 it times outs.
From 192.168.1.160 I can ping 192.168.1.99 and 10.8.06 but if I try to ping the server ( which is 10.8.0.1, right? ) it also gets timed out.
Re: Accessing client side lan
Posted: Sat Jun 25, 2016 12:16 pm
by TinCanTech
headhunter942135 wrote:From the server I can ping 192.168.1.99 and 10.8.06 but if I try to ping 192.168.1.160 it times outs
Add a permanent route for the vpn subnet to 192.168.1.160
Re: Accessing client side lan
Posted: Mon Jun 27, 2016 2:21 am
by headhunter942135
Tried adding permanent route but still not working. Here are the routing tables for the VPN server and Client A
VPN Server
Code: Select all
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.17.0.0 * 255.255.0.0 U 0 0 0 eth0
55.55.128.0 * 255.255.192.0 U 0 0 0 eth0
192.168.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.160 10.8.0.2 255.255.255.255 UGH 0 0 0 tun0
Client A
Code: Select all
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.17.0.0 10.8.0.5 255.255.0.0 UG 0 0 0 tun0
55.55.182.157 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Here is the routing table for the machine ( 192.168.1.160 ) that is in the same subnet as Client A but doesn't have the OpenVPN client running.
Code: Select all
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.160 276
10.8.0.0 255.255.255.0 10.8.0.6 192.168.1.160 21
10.17.0.0 255.255.0.0 192.168.1.10 192.168.1.160 21
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.160 276
192.168.1.160 255.255.255.255 On-link 192.168.1.160 276
192.168.1.255 255.255.255.255 On-link 192.168.1.160 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.160 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.160 276
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 25.0.0.1 Default
0.0.0.0 0.0.0.0 192.168.1.1 Default
===========================================================================
Re: Accessing client side lan
Posted: Mon Jun 27, 2016 1:55 pm
by TinCanTech
headhunter942135 wrote:Here is the routing table for the machine ( 192.168.1.160 ) that is in the same subnet as Client A but doesn't have the OpenVPN client running.
Code: Select all
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.160 276
This gateway is wrong .. 192.168.1.xxx where openvpn *is* running
10.8.0.0 255.255.255.0 10.8.0.6 192.168.1.160 21
10.17.0.0 255.255.0.0 192.168.1.10 192.168.1.160 21
Re: Accessing client side lan
Posted: Tue Jun 28, 2016 3:53 am
by headhunter942135
I changed it so that it now reads
Code: Select all
10.8.0.0 255.255.255.0 192.168.1.99 192.168.235.160
Still not able to access 192.168.1.160 from either the VPN server or from Client A.
Re: Accessing client side lan
Posted: Tue Jun 28, 2016 10:08 am
by TinCanTech
Have you enabled IP_Forward on the vpn client (as you do on the server) ?
Re: Accessing client side lan
Posted: Tue Jun 28, 2016 2:03 pm
by headhunter942135
Just enabled IP_forward on the VPN clients. Still can't access 192.168.1.160
Re: Accessing client side lan
Posted: Tue Jun 28, 2016 2:23 pm
by TinCanTech
headhunter942135 wrote:Just enabled IP_forward on the VPN clients
Did you enable it on the correct client .. ie: the one running openvpn/client ?
Basically, you have all the steps in place so you will have to determine at which step the packets are dropped or routed incorrectly. Also, make sure your firewalls allow such packets.
Re: Accessing client side lan
Posted: Thu Jul 07, 2016 8:53 am
by headhunter942135
Thanks. I was able to get it working by enabling IP forwarding and by adding a route to the VPN clients.
Re: Accessing client side lan
Posted: Thu Jul 07, 2016 10:20 am
by TinCanTech
Thanks for letting us know you solved this
