Ticket #1160 (closed bug: moreinfoneeded)

Opened 14 months ago

Last modified 7 months ago

OpenVPN routing problem

Reported by: jrcresawn@… Owned by:
Priority: normal Milestone: Firmware 2.3.7.0
Component: fon-plugin-openvpn Version: 2.3.7.0 beta2
Severity: unknown
Cc: Hardware: 2.0n (FON2300)

Description

I am unable to route traffic through OpenVPN on my Fonera 2.0n to a server on my internal network. Each time I connect my Linux laptop the tun0 interface is configured like this:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:10 overruns:0 frame:0 TX packets:37 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:2400 (2.4 KB)

But the surprising thing is that the /tmp/ipp.txt file doesn't have a matching IP address in it.

root@Fonera:~# cat /tmp/ipp.txt ryan,10.8.0.4

This doesn't make sense to me. Shouldn't the IP address in /tmp/ipp.txt be 10.8.0.6?

Thanks, Ryan

Attachments

Change History

Changed 14 months ago by jrcresawn@…

Since I upgraded from the stable firmware 2.3.6.1 to 2.3.7.0 beta 2 DEV should I perform a reset to factory defaults on the router to help with this routing problem?

Changed 14 months ago by matthijs

  • status changed from new to infoneeded

A factory reset shouldn't be needed (though you could try it, just in case).

If you generated the openvpn config files before upgrading to the beta, you might want to try regenerating them (just click the download link in the dashboard again).

About the ipp.txt, I'm not entirely sure what that should contain. It could very well be that OpenVPN really allocates three addresses for each connection, which would make the ipp.txt correct.

As for the real problem: You say you can't access a server on the network behind the Fonera? Can you access the Fonera itself? Did you enable local network access (under "Manage security settings" in the OpenVPN page)?

If that doesn't help, could you provide the output of the route -n command on both the Fonera and your laptop after setting up the OpenVPN connection? (don't forget to use the {{{ syntax when pasting the output into trac, as described  here).

Changed 14 months ago by jrcresawn@…

Thanks for the feedback!

  1. I will not perform a factory reset at this time.
  2. I generated the OpenVPN configuration after upgrading from the stable release to the beta.
  3. I don't believe I had the option to generate OpenVPN configuration files with the stable release.
  4. I'll ignore /tmp/ipp.txt.
  5. If I am on my home network (192.168.10.0/24) then I can access another computer on my home network. So, connections from 192.168.10.11 to 192.168.10.10 work fine. If I am outside my home network and am connected, or not connected, to the OpenVPN server on the Fonera I cannot connect to any computer on my home network.
  6. I can access the Fonera from a computer on my home network. I cannot access the Fonera from outside my home network.
  7. Yes, I enabled local network access (under "Manage security settings" in the OpenVPN page).
  8. Here is the output of route -n on the Fonera: 
    root@Fonera:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun-ovpn
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun-ovpn
72.200.124.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br-lan
0.0.0.0         72.200.124.1    0.0.0.0         UG    0      0        0 eth0.2
  9. Finally, here is the output of route PRINT -4 on my Windows 7 virtual machine while connected to the OpenVPN server running on the Fonera: 
    ===========================================================================
Interface List
 15...00 ff 65 4c 91 d7 ......TAP-Win32 Adapter V9
 11...52 54 00 be f6 8d ......Red Hat VirtIO Ethernet Adapter
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft 6to4 Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     150.135.40.1    150.135.40.13    266
         10.8.0.4  255.255.255.252         On-link          10.8.0.6    286
         10.8.0.6  255.255.255.255         On-link          10.8.0.6    286
         10.8.0.7  255.255.255.255         On-link          10.8.0.6    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
     150.135.40.0    255.255.252.0         On-link     150.135.40.13    266
    150.135.40.13  255.255.255.255         On-link     150.135.40.13    266
   150.135.43.255  255.255.255.255         On-link     150.135.40.13    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     150.135.40.13    266
        224.0.0.0        240.0.0.0         On-link          10.8.0.6    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     150.135.40.13    266
  255.255.255.255  255.255.255.255         On-link          10.8.0.6    286
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0     150.135.40.1  Default 
===========================================================================

So the problem is that I cannot use PuTTY to connect to an SSH server running on 192.168.10.10 after I have connected to the OpenVPN server running on the Fonera. I look forward to any response you may have to this frustrating problem. Again, thank you!

Changed 14 months ago by matthijs

Thanks for your detailed answers.

Looking at the route PRINT output from your OpenVPN client, I don't see any routes for 192.168.10.1, which should be there (I also presume this is the reason it doesn't work).

Could you see if you can access the Fonera webinterface using  http://10.8.0.4 ?

Also, I think that the OpenVPN client keeps a logfile of what happens when connecting (it should be available through the systray icon somehow. IIRC there's an option there that opens a window containing the log output / debug log). Could you see if you can find that one and paste the contents here? If you can't find it, just leave a comment and I'll boot a Windows machine to double-check where to find the log.

Changed 14 months ago by jrcresawn@…

I see there is no route to 192.168.10.1 which does explain why I can't connect to 192.168.10.10. I am not able to access  http://10.8.0.4/ . This is my FONERA.log: 

Fri Mar 16 11:04:42 2012 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Mar 16 11:04:42 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Mar 16 11:04:42 2012 LZO compression initialized
Fri Mar 16 11:04:42 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Mar 16 11:04:42 2012 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Mar 16 11:04:42 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Mar 16 11:04:42 2012 Local Options hash (VER=V4): '41690919'
Fri Mar 16 11:04:42 2012 Expected Remote Options hash (VER=V4): '530fdded'
Fri Mar 16 11:04:42 2012 UDPv4 link local: [undef]
Fri Mar 16 11:04:42 2012 UDPv4 link remote: 72.200.124.9:1194
Fri Mar 16 11:04:42 2012 TLS: Initial packet from 72.200.124.9:1194, sid=90b5b75f 3b45e715
Fri Mar 16 11:04:42 2012 VERIFY OK: depth=1, /C=DE/ST=DE/L=Hamburg/O=Fonera/CN=Fonera/emailAddress=me@myhost.mydomain
Fri Mar 16 11:04:42 2012 VERIFY OK: nsCertType=SERVER
Fri Mar 16 11:04:42 2012 VERIFY OK: depth=0, /C=DE/ST=DE/L=Hamburg/O=Fonera/CN=Fonera/emailAddress=me@myhost.mydomain
Fri Mar 16 11:04:43 2012 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Mar 16 11:04:43 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 16 11:04:43 2012 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Mar 16 11:04:43 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 16 11:04:43 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Mar 16 11:04:43 2012 [Fonera] Peer Connection Initiated with 72.200.124.9:1194
Fri Mar 16 11:04:45 2012 SENT CONTROL [Fonera]: 'PUSH_REQUEST' (status=1)
Fri Mar 16 11:04:45 2012 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Fri Mar 16 11:04:45 2012 OPTIONS IMPORT: timers and/or timeouts modified
Fri Mar 16 11:04:45 2012 OPTIONS IMPORT: --ifconfig/up options modified
Fri Mar 16 11:04:45 2012 OPTIONS IMPORT: route options modified
Fri Mar 16 11:04:45 2012 ROUTE default_gateway=150.135.40.1
Fri Mar 16 11:04:45 2012 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{654C91D7-413E-4FB7-B22A-95A4CB86C928}.tap
Fri Mar 16 11:04:45 2012 TAP-Win32 Driver Version 9.9 
Fri Mar 16 11:04:45 2012 TAP-Win32 MTU=1500
Fri Mar 16 11:04:45 2012 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {654C91D7-413E-4FB7-B22A-95A4CB86C928} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Fri Mar 16 11:04:45 2012 Successful ARP Flush on interface [20] {654C91D7-413E-4FB7-B22A-95A4CB86C928}
Fri Mar 16 11:04:50 2012 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Fri Mar 16 11:04:50 2012 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Fri Mar 16 11:04:50 2012 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Fri Mar 16 11:04:50 2012 Route addition via IPAPI succeeded [adaptive]
Fri Mar 16 11:04:50 2012 Initialization Sequence Completed
Fri Mar 16 11:41:22 2012 TCP/UDP: Closing socket
Fri Mar 16 11:41:22 2012 C:\WINDOWS\system32\route.exe DELETE 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Fri Mar 16 11:41:22 2012 Route deletion via IPAPI succeeded [adaptive]
Fri Mar 16 11:41:22 2012 Closing TUN/TAP interface
Fri Mar 16 11:41:22 2012 SIGTERM[hard,] received, process exiting

Changed 14 months ago by matthijs

Ok, it seems that OpenVPN is somehow not even trying to push the route. Could you run the following three commands on your Fonera to see what's up? 

root@Fonera:~# cat /etc/config/openvpn 
root@Fonera:~# cat /var/.uci/openvpn 
root@Fonera:~# cat /proc/$(ps aux|grep openvpn|grep -v grep | sed 's/ *\([0-9]*\).*/\1/')/cmdline

The output of the last one is probably a bit messed up for lack of spaces, but it's useful enough.

The client does not need to be connected while running these commands (but it doesn't hurt either).

Changed 14 months ago by jrcresawn@…

Here is the output of the commands you asked me to run. Thanks for continuing to investigate this. 

root@Fonera:~# cat /etc/config/openvpn

config 'openvpn' 'openvpn'
	option 'port' '1194'
	option 'proto' 'udp'
	option 'dev' 'tun-ovpn'
	option 'ca' '/etc/openvpn/keys/ca.crt'
	option 'cert' '/etc/openvpn/keys/Fonera.crt'
	option 'key' '/etc/openvpn/keys/Fonera.key'
	option 'dh' '/etc/openvpn/keys/dh1024.pem'
	option 'server' '10.8.0.0 255.255.255.0'
	option 'ifconfig_pool_persist' '/tmp/ipp.txt'
	option 'keepalive' '10 120'
	option 'comp_lzo' '1'
	option 'max_clients' '2'
	option 'persist_key' '1'
	option 'persist_tun' '1'
	option 'verb' '3'
	option 'status' '/tmp/openvpn.clients 15'
	option 'status_version' '2'
	option 'lan' '1'
	option 'wan' '0'
	option 'enable' '1'

config 'client' 'ryan'
	option 'name' 'ryan'

root@Fonera:~# cat /var/.uci/openvpn
root@Fonera:~# cat /proc/$(ps aux|grep openvpn|grep -v grep | sed 's/ *\([0-9]*\
).*/\1/')/cmdline
/usr/sbin/openvpn--syslogopenvpn(openvpn)--writepid/var/run/openvpn-openvpn.pid--comp-lzo--persist-key--persist-tun--ca/etc/openvpn/keys/ca.crt--cert/etc/openvpn/keys/Fonera.crt--devtun-ovpn--dh/etc/openvpn/keys/dh1024.pem--ifconfig-pool-persist/tmp/ipp.txt--keepalive10120--key/etc/openvpn/keys/Fonera.key--max-clients2--port1194--protoudp--server10.8.0.0255.255.255.0--status/tmp/openvpn.clients15--status-version2--verb3--pushroute 192.168.10.0 255.255.255.0root@Fonera:~#

Changed 14 months ago by matthijs

Hm, weird. The --pushroute option is present, so that's not the problem either. I wonder if there is anything in the client configuration that could break this. Could you paste the FONERA.ovpn config file you are using? You might want to doublecheck if there is not sensitive data in there (IIRC there isn't, but better check nonetheless).

Changed 14 months ago by jrcresawn@…

I'm pretty sure none of this is sensitive: 

client
dev tun
proto udp
remote 72.200.124.9 1194
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
ca ca_ryan.crt
cert ryan.crt
key ryan.key
ns-cert-type server
comp-lzo
verb 3
float

Changed 14 months ago by matthijs

  • status changed from infoneeded to investigate
  • milestone set to Firmware 2.3.7.0

That looks ok at first glance as well...

I've exausted my easy debug options for now: I'll have to actually try and see if I can reproduce your problem on (Windows) client here locally. That'll require some more time from my end, so I'll get back on this later (hopefully not so much later, but I'm busy with some other things first).

I'll get back to you when I know more!

Changed 12 months ago by matthijs

  • status changed from investigate to infoneeded

I've done some testing with my 2.0n and could not reproduce the problem here. I tried using a Linux, Windows XP and Windows 7 client and all worked like they should. Some more thoughts:

  1. Perhaps the OpenVPN server was not properly restarted at some point and the problem has gone away already? Or are you still seeing this problem?
  2. Does the problem still occur when you use the latest svn trunk version? I don't think there have been relevant OpenVPN changes since beta2, but it would be good to double check just in case. The latest version (just finished compiling) can be downloaded from  http://download.fonosfera.org /auto-builds/fon-ng/fon-ng-r2056/fonera2n/
  3. Does the problem occur with all clients, or just with Windows 7 clients or perhaps just with this particular client? You mentioned a linux client in your initial post?

The best way to determine if the problem occurs is to look for this line in the connect log: 

PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'

If this line contains a mention of 192.168.10.1, the problem does not occur (I'm saying this because just seeing of you can connect to the network might not work if there is some other problem as well, so best to keep the debugging conclusions accurate).

Changed 12 months ago by matthijs

I just committed an update to include a newer version (2.2.2) of OpenVPN in the firmware, so you should probably test with that version instead:  http://download.fonosfera.org/auto-builds/fon-ng/fon-ng-r2060/fonera2n/

Thanks!

Changed 7 months ago by matthijs

  • status changed from infoneeded to closed
  • resolution set to moreinfoneeded

I'm closing this issue for lack of a response. If this issue is still relevant, feel free to leave a comment.

Add/Change #1160 (OpenVPN routing problem)

Author


E-mail address and user name can be saved in the Preferences.


Action
as closed
 
Note: See TracTickets for help on using tickets.