Topic: Customization of OpenVPN setup

[evikali]

Hi there

I wonder if it is possible to somehow change the virtual ip of the sme server that it gets when a vpn client is connected.

When a client is connected, he sees the server with this ip : 192.168.100.1  in stead of the real one: 192.168.10.3

The reason for the change is that the client have access to the server both as a normal local client on the network and also as a vpn client. Both times the client needs to access an ibay on the server from a windows pc. And I need to, somehow, make the path to the ibay the same in both situations. More simpified!

Client connected local:
Server ip: 192.168.10.3
Ibay : \\192.168.10.3\IbayName\
Network drive in windows: x:\IbayName

Client connected via VPN
Server ip: 192.168.100.1
Ibay: \\192.168.100.1\IbayName
Network drive in windows: x:\IbayName
Problem: The x drive becomes invalid due to change in server ip

I followed this setup:

http://sme.swerts-knudsen.dk/index.html?frame=http%3A//sme.swerts-knudsen.dk/howtos/howto_30.htm

Does anyone have a solution ?

[Knuddi]

You should not have problems using the local IP (192.168.10.3) even though you are connected via VPN. The OpenVPN server should route the traffic from the 192.168.100.x network to your 192.168.10.x net.


What does the command route show from shell - this is likely to be a simple routing issue.

[evikali]

This is the output from "route"


[root@webserver root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.11.0    pc-00001.lisbje 255.255.255.255 UGH   0      0        0 eth0
130.225.10.248  pc-00001.lisbje 255.255.255.248 UG    0      0        0 eth0
130.225.11.248  pc-00001.lisbje 255.255.255.248 UG    0      0        0 eth0
default         pc-00001.lisbje 255.255.255.0   UG    0      0        0 eth0
192.168.2.0     pc-00001.lisbje 255.255.255.0   UG    0      0        0 eth0
10.10.10.0      pc-00001.lisbje 255.255.255.0   UG    0      0        0 eth0
192.168.10.0    *               255.255.255.0   U     0      0        0 eth0
192.168.254.0   pc-00001.lisbje 255.255.255.0   UG    0      0        0 eth0
192.168.0.0     pc-00001.lisbje 255.255.0.0     UG    0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         pc-00001.lisbje 0.0.0.0         UG    0      0        0 eth0
[root@webserver root]#

[duncan]

Some of your routes are incorrect. Check towards the end of the howto with respect to /etc/openvpn/openvpn.up and make sure this is set up right.

[evikali]

oups!! pasted the wrong route, here is the route from the right server

Welcome to the Mitel Networks SME Server.
[root@cmsserver root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   192.168.100.1   255.255.255.0   UG    0      0        0 tap0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         pc-00001.evikal 0.0.0.0         UG    0      0        0 eth0
[root@cmsserver root]#

[duncan]

Looking at that table I am guessing that 192.168.10.3 is actually 192.168.2.3.

As Knuddi indicated - there is no reason why your remote pc shouldnt be able to connect to 192.168.2.3 (or 10.3). In fact samba only listens on the local interface for connections - so connecting to 192.168.100.1 will never work anyway.

Can you ping the SME server local interface. Perhaps your remote machine doesnt have a gateway route to the local network.

[evikali]

I cant not ping 192.168.2.85 when I connect through OpenVPN, but there is no problem pinging 192.168.100.1
(my test server has i.p. 192.168.2.85)

[dave_d]

Just to add my tuppence worth, I too am having similar problems with OpenVPN.

I've got to the point where making the VPN connection is child's play - it's using it later where things become tricky!

In my case the SME server that I'm making the connection to is operating in ServerOnly mode.  Dumb question - but does that mean that the VPN route to the SME box doesn't work?  (You'll have noticed that I'm not very good at diagnosing this routing stuff yet!!)

Having made the VPN connection I can find the server by using the Search for Computers command on the Windoze box, but having found the server I then can't access it!!  I'm guessing that this is because the IP address that the VPN terminal has is not in the normal LAN IP range and the appropriate routing is not taking place - but that's just a guess.  When I try to look at the server I get a username/password box, and whatever I enter in there results in the error message:

//<server> is not accessible. You might not have permission to use this network resource. Contact the system administrator blah, blah, blah.


Would it be better in my case if the VPN were given an IP address in the existing local network range? .. and if so, how easy is that to do?

The route command on my server presently gives me the following ....

[root@cssl-server openvpn]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   192.168.100.1   255.255.255.0   UG    0      0        0 tap0
192.168.30.0    *               255.255.255.0   U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         pc-00001.cssl.y 0.0.0.0         UG    0      0        0 eth0
[root@cssl-server openvpn]#


Regards,

Dave

[rmarshall]

dave_d,
If you search the site you will find that you need to create a route from whatever you are using as your router/gateway. I also use sme in server only mode and have forwarded the port from my linksys router to the server for openvpn. I then had to create in the linksys a static route with the server as the gateway.If you think about it, the packet forwards thru your router to your server and then out into your network. Without something pointing back there is no way for it to go back out of your network over the vpn.

[dave_d]

Thanks rmarshall!

That did the trick.  I knew that I needed another route somewhere but my brain had become completely addled after the last couple of days fighting with various flavours of VPN.

regards,

Dave