• April 18, 2024, 06:03:07 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Author Topic: OpenVPN Issues  (Read 7398 times)

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
OpenVPN Issues
« on: August 04, 2016, 11:49:25 AM »
Hi everyone:

I have a DSR-250N, running Firmware 2.11WW, and I have been fighting with it for the last 3 weeks to get it working as a VPN "server" for remote clients to connect to. I have a mix of iPhones, Androids, and laptops to test with. I have tried IPSec, IPSec with L2TP, and OpenVPN, and so far the only thing that has gotten past the connection stage is OpenVPN. I can connect fine with OpenVPN, I get an address, and the tunnel looks to be completely up, but the traffic doesn't go anywhere. I look at my routing table, and I see addresses propogated from the remote site to my local windows machine, but I can't ping anything at the remote site.

I have tried from my own commercial network, and from a "normal" wireless router, and had no success getting traffic to go.

The remote site is running commercial grade cable, with a public IP and no filtering by the ISP. 

I have tried slipt tunnel mode, and full tunnel mode, and had no success either way.

Has anyone successfully had OpenVPN working on one of these devices, and if so, what did you have to do to get it working?..

Remote network has 192.168.1.0 and 192.168.2.0 subnets, VPN network is 192.168.5.0, and my local network is 192.168.3.0. Routing table after OpenVPN comes up looks like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.3.1    192.168.3.101     25
        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
      169.254.0.0      255.255.0.0         On-link   169.254.215.229     21
      169.254.0.0      255.255.0.0         On-link    169.254.220.88     21
      169.254.0.0      255.255.0.0    169.254.62.85   169.254.220.88     21
      169.254.0.0      255.255.0.0  169.254.215.229   169.254.220.88     21
      169.254.0.0      255.255.0.0    169.254.62.85  169.254.215.229     21
      169.254.0.0      255.255.0.0   169.254.220.88  169.254.215.229     21
      169.254.0.0      255.255.0.0         On-link   169.254.171.176    261
      169.254.0.0      255.255.0.0    169.254.62.85  169.254.171.176      6
      169.254.0.0      255.255.0.0  169.254.215.229  169.254.171.176      6
      169.254.0.0      255.255.0.0   169.254.220.88  169.254.171.176      6
  169.254.171.176  255.255.255.255         On-link   169.254.171.176    261
  169.254.215.229  255.255.255.255         On-link   169.254.215.229    276
   169.254.220.88  255.255.255.255         On-link    169.254.220.88    276
  169.254.255.255  255.255.255.255         On-link   169.254.215.229    276
  169.254.255.255  255.255.255.255         On-link    169.254.220.88    276
  169.254.255.255  255.255.255.255         On-link   169.254.171.176    261
      192.168.1.0    255.255.255.0      192.168.5.5      192.168.5.6     20
      192.168.2.0    255.255.255.0      192.168.5.5      192.168.5.6     20
      192.168.3.0    255.255.255.0         On-link     192.168.3.101    281
    192.168.3.101  255.255.255.255         On-link     192.168.3.101    281
    192.168.3.255  255.255.255.255         On-link     192.168.3.101    281
      192.168.5.1  255.255.255.255      192.168.5.5      192.168.5.6     20
      192.168.5.4  255.255.255.252         On-link       192.168.5.6    276
      192.168.5.6  255.255.255.255         On-link       192.168.5.6    276
      192.168.5.7  255.255.255.255         On-link       192.168.5.6    276
        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     192.168.3.101    281
        224.0.0.0        240.0.0.0         On-link   169.254.215.229    276
        224.0.0.0        240.0.0.0         On-link    169.254.220.88    276
        224.0.0.0        240.0.0.0         On-link       192.168.5.6    276
        224.0.0.0        240.0.0.0         On-link   169.254.171.176    261
  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     192.168.3.101    281
  255.255.255.255  255.255.255.255         On-link   169.254.215.229    276
  255.255.255.255  255.255.255.255         On-link    169.254.220.88    276
  255.255.255.255  255.255.255.255         On-link       192.168.5.6    276
  255.255.255.255  255.255.255.255         On-link   169.254.171.176   9999
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      169.254.0.0      255.255.0.0    192.168.232.1       1
      169.254.0.0      255.255.0.0    192.168.130.1       1
      169.254.0.0      255.255.0.0    192.168.20.13       1
      169.254.0.0      255.255.0.0    169.254.62.85       1
      169.254.0.0      255.255.0.0  169.254.215.229       1
      169.254.0.0      255.255.0.0   169.254.220.88       1
      169.254.0.0      255.255.0.0     192.168.0.26       1
===========================================================================

Thoughts, or suggestions much appreciated!

Thanks,
Richard.
Logged

PacketTracer

  • Level 4 Member
  • ****
  • Posts: 441
Re: OpenVPN Issues
« Reply #1 on: August 05, 2016, 11:55:44 AM »
Hi,

first of all your 169.254 entries are extremely remarkable, and most astonishing are the following entries:


Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      169.254.0.0      255.255.0.0    169.254.62.85   169.254.220.88     21
      169.254.0.0      255.255.0.0  169.254.215.229   169.254.220.88     21
      169.254.0.0      255.255.0.0    169.254.62.85  169.254.215.229     21
      169.254.0.0      255.255.0.0   169.254.220.88  169.254.215.229     21
      169.254.0.0      255.255.0.0    169.254.62.85  169.254.171.176      6
      169.254.0.0      255.255.0.0  169.254.215.229  169.254.171.176      6
      169.254.0.0      255.255.0.0   169.254.220.88  169.254.171.176      6
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      169.254.0.0      255.255.0.0    192.168.232.1       1
      169.254.0.0      255.255.0.0    192.168.130.1       1
      169.254.0.0      255.255.0.0    192.168.20.13       1
      169.254.0.0      255.255.0.0    169.254.62.85       1
      169.254.0.0      255.255.0.0  169.254.215.229       1
      169.254.0.0      255.255.0.0   169.254.220.88       1
      169.254.0.0      255.255.0.0     192.168.0.26       1
===========================================================================


I have never seen something like that. 169.254 addresses (so called APIPA) are not meant for routing, hence any routing table entry for 169.254.x.y other than Gateway = "On-link" are useless. Persistent routes for 169.254.0.0/16 shouldn't exist at all. You should remove the above listed 169.254 entries, while you can leave all 169.254 entries with Gateway="On-link" in place (looks like you have 3 additional interfaces not used but active and hence autoconfigured with APIPA addresses).

On the other hand there is probably no negative effect of this 169.254 misconfiguration to your OpenVPN problem.

Filtering the relevant information gives the following routing information:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.3.1    192.168.3.101     25
        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
      192.168.1.0    255.255.255.0      192.168.5.5      192.168.5.6     20
      192.168.2.0    255.255.255.0      192.168.5.5      192.168.5.6     20
      192.168.3.0    255.255.255.0         On-link     192.168.3.101    281
    192.168.3.101  255.255.255.255         On-link     192.168.3.101    281
    192.168.3.255  255.255.255.255         On-link     192.168.3.101    281
      192.168.5.1  255.255.255.255      192.168.5.5      192.168.5.6     20
      192.168.5.4  255.255.255.252         On-link       192.168.5.6    276
      192.168.5.6  255.255.255.255         On-link       192.168.5.6    276
      192.168.5.7  255.255.255.255         On-link       192.168.5.6    276
        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     192.168.3.101    281
        224.0.0.0        240.0.0.0         On-link       192.168.5.6    276
  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     192.168.3.101    281
  255.255.255.255  255.255.255.255         On-link       192.168.5.6    276


Here 192.168.5.4/255.255.255.252 (or /30) obviously is your tunnel network with 192.168.5.6 being your Client  and 192.168.5.5 being the peer tunnel address of your remote router. And networks 192.168.1.0/24, 192.168.2.0/24 and 192.168.5.1/32 are possible destinations at your remote location (where 192.168.5.1/32 is unclear), reachable through the tunnel (next hop = 192.168.5.5). So from the client's perspective routing looks ok.

But what about the "servers" in you remote location? Do their routing tables encompass routing information for destination 192.168.5.4/255.255.255.252 (your tunnel net)?

In addition I guess, that your OpenVPN client shall not be configured to be a router for network 192.168.3.0/24, meaning any other device in that network would use your client as next hop to tunnel traffic to your remote site? Hence your client shall be the only device using its tunnel address 192.168.5.6 to talk to the remote site?

PT


Logged

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
Re: OpenVPN Issues
« Reply #2 on: August 06, 2016, 10:44:52 AM »
Quote from: PacketTracer on August 05, 2016, 11:55:44 AM

>> first of all your 169.254 entries are extremely remarkable, and most astonishing are the following entries:

These routes, and the 192.168.x networks in the higher numbers are virtual interfaces for Workstation, and I believe are a red herring. 


>>Here 192.168.5.4/255.255.255.252 (or /30) obviously is your tunnel network with 192.168.5.6 being your Client  and 192.168.5.5 being the peer tunnel
>>address of your remote router. And networks 192.168.1.0/24, 192.168.2.0/24 and 192.168.5.1/32 are possible destinations at your remote location
>>(where 192.168.5.1/32 is unclear), reachable through the tunnel (next hop = 192.168.5.5). So from the client's perspective routing looks ok.

When the tunnel is up, I can ping my local address, 192.168.5.6, but I cannot ping the other end of the tunnel, 192.168.5.5. I also cannot ping any other interface on the remote network, 192.168.1.1, 192.168.2.1, etc. So the routes are there, but the traffic doesn't seem to be either getting to the remote end, or the remote end is just dropping the traffic. I don't see anything in the logs to explain that, but I am thinking of running a packet capture, and dissecting with Wireshark.

>> But what about the "servers" in you remote location? Do their routing tables encompass routing information for destination 192.168.5.4/255.255.255.252
>> (your tunnel net)?

The remote resources are in their own VLAN, and the routing table on the remote system has the next hop as the router itself. The remote resource has no problems connecting to the internet, and I can connect to it from a system in the other subnet on the same router without issue, so I know internally that routing is working.

>> In addition I guess, that your OpenVPN client shall not be configured to be a router for network 192.168.3.0/24, meaning any other device in that
>> network would use your client as next hop to tunnel traffic to your remote site? Hence your client shall be the only device using its tunnel address
>>192.168.5.6 to talk to the remote site?

I have tried with and without split tunneling, and no difference. In "full" tunnel mode, there should be no place for the traffic to go other than the tunnel.

For something that is sold and marketed as a "VPN Router". the VPN documentation seems really lacking, and I see a lot of people with VPN related issues, and not a whole lot of answers. My attempt to get an IPSec/L2TP connection going with a support call to Dlink resulted in me using the GreenBow VPN client, which worked (sort of), but it seems silly to have to pay for a client, when Windows has a built in one that should in theory work.

This is why I am currently wandering down the OpenVPN path, which has gotten me further, but not all the way yet.
Logged

PacketTracer

  • Level 4 Member
  • ****
  • Posts: 441
Re: OpenVPN Issues
« Reply #3 on: August 07, 2016, 05:35:36 AM »
Hi,

what kind of OpenVPN client do you use? The original one from openvpn.net, which uses a TUN/TAP interface? In this case check if the following hint may be helpful.

PT
Logged

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
Re: OpenVPN Issues
« Reply #4 on: August 07, 2016, 07:35:10 AM »
I am seeing the same behaviour on an Android device. Both the Windows 10 laptop and the Android are using the official OpenVPN clients available to them. Neither of them have issues connecting to my Linux OpenVPN server implementation.

I suspect whatever is happening or missing is on the Dlink end. Either it is not forwarding correctly, or is not allowing the traffic at all. I am not sure what to do if that is the case, other than to open a case with Dlink, which like the last one will go nowhere.
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49923
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: OpenVPN Issues
« Reply #5 on: August 07, 2016, 05:46:54 PM »
Did you email or phone contact D-Link support? Phone support is preferred...
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
Re: OpenVPN Issues
« Reply #6 on: August 07, 2016, 08:12:32 PM »
My last contact with DLink support on a VPN issue was not terribly useful in terms of a resolution, but I am desperate for a workable solution, so will try them in the morning again tomorrow.
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49923
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: OpenVPN Issues
« Reply #7 on: August 08, 2016, 06:34:13 AM »
Please try phone support. Let us know how it goes...
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
Re: OpenVPN Issues -- SOLVED
« Reply #8 on: August 08, 2016, 09:17:47 PM »
I called phone support, and was able to resolve the issue while on the phone with them, but not really something they were able to help me with.

As I was working through the problem, I noticed a log message on the server I had the 250N logging to:

Aug  8 11:09:52 x.x.x.x [Aug 08 11:09:52 Mon 2016(GMT-0800)] [DSR-250N] [2.11] [VPN] [Warning] [OPEN_VPN] [openvpn[30694]: x.x.x.x:58174 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo]]

Sure enough, I looked in my client config file, and comp-lzo was set. I commented it out, and tried the conection again, and voila! I had success and traffic was moving!!
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49923
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: OpenVPN Issues
« Reply #9 on: August 09, 2016, 06:37:59 AM »
So this comp-lzo seems to be inhibiting the connection?

Where is this client file and where is it commented out, for future users.

Thanks for posting your resolution.
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.

PacketTracer

  • Level 4 Member
  • ****
  • Posts: 441
Re: OpenVPN Issues
« Reply #10 on: August 09, 2016, 07:11:56 AM »
The solution in general raises the question of possible mismatches between client and server site settings not just concerning compression (on|off and if on which method?) but also encryption or hash algorithms to be used. Especially if there is no integration procedure (do there exist any for DLINK routers?) that allows e.g. the  creation of a configuration file exported from the server for use as input file to the client's configuration, the occurrence of such problems is highly probable.
Logged

ZaphoidYK

  • Level 1 Member
  • *
  • Posts: 7
Re: OpenVPN Issues
« Reply #11 on: August 09, 2016, 11:46:09 AM »
Quote from: FurryNutz on August 09, 2016, 06:37:59 AM
So this comp-lzo seems to be inhibiting the connection?
Where is this client file and where is it commented out, for future users.

The OpenVPN config file is simply a flat text file with configuration options in it. The location of the file depends on the client. For most mobile clients it is imported as a part of the configuration process. You would generally create and edit the file offline, then deploy it.

The sample config file, which I was using for my original Linux OpenVPN setup is here, and I modified my working file for the Dlink implementation:

https://openvpn.net/index.php/open-source/documentation/howto.html#client

comp-lzo is enabled in that example by default (and in the server end as well), but the Dlink implementation does not have it set, nor is that documented anywhere. I only found it through reviewing log messages, and connecting the dots. I'm not sure why compression is not turned on in the Dlink implementation. CPU load perhaps?... In looking back, it makes perfect sense why I would be seeing the behaviour I was with a compression mismatch. Compression would not come into play during negotiation, so you would get a successful connection, but if one end was sending compressed data that the other end couldn't decompress, then it would make sense that traffic would not pass.

In terms of other options, the openvpn site is pretty good about explaining things.

Regards,
Richard.
Logged

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 49923
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: OpenVPN Issues
« Reply #12 on: August 09, 2016, 02:01:22 PM »
Thanks for the additional information and explanation. Hope it helps future users where needed.  ;)
Logged
Cable: 1Gb/50Mb>NetGear CM1200>DIR-882>HP 24pt Gb Switch. COVR-1202/2202/3902,DIR-2660/80,3xDGL-4500s,DIR-LX1870,857,835,827,815,890L,880L,868L,836L,810L,685,657,3x655s,645,628,601,DNR-202L,DNS-345,DCS-933L,936L,960L and 8000LH.