OpenVPN forcing change of client IP address?

[Ancient Geek]

I'm running an OpenVPN client on a Windows 2012 R2 server. There is software on this server that expects the IP address associated with the machine name to be immutable. But whenever the VPN tunnel is brought up, the machine name now resolves to the tunnel's IP address.

Client System:

View OriginalWindows Client

Windows Server 2012 R2 (Microsoft Windows [Version 6.3.9600])

View OriginalOpenVPN Version

OpenVPN 2.4.3-1602
TAP-Windows 9.21.2

Interface Information:

Code: Select all

C:\Users\Administrator>ipconfig/all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : TESTSRV
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : test.local

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Intel(R) 82599 Virtual Function
   Physical Address. . . . . . . . . : 02-BE-94-FE-D1-F8
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28fa:2c44:755e:60f%14(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.30.8.20(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Lease Obtained. . . . . . . . . . : Thursday, December 7, 2017 6:31:40 PM
   Lease Expires . . . . . . . . . . : Thursday, December 7, 2017 10:01:40 PM
   Default Gateway . . . . . . . . . : 172.30.8.17
   DHCP Server . . . . . . . . . . . : 172.30.8.17
   DHCPv6 IAID . . . . . . . . . . . : 335946933
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-1B-8D-5C-06-B1-98-04-22-82

   DNS Servers . . . . . . . . . . . : 172.30.8.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet 3:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-6C-78-F7-8D
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::ad3c:c740:faf9:37c8%16(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.30.0.26(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.248
   Lease Obtained. . . . . . . . . . : Thursday, December 7, 2017 6:39:31 PM
   Lease Expires . . . . . . . . . . : Friday, December 7, 2018 6:39:30 PM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 172.30.0.30
   DHCPv6 IAID . . . . . . . . . . . : 268500844
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-1B-8D-5C-06-B1-98-04-22-82

   DNS Servers . . . . . . . . . . . : 172.30.0.25
   NetBIOS over Tcpip. . . . . . . . : Enabled

C:\Users\Administrator>

View OriginalClient Configuration File

client
dev tun
remote 172.30.0.17
proto udp4
cipher none
ca ca.crt
cert CLIENT.crt
key CLIENT.key

(Yes, I know there's no cipher. This is in a lab environment and we may need to see what's going on.)

Server System:

View OriginalFreeBSD Server

FreeBSD ssdtest 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

View OriginalOpenVPN Version

OpenVPN 2.4.1

Interface Information:

Code: Select all

re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
	ether 00:0e:c4:cf:5c:1f
	inet 172.30.0.17 netmask 0xfffffffc broadcast 172.30.0.19 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
	ether 00:0e:c4:cf:5c:20
	inet 172.30.0.1 netmask 0xfffffff0 broadcast 172.30.0.15 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
	inet 127.0.0.1 netmask 0xff000000 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	groups: lo 
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet6 fe80::20e:c4ff:fecf:5c1f%tun1 prefixlen 64 scopeid 0x5 
	inet 172.30.0.25 --> 172.30.0.26  netmask 0xfffffff8 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	groups: tun 
	Opened by PID 93052

View OriginalServer Configuration File

dev tun1
verb 1
writepid /var/run/openvpn_ssdtest.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher none
auth SHA1
local 172.30.0.17
tls-server
server 172.30.0.24 255.255.255.248
client-config-dir /usr/local/etc/openvpn-csc/client
lport 1194
push "dhcp-option DNS 172.30.0.25"
push "route 192.168.2.0 255.255.255.252"
push "route 192.168.3.0 255.255.255.0"
push "route 172.28.0.0 255.255.0.0"
push "block-outside-dns"
#push "register-dns"
ca /usr/local/etc/easy-rsa/pki/ca.crt
cert /usr/local/etc/easy-rsa/pki/issued/TEST.crt
key /usr/local/etc/easy-rsa/pki/private/TEST.key
dh /usr/local/etc/easy-rsa/pki/dh.pem
persist-remote-ip
float
topology subnet
mute 10

Here's an example of the issue (the client machine's hostname is TESTSRV):

C:\Users\Administrator>ping TESTSRV

Pinging TESTSRV [172.30.8.20] with 32 bytes of data:
Reply from 172.30.8.20: bytes=32 time<1ms TTL=128
Reply from 172.30.8.20: bytes=32 time<1ms TTL=128
Reply from 172.30.8.20: bytes=32 time<1ms TTL=128
Reply from 172.30.8.20: bytes=32 time<1ms TTL=128

Ping statistics for 172.30.8.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

(At this point I bring up the VPN tunnel.)
C:\Users\Administrator>ping TESTSRV

Pinging TESTSRV [172.30.0.26] with 32 bytes of data:
Reply from 172.30.0.26: bytes=32 time<1ms TTL=128
Reply from 172.30.0.26: bytes=32 time<1ms TTL=128
Reply from 172.30.0.26: bytes=32 time<1ms TTL=128
Reply from 172.30.0.26: bytes=32 time<1ms TTL=128

Ping statistics for 172.30.0.26:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\Administrator>

I need the IP address associated with the machine name to remain 172.30.8.20 when the tunnel is up.
I've tried everything I can think of, along with other suggestions from around the 'net:

• Put the machine name and the desired IP address in the hosts file

• Put the machine name and the desired IP address in the lmhosts file

• Changed the order of the interfaces on the server so the TAP interface is listed second (it was first)

• Deselected the "Register this connection's addresses in DNS" on the TAP interface

• Removed the "push register-dns" line from the server's config file

I'm out of ideas. Is there anything I can try at this point?

Thanks,
Rick

[TinCanTech]

Please see:
HOWTO: Request Help !

[Ancient Geek]

I updated the OP with (I hope) the required information. Any help would be appreciated.

[TinCanTech]

I have no idea what is happening to your DNS but ..
You cannot share the same subnet on your LAN and your VPN with a tunnel.

Change the --server parameter to 10.8.0.0 .. eg:

View Originalserver

server 10.8.0.0 255.255.255.0

Also, you are using the tunnel address of your server as the --remote address in your client, which is even more crazy and absolutely will not work.

Start here:
HOWTO: For OpenVPN Community Edition

[Ancient Geek]

I'm not sure I understand...
The Local interface is 172.30.0.17/30 (172.30.0.16 - 172.30.0.19)
The tunnel network is 172.30.0.24/30 (172.30.0.24 - 172.30.0.27)
When the tunnel is up, 172.30.0.25 is server end of the tunnel and 172.30.0.26 is client end.
As far as I can tell, they don't overlap. Am I missing something?

[TinCanTech]

Ah yes .. your are playing with netmasks .. good luck with that.

My advice .. do it right first then go nuts.

[Ancient Geek]

I have some severe constraints on my IP allocations. But regardless, I finally figured it out:

I had to adjust the metric on the interface I wanted Windows to use for the IP assignment.
(It's at the bottom of the "Advanced TCP/IP Settings" for the interface. I set it to '1' and things wored as I wanted.)