Endian 2.5.1 OpenVPN Default Gateway and DNS Not Pushing Fix

[Guest]

[ruhllatio]

EDIT ** Guaranteed fix for not pushing DNS and Static IP Address assignments ** Workaround for not pushing default gateway **

All,

Like others my Endian 2.5.1 box was incapable of providing DNS\Default route information to my roadwarrior client.  Though these steps might not work for everyone, this is what I did to rectify.  If you do not require Split-Tunnel or Internal DNS resolution, then you can leave your server as is.  It will work to grant you Green access.

First, open your OpenVPN config template and allow the server to search for a client configuration directory.

nano /etc/openvpn/openvpn.conf.tmpl

Remove the ; character before ";client-config-dir clients"  

Ctrl-O to write out the file and Ctrl-X to Exit Nano.

Now, create a file the exact name as the user you have configured in the OpenVPN gui in the /var/openvpn/clients directory.  There is no extension.

nano /var/openvpn/clients/EnterUserName

In this file, add the following lines adapted to your specific network configuration:

ifconfig-push "192.168.1.80 255.255.255.0"
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.1.1"

Then Ctrl-O to write out the file and Ctrl-X to Exit Nano.

Restart OpenVPN server.

Profit.

Edit:  Thanks to Peter-Endian and Verno100 for the path to the solution!

[ruhllatio]

After some additional testing, this configuration may not work in call cases.  Hold tight for more.

EDIT:  After reviewing how all this goes down, it is kind of a workaround and not a true fix.  A fix would be a new version of OpenVPN on 2.5.1 that correctly writes a client file.  Important to note:  I'm testing my OpenVPN connectivity using a tethered BlackBerry Tour through VZAccess Manager.  Because it dials out on a PPP connection for Web services, it doesn't receive a real default gateway that can be redirected by OpenVPN.  Instead, it applies the logic of "in a point to point tunnel, I can route everything to the tunnel interface as a gateway because there is only one other destination besides myself."  For all you Cisco folks out there (and likely some other vendors) this is the equivalent of building a GRE Tunnel and then routing things to Tunnel0 instead of the IP of the distant end gateway.

The "redirect-gateway def1" command added to the client file forces my client to add two routes that are more specific than the default.  It basically splits the default route in half... 0.0.0.0/1 and 128.0.0.0/1 are both routed to 192.168.1.1 (the internal IP of my Endian).  As this makes these rules more specific than the default route of 0.0.0.0/0 to the PPP Adapter, it routes all my traffic to 192.168.1.1 instead.  Some or all of this may not be necessary depending upon your configuration.  I urge each of you to run a "route print" from your command window to check your table after making the above changes and connecting to OpenVPN.  Below is likely what you will see... 10.35.199.3 is my IP from Verizon Wireless.  MYREDIPATHOME is my Endian's External IP Address.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         On-link       10.35.199.3     51
          0.0.0.0        128.0.0.0      192.168.1.1     192.168.1.80   4256
      10.35.199.3  255.255.255.255         On-link       10.35.199.3    306
    MYREDIPATHOME  255.255.255.255         On-link       10.35.199.3     51
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
        128.0.0.0        128.0.0.0      192.168.1.1     192.168.1.80   4256
      192.168.1.0    255.255.255.0         On-link      192.168.1.80   4511
     192.168.1.80  255.255.255.255         On-link      192.168.1.80   4511
    192.168.1.255  255.255.255.255         On-link      192.168.1.80   4511
===========================================================================


You will notice all the routes added have a much higher metric than the standard.  Not sure how to change this as it is currently autogenerated by the OpenVPN client.  Even if it were able to create a new default gateway for the Tap interface, it likely wouldn't be able to compete with the metric of the current default gateway and therefore drop.

[riaanjvr]

I had the exact same issue with 2.5.1; trying to run Gw2Gw VPN from my home through a semi public wireless network to the office to get internet access.

The solution was for me to put in  OPenVPN Server's Advanced settings;  under the Global push options:
Push this Networks:
0.0.0.0/1
128.0.0.0/1

And under Push these nameservers:
The Green IP of your Endian VPN server

[anduran9003]

I had the exact same issue with 2.5.1; trying to run Gw2Gw VPN from my home through a semi public wireless network to the office to get internet access.

The solution was for me to put in  OPenVPN Server's Advanced settings;  under the Global push options:
Push this Networks:
0.0.0.0/1
128.0.0.0/1

And under Push these nameservers:
The Green IP of your Endian VPN server

Hello! Sorry for my really bad English and to revive old topic but I found a solution for this problem.

the first thing you should do is define what you want to target DNS in the internal domain, then I am connected to VPN interface (on the server where the drawback EFW) enter proxy> DNS> DNS Routing and add a name server for your domain
Field 1(domain): domain.local #(your domain)
Field 2(DNS Server):192.168.0.1@tap1 #(your dns server on the LAN @ interface tap1)

I hope you find it useful

[mmiat]

I've not understood, is there a fix? and 2.5.2 is broken too?
thanks