D-Link VPN Router > DSR-250N

OpenVPN Issues

(1/3) > >>

ZaphoidYK:
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.

PacketTracer:
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


ZaphoidYK:

--- 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.

--- End quote ---

PacketTracer:
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

ZaphoidYK:
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.

Navigation

[0] Message Index

[#] Next page

Go to full version