Solved

routing using openvpn to a private network

Posted on 2008-06-12
12
285 Views
Last Modified: 2010-04-09
Hello Team:

I am trying to access a private network. I have openvpn running on a Linux box, and I would like to access the LAN behind that box.  I can establish and ping the vpn tunnel, but I cannot ping any of the boxes behind the openvpn.  The network behind the vpn is 192.168.1.0. These are my configuration files for the client and for the server:

client configuration file (Linux, Centos 5.0):

client
dev tun
proto udp

remote 75.22.82.166 1194
ifconfig 10.3.0.2 10.3.0.1

route 192.168.1.0 255.255.255.0
resolv-retry infinite
nobind

persist-key
persist-tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key

tls-auth /etc/openvpn/keys/ta.key 1
cipher BF-CBC

status /var/log/openvpn-status.log
log-append /var/log/openvpn.log

comp-lzo
verb 4
;mute 20

server configuration file (Linux, Centos 5.0):

local 75.22.82.166
ifconfig 10.3.0.1 10.3.0.2

port 1194
proto udp
dev tun
daemon

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem

server 10.3.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1 eth1

keepalive 10 120

tls-auth /etc/openvpn/keys/ta.key 0

cipher BF-CBC
comp-lzo
max-clients 25
user nobody
group nobody
persist-key
persist-tun

status /var/log/openvpn-status.log

log-append  /var/log/openvpn.log
verb 4
mute 20

Now let me do some explaining:
192.168.1.0 is the network behind the vpn server that I wan to get access to.
192.168.1.1 is the gateway for the 192.168.1.0 network.

75.22.82.166 is the public IP of the box that the openvpn server is running on.
10.3.0.1 and 10.3.0.2 are the virtual IPs of the openvpn tunnel. These I can ping. However, I cannot ping any box on the 192.168.1.0 network.

Now my routing tables:

routing table for the server:

Kernel IP routing table
Destination     Gateway         Genmask               Flags Metric Ref    Use Iface
10.3.0.2           *                  255.255.255.255    UH     0        0        0   tun0
75.22.82.128    *                  255.255.255.192    U       0        0        0   eth0
192.168.1.0      *                  255.255.255.0       U       0        0        0   eth1
10.3.0.0        10.3.0.2           255.255.255.0       UG     0        0        0   tun0
269.254.0.0      *                  255.255.0.0           U      0                 0    eth1
default         75.22.82.129     0.0.0.0                  UG    0        0        0    eth0


routing table for client:


Kernel IP routing table
Destination     Gateway           Genmask               Flags  Metric Ref    Use Iface
10.3.0.1          10.3.0.5           255.255.255.255    UGH    0       0        0    tun0
10.3.0.5          *                     255.255.255.255    UH      0       0        0    tun0
192.168.1.0     *                     255.255.255.0       U        0       0        0    eth0
269.254.0.0     *                     255.255.0.0           U        0       0        0    eth0
default            192.168.1.254   0.0.0.0                 UG      0       0        0    eth0


Please someone help to figure this routing problem out.

Thanks.
--Willie
0
Comment
Question by:wbens
  • 7
  • 5
12 Comments
 
LVL 76

Expert Comment

by:arnold
ID: 21773988
Notice that the client's IP has already 192.168.1.x whcih is seen as local and not VPN bound.
You have an IP overlap.  Your LAN and the clients LAN use the same IPs.
Change the 192.168.1.x on one side and see whether you are still having a problem.


0
 

Author Comment

by:wbens
ID: 21779137
Ok arnold, I will give this a try.
I will come back with the results.
Thanks.

--Willie
0
 

Author Comment

by:wbens
ID: 21779317
I have a question though, do I have to change the IP on the client's box or just on the client.conf file?
As you can see, the client is running on a network whose IP overlaps with the private LAN behind the vpn server. Therefore, if I change the IP on the client's box, I think that would not work.

This is why I am asking the question. Or should I try connecting the client to a different network whose IP does not overlap with the private LAN behind the openvpn.

Note: No iptalbes/firewalls is running.

Thanks.
0
 
LVL 76

Expert Comment

by:arnold
ID: 21779619
You should alter The remote IP segment from 192.168.1.0/24 or alter your VPN LAN segment from 192.168.1.0/24 to something like 172.16.1.0/24.

If you make the change on the LAN side behind the server, you would need to alter the route to reflect the changed LAN IP 172.16.1.0/24.

i.e. in the server config,
you should have an entry such as
push "route 172.16.1.0 255.255.255.0"

How are you managing the NAT of eth1 and access to and from it?
0
 

Author Comment

by:wbens
ID: 21779960
No iptables/firewalls are running at the moment, this leads me to believe that I should not worry about the NAT. Please correct me if I am wrong.

It would be easier for me to alter the remote IP from the client. When you say alter, do you mean just to change it in the client.conf file or give the client box a new IP on the eth0 interface?

Thanks.
0
 
LVL 76

Expert Comment

by:arnold
ID: 21780165
The changes are needed on the physical location and not as part of the openVPN configuration.

The remote CLient system and the LAN behind the openVPN server to which the client needs to connect use the same IP segment which is a no-no.

You should worry about NAT if you expect the systems on the LAN behind your Centos server to have access to the outside or the systems connecting via VPN.

The LAN segment on the remote end or the LAN on your side need to be changed from 192.168.1.0/24 to anything else excluding 10.3.0.0/24 since this is the IP segment used for your VPN IP pool.


Changing the LAN segment on the remote side, does not require any changes.
Changing the LAN side on the server end, requires changes to the push directive to reflect the changed LAN IP Segment.

 
0
6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

 

Author Comment

by:wbens
ID: 21780261
Hello arnold:

Please excuse me if I am asking too many questions, but I just want to be clear on your answers.
When you say "The changes are needed on the physical location and not as part of the openVPN configuration", by physical do you mean on the ethernet interface?

About NAT, I have to worry about it even if no iptables/firewalls are running?

I will test your suggestions, it might take me into next week because the network administrator is not back until Tuesday for me to discuss with him about the IP change(s).

Thanks arnold.
--Willie
0
 

Author Comment

by:wbens
ID: 21780269
I will also have to do some reading about the NAT since I am not familiar with it.
0
 
LVL 76

Accepted Solution

by:
arnold earned 500 total points
ID: 21780336
The remote client can not have a 192.168.1.x IP for the LAN if your LAN is 192.168.1.x and you want the remote client to access the LAN behind the openVPN server.

To answer your question, you would need to change the LAN IPs on one side from 192.168.1.0/24 to anything else excluding the 10.3.0.0/24 IP segment.

Currently, do the LAN systems behind your openVPN server have access to the net?  Or do you have a proxy server also configured on the Centos box through which the LAN systems get out??

To have your Centos server configuration to work in a routing mode, you have to use iptables/ipchains to NAT the eth1 interface.
http://www.dslreports.com/faq/1093


0
 

Author Comment

by:wbens
ID: 21780439
The LAN behind the openvpn server is not exposed to the outside in any way. There is no proxy server and the private LAN behind the vpn is does not have access to the net.

I will look into the NAT link you provided me.

Thanks.
--Wilie
0
 

Author Comment

by:wbens
ID: 21878166
I also had to do this from the command line on the client side:

route add -host IPofPrivateHostRunningBehindopenVPN server tun0

and this on the command line on the server side, I executed the next three commands:

service iptables restart

iptables -I POSTROUTING -t nat -s 10.3.0.6 -j MASQUERADE

service iptables save

It works.
Thanks.
--Willie
0
 
LVL 76

Expert Comment

by:arnold
ID: 21882869
You should be able to configure the openvpn server to push the route out where you do not need to manually add a route.

The issue with iptables rules are different.

I presume you are still using the 192.168.1.x on both sides and using the NAT functionality of the VPN connection?
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

When you connect to your workplace's VPN, you may not notice that you are using your workplace's servers to serve up webpages.  This might be undesirable since the workplace can log all the places you've been.  It also might be very slow to load pag…
If you use NetMotion Mobility on your PC and plan to upgrade to Windows 10, it may not work unless you take these steps.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now