No route between VPN clients after upgrade to 2.4.1 version

[Guest]

[rm123]

How to fix push routes problem after efw-upgrade (2.4.0 -> 2.4.1). I can not ping between vpn clients (client2 to client3) and also can not ping to orange zone (client2 to server1). Before upgrade everything worked fine

schema:

server1 (orange zone)
            |
client1 - EFW OpenVPN server - internet - EFW OpenVPN gw2gw client - client2
                             - internet - EFW OpenVPN gw2gw client - client3

[bautzen]

Hi rm123, I've a similar issue after upgrade to 2.4.1!!!!

my scenario:

LAN (10.1.0.0/16) ----- EFW (10.1.0.254/16) with OpenVPN (10.3.0.254/16) ---- VPN Clients (OpenVPN GUI 1.0.3)

Before upgrade:
- VPN Clients connect to EFW and correctly reached remote LAN (10.1.0.0/16) and other VPN Clients (10.3.0.0/16) and the gateway pushed was correct: 10.3.0.254!!!

After upgrade to 2.4.1:
- VPN Clients connect to EFW and are not more able to ping nothing!!! I have noticed by OpenVPN GUI log this "strange" thing for me:

'PUSH_REQUEST' (status=1)
Thu Nov 04 01:26:07 2010 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.3.0.0,route 10.1.0.0 255.255.0.0,route 10.3.0.0 255.255.0.0,route-gateway 10.3.0.0,ping 8,ping-restart 30,dhcp-option DNS 10.1.0.6,dhcp-option DNS 10.1.0.6,ifconfig 10.3.0.150 255.255.0.0'
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: route options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: route-related options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 04 01:26:08 2010 ROUTE default_gateway=192.168.181.10
Thu Nov 04 01:26:08 2010 TAP-WIN32 device [LAN-VPN] opened: \\.\Global\{37F78672-BCA7-4ED8-B986-D00091807684}.tap
Thu Nov 04 01:26:08 2010 TAP-Win32 Driver Version 9.6
Thu Nov 04 01:26:08 2010 TAP-Win32 MTU=1500
Thu Nov 04 01:26:08 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.3.0.150/255.255.0.0 on interface {37F78672-BCA7-4ED8-B986-D00091807684} [DHCP-serv: 10.3.0.0, lease-time: 31536000]
Thu Nov 04 01:26:08 2010 Successful ARP Flush on interface [3] {37F78672-BCA7-4ED8-B986-D00091807684}
Thu Nov 04 01:26:13 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Nov 04 01:26:13 2010 C:\WINDOWS\system32\route.exe ADD 10.1.0.0 MASK 255.255.0.0 10.3.0.0
Thu Nov 04 01:26:13 2010 Route addition via IPAPI succeeded [adaptive]
Thu Nov 04 01:26:13 2010 C:\WINDOWS\system32\route.exe ADD 10.3.0.0 MASK 255.255.0.0 10.3.0.0
Thu Nov 04 01:26:14 2010 Route addition via IPAPI succeeded [adaptive]
Thu Nov 04 01:26:14 2010 Initialization Sequence Completed
Thu Nov 04 02:26:05 2010 TLS: soft reset sec=0 bytes=450013/0 pkts=3559/0
Thu Nov 04 02:26:05 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Nov 04 02:26:06 2010 VERIFY OK: depth=1, /C=IT/O=efw/CN=efw_CA
Thu Nov 04 02:26:06 2010 VERIFY OK: depth=0, /C=IT/O=efw/CN=127.0.0.1
Thu Nov 04 02:26:07 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 04 02:26:07 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 04 02:26:07 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 04 02:26:07 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 04 02:26:07 2010 Control Channel: T

the routing gateway it's not a single IP but a network range (10.3.0.0)

in the picture below I have a print screen of the routing table of the vpn client

ALL work again if I delete the route for the 10.1.0.0 and 10.3.0.0 and I manually add: route ADD 10.1.0.0 MASK 255.255.0.0 10.3.0.254   as It was before upgrade


I have noticed that Openvpn.conf it's generated from a template
here is paste a part of the openvpn.conf

; tunnel configuration

dev tap0
; bridge to GREEN
server-bridge 10.3.0.0 255.255.0.0 10.3.0.150 10.3.0.200
push "route-gateway 10.3.0.0"

push "route 10.1.0.0 255.255.0.0"
push "route 10.3.0.0 255.255.0.0"

passtos
comp-lzo
management 127.0.0.1 5555
keepalive 8 30


I have just tried to "force" the variable "push route-gateway" to 10.3.0.254 but without success. On the client side nothing change

thank to all

Patrick

[bautzen]

Hi I have found a OpenVPN client log THAT WORKED perfectly before upgrade to 2.4.1:

Wed Sep 22 11:58:35 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 12 2009
Wed Sep 22 11:58:35 2010 WARNING: No server certificate verification method has been enabled.  See openvpn.net/howto.html#mitm for more info.
Wed Sep 22 11:58:35 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Sep 22 11:58:36 2010 LZO compression initialized
Wed Sep 22 11:58:36 2010 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Sep 22 11:58:36 2010 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Sep 22 11:58:36 2010 Local Options hash (VER=V4): '31fdf004'
Wed Sep 22 11:58:36 2010 Expected Remote Options hash (VER=V4): '3e6d1056'
Wed Sep 22 11:58:36 2010 Attempting to establish TCP connection with 79.54.181.195:1827
Wed Sep 22 11:58:57 2010 TCP: connect to 79.54.181.195:1827 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)
Wed Sep 22 11:59:02 2010 TCP connection established with 79.54.181.195:1827
Wed Sep 22 11:59:02 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Sep 22 11:59:02 2010 TCPv4_CLIENT link local: [undef]
Wed Sep 22 11:59:02 2010 TCPv4_CLIENT link remote: 79.54.181.195:1827
Wed Sep 22 11:59:02 2010 TLS: Initial packet from 79.54.181.195:1827, sid=18100bdc 46c24d9a
Wed Sep 22 11:59:02 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Sep 22 11:59:03 2010 VERIFY OK: depth=1, /C=IT/O=efw/CN=efw_CA
Wed Sep 22 11:59:03 2010 VERIFY OK: depth=0, /C=IT/O=efw/CN=127.0.0.1
Wed Sep 22 11:59:04 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Sep 22 11:59:04 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 22 11:59:04 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Sep 22 11:59:04 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 22 11:59:04 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Sep 22 11:59:04 2010 [127.0.0.1] Peer Connection Initiated with 79.54.181.195:1827
Wed Sep 22 11:59:06 2010 SENT CONTROL [127.0.0.1]: 'PUSH_REQUEST' (status=1)
Wed Sep 22 11:59:06 2010 PUSH: Received control message: 'PUSH_REPLY,ifconfig 10.3.0.150 255.255.0.0,dhcp-option DNS 10.1.0.6,dhcp-option DNS 10.1.0.6,ping-restart 30,ping 8,route-gateway 10.3.0.254,route 10.3.0.0 255.255.0.0,route 10.1.0.0 255.255.0.0,route-gateway 10.3.0.254'
Wed Sep 22 11:59:06 2010 OPTIONS IMPORT: timers and/or timeouts modified
Wed Sep 22 11:59:06 2010 OPTIONS IMPORT: --ifconfig/up options modified
Wed Sep 22 11:59:06 2010 OPTIONS IMPORT: route options modified
Wed Sep 22 11:59:06 2010 OPTIONS IMPORT: route-related options modified
Wed Sep 22 11:59:06 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Sep 22 11:59:06 2010 ROUTE default_gateway=192.168.181.10
Wed Sep 22 11:59:06 2010 TAP-WIN32 device [LAN-VPN] opened: \\.\Global\{37F78672-BCA7-4ED8-B986-D00091807684}.tap
Wed Sep 22 11:59:06 2010 TAP-Win32 Driver Version 9.6
Wed Sep 22 11:59:06 2010 TAP-Win32 MTU=1500
Wed Sep 22 11:59:06 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.3.0.150/255.255.0.0 on interface {37F78672-BCA7-4ED8-B986-D00091807684} [DHCP-serv: 10.3.0.0, lease-time: 31536000]
Wed Sep 22 11:59:06 2010 Successful ARP Flush on interface [3] {37F78672-BCA7-4ED8-B986-D00091807684}
Wed Sep 22 11:59:11 2010 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Wed Sep 22 11:59:11 2010 Route: Waiting for TUN/TAP interface to come up...
Wed Sep 22 11:59:14 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Sep 22 11:59:14 2010 C:\WINDOWS\system32\route.exe ADD 10.3.0.0 MASK 255.255.0.0 10.3.0.254
Wed Sep 22 11:59:14 2010 Route addition via IPAPI succeeded [adaptive]
Wed Sep 22 11:59:14 2010 C:\WINDOWS\system32\route.exe ADD 10.1.0.0 MASK 255.255.0.0 10.3.0.254
Wed Sep 22 11:59:14 2010 Route addition via IPAPI succeeded [adaptive]
Wed Sep 22 11:59:14 2010 Initialization Sequence Completed


This one is after upgrade to 2.4.1

Thu Nov 04 01:26:01 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 12 2009
Thu Nov 04 01:26:01 2010 WARNING: No server certificate verification method has been enabled.  See openvpn.net/howto.html#mitm for more info.
Thu Nov 04 01:26:01 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Nov 04 01:26:02 2010 LZO compression initialized
Thu Nov 04 01:26:02 2010 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Nov 04 01:26:03 2010 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Nov 04 01:26:03 2010 Local Options hash (VER=V4): '31fdf004'
Thu Nov 04 01:26:03 2010 Expected Remote Options hash (VER=V4): '3e6d1056'
Thu Nov 04 01:26:03 2010 Attempting to establish TCP connection with 95.233.5.77:1827
Thu Nov 04 01:26:03 2010 TCP connection established with 95.233.5.77:1827
Thu Nov 04 01:26:03 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Nov 04 01:26:03 2010 TCPv4_CLIENT link local: [undef]
Thu Nov 04 01:26:03 2010 TCPv4_CLIENT link remote: 95.233.5.77:1827
Thu Nov 04 01:26:03 2010 TLS: Initial packet from 95.233.5.77:1827, sid=6eafab82 987b5b00
Thu Nov 04 01:26:03 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Nov 04 01:26:04 2010 VERIFY OK: depth=1, /C=IT/O=efw/CN=efw_CA
Thu Nov 04 01:26:04 2010 VERIFY OK: depth=0, /C=IT/O=efw/CN=127.0.0.1
Thu Nov 04 01:26:05 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 04 01:26:05 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 04 01:26:05 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 04 01:26:05 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 04 01:26:05 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 04 01:26:05 2010 [127.0.0.1] Peer Connection Initiated with 95.233.5.77:1827
Thu Nov 04 01:26:07 2010 SENT CONTROL [127.0.0.1]: 'PUSH_REQUEST' (status=1)
Thu Nov 04 01:26:07 2010 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.3.0.0,route 10.1.0.0 255.255.0.0,route 10.3.0.0 255.255.0.0,route-gateway 10.3.0.0,ping 8,ping-restart 30,dhcp-option DNS 10.1.0.6,dhcp-option DNS 10.1.0.6,ifconfig 10.3.0.150 255.255.0.0'
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: route options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: route-related options modified
Thu Nov 04 01:26:07 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 04 01:26:08 2010 ROUTE default_gateway=192.168.181.10
Thu Nov 04 01:26:08 2010 TAP-WIN32 device [LAN-VPN] opened: \\.\Global\{37F78672-BCA7-4ED8-B986-D00091807684}.tap
Thu Nov 04 01:26:08 2010 TAP-Win32 Driver Version 9.6
Thu Nov 04 01:26:08 2010 TAP-Win32 MTU=1500
Thu Nov 04 01:26:08 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.3.0.150/255.255.0.0 on interface {37F78672-BCA7-4ED8-B986-D00091807684} [DHCP-serv: 10.3.0.0, lease-time: 31536000]
Thu Nov 04 01:26:08 2010 Successful ARP Flush on interface [3] {37F78672-BCA7-4ED8-B986-D00091807684}
Thu Nov 04 01:26:13 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Nov 04 01:26:13 2010 C:\WINDOWS\system32\route.exe ADD 10.1.0.0 MASK 255.255.0.0 10.3.0.0
Thu Nov 04 01:26:13 2010 Route addition via IPAPI succeeded [adaptive]
Thu Nov 04 01:26:13 2010 C:\WINDOWS\system32\route.exe ADD 10.3.0.0 MASK 255.255.0.0 10.3.0.0
Thu Nov 04 01:26:14 2010 Route addition via IPAPI succeeded [adaptive]
Thu Nov 04 01:26:14 2010 Initialization Sequence Completed


The only thing that is changed is the EFW to 2.4.1

Please help me to understand what is wrong

thnaks

Patrick

[bautzen]

Hi IMHO the problem could be here:

/var/openvpn/user.tmpl

under /var/openvpn/clients/ there are several files each one for each OpenVPN client account. These are generated from a template. So if I edit the file 'vpn1' (name of a VPN account) I see something like this:

; this file has been automatically generated using the template
; /var/openvpn/user.tmpl written to /var/openvpn/clients/vpn1
; server is on GREEN

; no explicit routes to push

;push openvpn networks of other users

; push only global dns server(s)
push "dhcp-option DNS 10.1.0.6"
push "dhcp-option DNS 10.1.0.6"

So if here I add this line:
push "route-gateway 10.3.0.254"

...... et voilà ...   all return to work correctly!!!

OpenVPN Client receive the right routing rule!!!

Could someone help me to modify the template? In efw 2.4.0 the same file is written using different variables so I can't use it

[bautzen]

I am so stupid that I am not able to modify correctly the user.tmpl!!!

so for now I have solved the issue adding the directive: push "route-gateway 10.3.0.254" at the end of the file so every time I have to reboot the firewall or the OpenVPN service the conf files generated from the template will be correct.

I have also notice in the OpenVPN GUI that they are added few more options like: force routing to Blue or Orange net. Maybe it's here the main difference from previous version. But If someone have to force the routing to GREEN zone??? Basically they have thought to use the BRIDGE system to access the GREEN net but on this side my efw has 2 IP (10.1.0.254 and alias 10.3.0.254 with DHCP scope used for my Remote clients). Then used BLUE zone as Wifi and Test-Lan and ORANGE as DMZ for some special publishing.

I don't know I'm confused

Best regards

[bautzen]

Hi to all, has none encured on this routing error during vpn negotiation?

strange... only to me!!

best regards

Patrick