[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] One user having problems with OpenVPN, Remote Desktop

  • Subject: Re: [Openvpn-users] One user having problems with OpenVPN, Remote Desktop
  • From: Josh Cepek <josh.cepek@xxxxxxx>
  • Date: Wed, 21 Nov 2007 01:18:51 -0600
  • Openpgp: id=2E5A5127
  • Z-usanet-msgid: XID818LkuHs70028X39

JJB wrote:

We have one user who is unable to use OpenVPN from one machine.  From 
the other machine he is able to connect, but cannot use Microsoft Remote 
Desktop over OpenVPN to get to our DMZ servers, but is able to use RDC 
to get to the LAN, and then RDC from his workstation back to the DMZ. 
Other people do not have this problem.

I see 2 places to check regarding the machine that can reach the LAN but not DMZ servers:
  • Does the client have a valid route to the DMZ network after VPN connection, and is this route unique on the client's system?  Both these conditions need to be met for the client to properly establish communication directly to DMZ systems.  Some Windows clients, especially Vista, need to set the "route-method exe" and/or "tap-sleep 10" options to properly set routing and give the tap/tun adapter time to come up properly.
  • It doesn't sound like firewalls are the issue if other users of the same VPN setup can directly connect to DMZ servers, although this assumes there are no additional rules for this particular device or client-side firewall rules in effect.  Normally a client firewall will allow outbound connections and accept the return packets, but this might be worth double-checking.
If routing and firewalls aren't the issue, your best bet will be to trace the packets to see where the connection fails.  Tools such as tcpdump or Wireshark will allow you to capture packets.  A successful connection should see packets in this order:
  1. From the client through the VPN tunnel to the VPN server (destined for the DMZ server)
  2. From the VPN server to the DMZ server
  3. (The reply) from the DMZ server to the VPN server (destined for the client)
  4. (The reply) from the VPN server through the VPN tunnel to the client
The client should see steps 1 & 4 on the VPN interface, the VPN server will see steps 1 & 4 on the VPN interface and steps 2 & 3 on the DMZ interface, and the DMZ server will see steps 2 & 3 on the DMZ interface.

The gateway server is running Shorewall and OpenVPN. It has an ethernet 
interface for the internet connection, and two more interfaces for the 
DMZ and the LAN network. Traffic is allowed from the LAN to the DMZ, but 
not from the DMZ to the LAN, so DMZ servers cannot connect to LAN 
servers, but LAN servers can connect to the DMZ.

One of the errors he has forwarded to me is from his windows event log: 
(from the machine that won't connect at all)

Source DHCP
Event ID 1002

Event log error:

The IP address lease for the Network Card with Network Address 
(XXXXXXXXXXXX) has been denied by the DHCP Server (The DHCP 
Server sent a DHCPNACK message)

A DHCP server will send a NACK response if the last used IP by the client either isn't available or has been expressly denied by the DHCP administrator.  In this case the DHCP client is expected to ask for a new lease.  As above, this communication process can be exposed by capturing packets on the client PC to see if it really is sending out and getting back the proper DHCP lease.  Once connected to the VPN, the client should have an address valid on the remote network.  Note that all tap adapters have MAC addresses starting with 00-FF which becomes important when using DHCP reservations or access groups; these may change if an adapter is deleted and re-created.

While not directly related to your problem, you might also want to consider using a routed setup with tun adapters rather than bridging unless you specifically need Ethernet-layer support.  The advantage is less overhead (no need to send subnet broadcasts across the Internet to all VPN clients) and offloading the management of VPN client IP addresses to the VPN server rather than your internal DHCP server.  You can even issue the same VPN IP address for each client by using the client-connect-directory (ccd) configuration option on the VPN server if desired.


Attachment: signature.asc
Description: OpenPGP digital signature