Welcome, Guest. Please login or register.
Did you miss your activation email?
Sunday 08 December 2024, 02:47:33 pm

Login with username, password and session length

CLICK HERE for the The official Endian Roadmap and Issue tracker
14261 Posts in 4377 Topics by 6517 Members
Latest Member: Sandro
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  VPN Support
| | |-+  OPEN VPN host route to client network failure from 2.4 to 2.4 with work around.
0 Members and 2 Guests are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: OPEN VPN host route to client network failure from 2.4 to 2.4 with work around.  (Read 20687 times)
jantram
Jr. Member
*
Offline Offline

Posts: 7


« on: Monday 21 June 2010, 02:35:48 am »

Hello all,

I have recently updated from 2.3 to 2.4 on both ends of a VPN link. I could not get VPN working and I recall seeing log entries along the lines of:

[openvpn] error from Linux command /bin/route command ( Lots of guess work here, in recreating the log entry, sorry )

The upshot of this was that the openVPN HOST did not have route data for the client end. The connection profile shows the network behind client ( 192.168.33.0/24) properly, but the route was not entered into the kernel routing table. I was able to RDP/SSH to the HOST machine from the client machine and fix the route data. I then created static route data on the host using the IP address the user is assigned. It looks like you can assign static IP numbers per user but not out of the dynamic pool, which would be a management headache for many-to-many vpn connections.

It seems like there is an issue on the OpenVPN server with not creating route data properly for reaching Gate-to-gate connections. The client endian machine was able to ping whatever it wanted, using the assigned tunnel VPN address. It would be nicer if this worked out of the box ( as it did in 2.3 ).

I hope this will help others who are having issues with openvpn on 2.4. If you have questions on this, please reply and I will try to answer any questions.

jantram


Logged
jantram
Jr. Member
*
Offline Offline

Posts: 7


« Reply #1 on: Tuesday 22 June 2010, 04:42:06 am »

So some further experimentation shows that the routing is setup correctly if you have a static IP assigned to your VPN user.

That static address cannot be part of the dynamic range for VPN connections, obviously.

Routes are created and removed on the fly and, it seems, GW-to-GW users should be configured with static IP's only.

I did not do a backup/restore when I did my 2.4 install as I was merging 3 uplinks and 3 networks, thus the VPN configation was done from notes, not a restore.
Logged
gpak-iasonas
Jr. Member
*
Offline Offline

Posts: 2


« Reply #2 on: Sunday 11 July 2010, 08:21:16 pm »

Hi There,
I also have the same issue but setting the users to have statically assigned addresses did not resolve the issue. This is the messages I get in the system log:

sudo:  openvpn  3 incorrect password attempts ; TTY=unknown ; PWD=/var/openvpn ; USER=root ; COMMAND=/usr/local/bin/remoteroute.py add gw-lackman 192.168.250.11

sudo:  openvpn  3 incorrect password attempts ; TTY=unknown ; PWD=/var/openvpn ; USER=root ; COMMAND=/usr/local/bin/setdnat.py


Simple solution for me was to just run those commands from an ssh session as root, which seems to work, but I would imagine that you would need to run these everytime a new VPN session is initiated. I will have to file a bug report on this, unless any developers are reading this and can take note of this issue! Very frustrating! Smiley

If anyone knows of a more permanent fix however, i'm all ears.
Logged
DFen
Full Member
***
Offline Offline

Posts: 46


« Reply #3 on: Monday 12 July 2010, 04:34:45 pm »

jantram

Can you check the following:
ssh on to the endian box

cat sudoers | grep 'openvpn '
You should see something like:
openvpn  ALL=NOPASSWD: /usr/local/bin/updatednsmasq.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setsnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setvpnfw.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setpolicyrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setdnat.py
Logged
gpak-iasonas
Jr. Member
*
Offline Offline

Posts: 2


« Reply #4 on: Tuesday 13 July 2010, 09:21:19 pm »

Hi DFen,
Not that i'm jantram or wanted to hijack this thread, but here's the output from mine:

root@gw-adl:/etc # cat sudoers | grep 'openvpn'
nobody  ALL=NOPASSWD: /usr/bin/openvpn-user
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpnclients.py
nobody  ALL=NOPASSWD: /etc/init.d/openvpnclient
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpn.py
openvpn  ALL=NOPASSWD: /usr/local/bin/updatednsmasq.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setsnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setvpnfw.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setpolicyrouting.py
Logged
DFen
Full Member
***
Offline Offline

Posts: 46


« Reply #5 on: Tuesday 13 July 2010, 10:45:01 pm »

Hi DFen,
Not that i'm jantram or wanted to hijack this thread, but here's the output from mine:

root@gw-adl:/etc # cat sudoers | grep 'openvpn'
~~~
openvpn  ALL=NOPASSWD: /usr/local/bin/updatednsmasq.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setsnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setvpnfw.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setpolicyrouting.py

You seem to be missing two lines:
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setdnat.py

Are you sure you have run efw-upgrade recently Grin

If you edit sudoers and add those two lines then this problem should go away. However I cannot guarantee that there isn't something else missing!

Logged
kernelbauer
Jr. Member
*
Offline Offline

Posts: 1


« Reply #6 on: Wednesday 14 July 2010, 12:09:24 am »

Hi,

Quote
You seem to be missing two lines:
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setdnat.py

Are you sure you have run efw-upgrade recently Grin

If you edit sudoers and add those two lines then this problem should go away. However I cannot guarantee that there isn't something else missing!



The two line still be there, only the user is wrong:

nobody  ALL=NOPASSWD: /usr/local/bin/remoteroute.py
nobody  ALL=NOPASSWD: /usr/local/bin/setdnat.py

changing the user to openvpn will resolve the problem.
Itīs an bug in enterprise version too.


Greets
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.125 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com