OpenVPN Support Forum

Hello,

I have a problem on new configurations :

6 2011 OpenVPN 2.1_rc20 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Oct 1 2009
Thu Feb 17 14:56:06 2011 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Thu Feb 17 14:56:06 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Feb 17 14:56:06 2011 LZO compression initialized
Thu Feb 17 14:56:06 2011 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Feb 17 14:56:06 2011 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Feb 17 14:56:06 2011 Local Options hash (VER=V4): 'd79ca330'
Thu Feb 17 14:56:06 2011 Expected Remote Options hash (VER=V4): 'f7df56b8'
Thu Feb 17 14:56:06 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Feb 17 14:56:06 2011 UDPv4 link local: [undef]
Thu Feb 17 14:56:06 2011 UDPv4 link remote: 178.xxx.xxx.xxx:1194
Thu Feb 17 14:56:06 2011 TLS: Initial packet from 178.xxx.xxx.xxx:1194, sid=ee4555c8 69c7fa5b
Thu Feb 17 14:56:06 2011 VERIFY OK: depth=1, /O=Orion/CN=Certification_Authority_Certificate
Thu Feb 17 14:56:06 2011 VERIFY X509NAME OK: /O=Orion/CN=vpn-Orion
Thu Feb 17 14:56:06 2011 VERIFY OK: depth=0, /O=Orion/CN=vpn-Orion
Thu Feb 17 14:56:07 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Feb 17 14:56:07 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Feb 17 14:56:07 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Feb 17 14:56:07 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Feb 17 14:56:07 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Feb 17 14:56:07 2011 [vpn-Orion59] Peer Connection Initiated with 178.33.22.89:1194
Thu Feb 17 14:56:09 2011 SENT CONTROL [vpn-Orion59]: 'PUSH_REQUEST' (status=1)
Thu Feb 17 14:56:10 2011 PUSH: Received control message: 'PUSH_REPLY,route 178.xxx.xxx.xxx 255.255.255.255,route-gateway 192.168.159.1,ping 10,ping-restart 120,ifconfig 192.168.159.7 255.255.255.0'
Thu Feb 17 14:56:10 2011 OPTIONS IMPORT: timers and/or timeouts modified
Thu Feb 17 14:56:10 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu Feb 17 14:56:10 2011 OPTIONS IMPORT: route options modified
Thu Feb 17 14:56:10 2011 OPTIONS IMPORT: route-related options modified
Thu Feb 17 14:56:10 2011 ROUTE default_gateway=192.168.77.1
Thu Feb 17 14:56:10 2011 TAP-WIN32 device [Connexion au réseau local 2] opened: \\.\Global\{C2D744C0-4707-439F-2CB7-08C16648F81A}.tap
Thu Feb 17 14:56:10 2011 TAP-Win32 Driver Version 9.6
Thu Feb 17 14:56:10 2011 TAP-Win32 MTU=1500
Thu Feb 17 14:56:10 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.159.7/255.255.255.0 on interface {C2D744C0-4707-439F-2CB7-08C16648F81A} [DHCP-serv: 192.168.159.0, lease-time: 31536000]
Thu Feb 17 14:56:10 2011 Successful ARP Flush on interface [14] {C2D744C0-4707-439F-2CB7-08C16648F81A}
Thu Feb 17 14:56:15 2011 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Thu Feb 17 14:56:15 2011 C:\WINDOWS\system32\route.exe ADD 178.33.22.89 MASK 255.255.255.255 192.168.159.1
Thu Feb 17 14:56:15 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu Feb 17 14:56:15 2011 Route addition via IPAPI succeeded [adaptive]
Thu Feb 17 14:56:15 2011 Initialization Sequence Completed


The connexion is starting and the ping is OK for 3 seconds on 192.168.159.1 during the end of the connexion.
At this moment : Successful ARP Flush on interface , the ping is ok
And wen the little widows is comming to say : User is now connected - Assigned IP : 192.168.159.7
The ping is stoped.
But Connexion is still active
I thing it is a route problem

Do someone have the solution ?

Thank you

you did not post your setup, but when I read the log file I see an error in your configuration:

a route is added to reach the remote machine via 192.168.159.1, yet this IP is part of the VPN subnet - that will never work.
Check your config, remove all 'route' and 'push "route"' statements that you don't need at first and then start troubleshooting. If that works, enable the route and push route statements again until it breaks: then you will know exactly what goes wrong and what to do about it.

HTH,

JJK

Sorry for my bad english..

My configuration :

Serveur Zentyal : 178.xxx.xxx.xxx
VPN address : 192.168.159.1
v^
vpn address : 192.168.159.2
client address : 192.168. 77.5



Successful ARP Flush on interface [14] {C2D741C.... At this moment, the ping is OK
The route (and the ping) is falling just after this ligne
But the vpn is still ON (green)

My server is a Zentyal (débian) behind Esxi with public adress ip in bridge
I forced the rc.local to obtain the good ip

please post your openvpn server configuration file . The thing that is broken is this:

first your client connects to the remote machine then later on a route is added this creates a routing loop. Your server configuration file most likely contains a line
Remove this line and try again.

HTH,

JJK

Hello,

Wich line must I remove and where can I remove it ? in the file.ovpn ?

Thank you.

post your server configuration and I can tell you. This is a *server* side problem, not the client side. If you have no control over the server then you're out of luck.

Well,
I'm half luky because I can use myself the server but I'm beginer in linux.
I use a Ubuntu Zentyal on a ''dedied server ovh'' in bridge.
I'm starting to learn Linux

***************************************************

I know two files to change :

1) - /etc/network/interfaces

/etc/network/interfaces
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address IP.FAIL.OVER
netmask 255.255.255.255
broadcast IP.FAIL.OVER
post-up route add IP.OF.MYPHYSICAL.254 dev eth0
post-up route add default gw IP.OF.MYPHYSICAL.254
post-down route del IP.OF.MYPHYSICAL.254 dev eth0
post-down route del default gw IP.OF.MYPHYSICAL.254

/etc/resolv.conf
nameserver 213.186.33.99

***************************************************

2) /etc/rc.local

ifconfig eth0 IP.FAIL.OVER netmask 255.255.255.255 broadcast IP.FAIL.OVER
route add IP.OF.MYPHYSICAL.254 dev eth0
route add default gw IP.OF.MYPHYSICAL.254

***************************************************

I use the rc.local because Zentyal erased the good line at restart.

But maybe it is not in this files that I must change something.

it's not - there should be a server config file present in if you did not set this up then who did?

hi there,

if you are using openvpn from zentyal's management interface,
i suggest you try posting first at their forum.

usually such appliances (untangle,zentyal,zeroshell) tend to overwrite
config files and loose any changes you manualy make..

cheers,

michael.

Well,
I found the file and I add a # before the last line wha said :
push "route 178.33.22.89 255.255.255.255"

Record, close restart and I try now.

Same result.
I can ping my server only for 3 or 4 seconds, during the end of connexion etablish.
At the real end of create of connexion, ping is lost.

It is strange to can ping for so short time.
It proove that my pc can see my server. but why so short time ?

post the server config file, and the client config file.
also, post the client log file again.
without it we're just guessing blindly as to what is going on.

This is my server conf :

EBox OpenVPN 2.0 config file for server Orion59
# Which local IP address should OpenVPN
# listen on? (optional)
# Which TCP/UDP port should OpenVPN listen on?
port 1194
# TCP or UDP server?
proto udp
# virtual device
dev tap0
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key).
ca '/var/lib/ebox/CA/cacert.pem'
cert '/var/lib/ebox/CA/certs/740019CA27EA3145.pem'
key '/var/lib/ebox/CA/private/vpn-Orion59.pem'
key '/var/lib/ebox/CA/private/vpn-Orion59.pem'
# This file should be kept secret
# check peer certificate against certificate revokation list
crl-verify /var/lib/ebox/CA/crl/latest.pem
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
#dh /etc/openvpn/dh1024.pem
dh /etc/openvpn/ebox-dh1024.pem
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
server 192.168.159.0 255.255.255.0
# Maintain a record of client <-> virtual IP address
# associations in this file.
ifconfig-pool-persist '/etc/openvpn/Orion59-ipp.txt'
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN
;push "redirect-gateway"
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# Uncomment this directive to allow different
# clients to be able to "see" each other.
client-to-client
# The keepalive directive causes ping-like
# messages to be sent back and forth over
keepalive 10 120
# client certificate common name authentication
# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
;tls-auth ta.key 0 # This file is secret
# to help block DoS attacks and UDP port flooding.
;tls-auth ta.key 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# group and user for the OpenVPN
# daemon's privileges after initialization.
user nobody
group nogroup
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status '/var/log/ebox/openvpn/status-Orion59.log'
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
log-append '/var/log/ebox/openvpn/Orion59.log'
# Set the appropriate level of log
# file verbosity.
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
push "route 178.xxx.xxx.x89 255.255.255.255"

****************************************************************
The Server Ifconfig

Link encap:Ethernet HWaddr 00:50:56:0c:77:d7
inet addr:178.xxx.xxx.x89 Bcast:178.xxx.xxx.x89 Mask:255.255.255.255
inet6 addr: fe80::250:56ff:fe0c:77d7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1269 errors:0 dropped:0 overruns:0 frame:0
TX packets:7501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:98913 (98.9 KB) TX bytes:1160314 (1.1 MB)
Interrupt:18 Base address:0x2000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:91424 errors:0 dropped:0 overruns:0 frame:0
TX packets:91424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:13405662 (13.4 MB) TX bytes:13405662 (13.4 MB)

tap0 Link encap:Ethernet HWaddr de:fd:8d:c3:19:71
inet addr:192.168.159.1 Bcast:192.168.159.255 Mask:255.255.255.0
inet6 addr: fe80::dcfd:8dff:fec3:1971/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2994 (2.9 KB) TX bytes:2270 (2.2 KB)


****************************************************************
/etc/network/interfaces

auto lo eth0

iface lo inet loopback
iface eth0 inet static
address 178.xxx.xxx.x89
netmask 255.255.255.255
broadcast 178.xxx.xxx.x89
gateway 178.xxx.xxx.x89 <--this is a bad ip for a good gw but forced by zentyal. That why I have rc.local


****************************************************************

/etc/rc.local

#!/bin/sh
initctl emit zentyal-lxdm
ifconfig eth0 178.xxx.xxx.x89 netmask 255.255.255.255 broadcast 178.xxx.xxx.x89
route add 91.xxx.xxx.254 dev eth0 <-- 91.xxx.xxx.x96 is the IP of my physical serveur in bridge
route add default gw 91.xxx.xxx.254
exit 0

****************************************************************

And to resum, before to start the VPN, I open a "ping 192.168.159.1 -t''
The ping respond OK for 1 or 2 or 3 times at this moment of VPN opening :
Fri Feb 18 14:24:17 2011 Successful ARP Flush on interface [14] {C2D741C0-4707-439F-8CB7-08C1

Just when the VPN is open, the ping is lost.
Are this informations enought to find the problem ?

In the openvpn.conf :
I enter in sudo
I erase the line : push "route 178.33.22.89 255.255.255.255"
confirm the change.
Restart the VM
But after restart, this line is coming back.

remove the line, don't restart the entire vm
try
/etc/init.d/openvpn restart

HTH,

JJK

Same result.

The ping is coming at a little moment but lost when the vpn is ON.
Why can i ping 192.168.159.1 for so short time ?
The route is good at a moment...

I could read very fast :
''closing socket''
The ping was OK at this moment and lost just after

hmmm perhaps it is time to ask on the Zentyal forums - this definitely sounds like a screwup on their end ...
is the 'push route' line back again? what does the client connection log show?

Well, the push route didn't stay after your post.
Restart only openvpn was ok
But for the moment the result is the same.
The first idea I was it was a problem of IP configuration because
- On the same machine in a local network (192.168.1.0) behind a router, everythink is all right. So easy !
- On the machine with Public IP 91.xxx.xxx.xxx netmak 255.255.255.255 I have a problem of routes

I could not fine any answer on Zentyal forum.

I have the impression to be so near of the solution and to turn all around since so long time...

After new tests :

I can ping and see shared folders of server but I must before it :

Add a new forced gw (192.168.159.1 wich is the vpn address of the server) to the TAP card of my machine
route add IP.DIFUSED.LANFROMSERVER MASK 255.255.255.252 192.168.159.1
route delete IP.DIFUSED.LANFROMSERVER MASK 255.255.255.252 192.168.159.1

And after it it is ok

Strange.

If I don't do it, I only ping 3 or 4 times at the end of VPN creation and after it is : Impossible to join....