1

Intended: OpenVPN server allows clients to masquerade as its public IPv4 on the WWAN, as well as connect to other local servers within the private network, e.g. the internal DNS server.

OpenVPN server routing all traffic to private network and WAN

The private network containing the VPN server + DNS server has addresses in 10.0.0.0/16. The DNS server is 10.0.0.2.

From that ^ diagram, the OpenVPN Client is connecting OK and is able to see the WAN. However, there are problems:

  1. I am not able to perform an nslookup even when I manually specify the DNS server's private IP. I have also tried using the VPN server's public & private IPs for the nslookup to no avail.

  2. I am not able to ping/http/ssh to any servers on the private subnet except the one I know I am VPN'ing through. I am able to SSH to the OpenVPN server's private IP address.

Note: For SSH, I actually don't mind ^ where I must first SSH forward-agent through the VPN server to get to the other private boxes on port 22. But even if I opt for that, I believe it's my responsibility to understand exactly how it's allowed/denied!

  1. Even though I have specified the DNS server in my OpenVPN server configuration, and the parameters are echoed in the OpenVPN startup sequence so I know the server is specifying them to the client in some way- Default DNS service on the local machine just goes dark when the VPN is connected. I have many theories, but it seems prudent to address item #1 before pursuing this more (??)

  2. During the OpenVPN startup sequence, I see errors like Unrecognized option or missing parameter yet believe these must be the result of items specified by the OpenVPNas server! Is there a compatibility problem (perhaps) between my OpenVPN client and OpenVPN server?

Note: The original Question contained false information and has been edited to be more useful. Thanks for illumination & guidance from MariusMatutiae in his answer below that addresseses faults in the original question.

In this process, I have been studying Internet Protocal- a formal understanding of the subject is inextricable from any sane attempt to configure a VPN.

My Current Configurations:

OpenVPN Access Server Admin UI:

Access Server version:  2.0.17  
Authenticate users with:    pam 
Accepting VPN client connections on IP address: all interfaces  
Port for VPN client connections:    tcp/443, udp/1194   
OSI Layer:  3 (routing/NAT) 
Clients access private subnets using: NAT
Dynamic IP Address Network: 10.0.16.0/24
Group Default IP Address Network: 10.0.16.0/24
Routing: Yes, VPN clients have access to private subnets
Private subnets: 10.0.0.0/16
Yes, Allow access from these private subnets to all VPN client IP addresses and subnets
Yes, client Internet traffic be routed through the VPN
Yes, clients be allowed to access network services on the VPN gateway IP address
Yes, have clients use same DNS servers as server

Server Config Directives:

keepalive 10 60

Client Config Directives:

redirect-gateway
persist-tun
pull

OpenVPN Startup Report:

Thu Jul 30 12:37:43 2015 OpenVPN 2.3.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun  8 2015
Thu Jul 30 12:37:43 2015 library versions: OpenSSL 1.0.1f 6 Jan 2014, LZO 2.06
Thu Jul 30 12:37:43 2015 Control Channel Authentication: tls-auth using INLINE static key file
Thu Jul 30 12:37:43 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:43 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:43 2015 Socket Buffers: R=[212992->200000] S=[212992->200000]
Thu Jul 30 12:37:43 2015 UDPv4 link local: [undef]
Thu Jul 30 12:37:43 2015 UDPv4 link remote: [AF_INET]52.58.43.124:1194
Thu Jul 30 12:37:43 2015 TLS: Initial packet from [AF_INET]52.58.43.124:1194, sid=6e5a857f 05e9ff87
Thu Jul 30 12:37:44 2015 VERIFY OK: depth=1, CN=OpenVPN CA
Thu Jul 30 12:37:44 2015 VERIFY OK: nsCertType=SERVER
Thu Jul 30 12:37:44 2015 VERIFY OK: depth=0, CN=OpenVPN Server
Thu Jul 30 12:37:44 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 30 12:37:44 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:44 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 30 12:37:44 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 12:37:44 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
Thu Jul 30 12:37:44 2015 [OpenVPN Server] Peer Connection Initiated with [AF_INET]52.58.43.124:1194
Thu Jul 30 12:37:47 2015 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Jul 30 12:37:47 2015 PUSH: Received control message: 'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 10,ping-restart 60,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 10.0.16.129,dhcp-option DNS 10.0.0.2,dhcp-option DNS 8.8.8.8,dhcp-option DOMAIN prd1.o2,register-dns,block-ipv6,ifconfig 10.0.16.131 255.255.255.128'
Thu Jul 30 12:37:47 2015 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:1 is ignored by previous <connection> blocks 
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.7)
Thu Jul 30 12:37:47 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.7)
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: LZO parms modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: route options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: route-related options modified
Thu Jul 30 12:37:47 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jul 30 12:37:47 2015 ROUTE_GATEWAY ON_LINK IFACE=wwan0 HWADDR=4e:cd:17:f4:1e:42
Thu Jul 30 12:37:47 2015 TUN/TAP device tun0 opened
Thu Jul 30 12:37:47 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 12:37:47 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 12:37:47 2015 /sbin/ip link set dev tun0 up mtu 1500
Thu Jul 30 12:37:47 2015 /sbin/ip addr add dev tun0 10.0.16.131/25 broadcast 10.0.16.255
Thu Jul 30 12:37:53 2015 ROUTE remote_host is NOT LOCAL
Thu Jul 30 12:37:53 2015 /sbin/ip route add 52.58.43.124/32 dev wwan0
Thu Jul 30 12:37:53 2015 /sbin/ip route add 0.0.0.0/1 via 10.0.16.129
Thu Jul 30 12:37:53 2015 /sbin/ip route add 128.0.0.0/1 via 10.0.16.129
Thu Jul 30 12:37:53 2015 Initialization Sequence Completed

2 Answers 2

0

These two statements

  push "remote-gateway 52.58.43.124"
  push "remote-gateway 10.0.31.207"

don't make any sense. First, they contradict each other. Second, this kind of push option does not exist: from the online manual

This is a partial list of options which can currently be pushed: --route, --route-gateway, --route-delay, --redirect-gateway, --ip-win32, --dhcp-option, --inactive, --ping, --ping-exit, --ping-restart, --setenv, --persist-key, --persist-tun, --echo, --comp-lzo, --socket-flags, --sndbuf, --rcvbuf

There is no mention of push gateway.

Third, they are superfluous. You need to know the public IP of your server (first statement) or your client will never be able to contact it, thus no need to push it to the client. As for the private IP (second statement) the routed setup which (presumably) you are contemplating has a peer to peer connection which will make the private IP of the counterpart known to the client as the tunnel is established, so there is no need to push the option.

If instead the addresses above do not refer to the public IP of the server and to the private address of the other end of the tunnel, then a fortiori there is no reason for the client to know these addresses, hence no push gateway options.

Since you do not provide full config files for both server and client, it is impossible to say whether there are any more errors, but surely the one pointed out above is an error.

0

I believe this is a case of over-configuration. The problem is using access to private subnets via routing. Actually, in this case simply using NAT will allow your clients full access to the 10.0.0.2 subnet.

Other than that, this is already solid. We are preventing "leaked" DNS -or anything for that matter- thanks to the "Route all traffic through VPN" in the OpenVPN server configuration. This option also requires you to specify what to do with DNS, because DNS absolutely does come along with "all traffic".

Fix that, and the rest of the DHCP process ought to take care of routing client DNS requests via your private DNS server.

Also, once this has been sorted out, you will be able to use the 10.0.0.2 DNS server directly from the client, as well as SSH into all the boxes on the 10.0.16.0/24 subnet. Ironically, you will no longer be able to SSH into the OpenVPN server itself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .