Join Log in
Score:0
pacoverflow avatar Server

Cannot assign a previously used static IP address to an OpenVPN client

ng flag
pacoverflow

We have an OpenVPN server with the following server.conf:

local x.x.x.x
port 1194
proto tcp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

We also had a Linux instance in AWS running an OpenVPN client, and we successfully assigned a static IP address of 10.8.0.2 to it by adding a file with the client's common name to the OpenVPN server's /etc/openvpn/ccd directory with the following contents:

ifconfig-push 10.8.0.2 255.255.0.0

Now we want to replace that Linux instance with a Windows Server 2019 instance and give it the same 10.8.0.2 static IP address. So we did the following:

  • deleted the Linux instance in AWS
  • used the Nyr OpenVPN openvpn-install.sh script on the OpenVPN server to revoke the Linux client
  • deleted the Linux client from the OpenVPN server's /etc/openvpn/server/easy-rsa/pki/index.txt file
  • deleted the Linux client's certificate from the OpenVPN server's /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serial directory
  • deleted the Linux client file in the OpenVPN server's /etc/openvpn/ccd directory
  • deleted the OpenVPN server's /etc/openvpn/server/ipp.txt file (since it had an association of 10.8.0.2 to the Linux client)
  • added a new file in the OpenVPN server's /etc/openvpn/ccd directory for the Windows Server 2019 instance with ifconfig-push 10.8.0.2 255.255.0.0
  • created a Windows Server 2019 instance in AWS
  • installed OpenVPN 2.4.9 on the Windows Server 2019 instance

The Windows Server 2019 instance has the following OpenVPN client configuration file:

client
dev tap
proto tcp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

When we start the OpenVPN client on the Windows Server 2019 instance, the following shows up in the OpenVPN client log file:

Wed Jul 14 01:15:02 2021 [server] Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Wed Jul 14 01:15:03 2021 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jul 14 01:15:03 2021 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.0.0,peer-id 0,cipher AES-256-GCM'
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: route-related options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: peer-id set
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: adjusting link_mtu to 1658
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: data channel crypto options modified
Wed Jul 14 01:15:03 2021 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Jul 14 01:15:03 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 interactive service msg_channel=0
Wed Jul 14 01:15:03 2021 open_tun
Wed Jul 14 01:15:03 2021 TAP-WIN32 device [Local Area Connection] opened: \\.\Global\{526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}.tap
Wed Jul 14 01:15:03 2021 TAP-Windows Driver Version 9.24 
Wed Jul 14 01:15:03 2021 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.0.0 on interface {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F} [DHCP-serv: 10.8.0.0, lease-time: 31536000]
Wed Jul 14 01:15:03 2021 Successful ARP Flush on interface [11] {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}
Wed Jul 14 01:15:03 2021 Block_DNS: WFP engine opened
Wed Jul 14 01:15:03 2021 Block_DNS: Using existing sublayer
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for exe_path
Wed Jul 14 01:15:03 2021 Block_DNS: Added block filters for all interfaces
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for TAP interface
Wed Jul 14 01:15:08 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:08 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:13 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:13 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:14 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:14 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:15 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:15 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:16 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:16 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:17 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:17 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:18 2021 TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/d=up
Wed Jul 14 01:15:18 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 14 01:15:18 2021 Initialization Sequence Completed

As you can see, the OpenVPN client on the Windows Server 2019 instance is receiving the 10.8.0.2 IP address from the OpenVPN server. However, I am repeatedly running ipconfig in a command line window, and I see the following happen every 15 seconds:

  • The OpenVPN network adapter (called "TAP-Windows Adapter V9") gets an IP address of 169.254.211.103 for a few seconds.
  • Then the OpenVPN network adapter gets an IP address of 10.8.0.2 for about one second. During this one second, a ping of 10.8.0.1 (the OpenVPN server) will be successful. Outside of that one second, a ping of 10.8.0.1 will fail.
  • Then the OpenVPN network adapter loses the 10.8.0.2 IP address and does not have any IP address for the next ~12 seconds.
  • This process of getting the 169.254.x.x address, then getting and losing the 10.8.0.2 address keeps repeating every 15 seconds.

Then I decided to see what would happen if I tried to give the Windows Server 2019 a different static IP address that had never been used before. I modified the file for the Windows Server 2019 in the OpenVPN server's /etc/openvpn/ccd directory to give it a static IP address of 10.8.0.11:

ifconfig-push 10.8.0.11 255.255.0.0

Then I restarted the OpenVPN client on the Windows Server 2019 instance, and it works! The client is successfully using the 10.8.0.11 IP address and is not losing it at all.

So why does the Windows Server 2019 instance keep losing the 10.8.0.2 address, which had been used previously by the Linux client? As you can see from the steps I listed above, I revoked the Linux client from the OpenVPN server, and I deleted all traces of the Linux client's common name that I could find on the OpenVPN server.

We would prefer to have the Windows Server 2019 instance use the 10.8.0.2 address, because we have already written scripts assuming 10.8.0.2 will be the static IP, and sent those scripts to a third-party. It will be easier to stick with 10.8.0.2, if possible.

UPDATE:

I didn't look at the Windows Server 2019 instance for a few days, and now I just looked at it again. Surprisingly it had the 10.8.0.2 IP address and it never disappeared. Everything was working as expected. I'm not sure why, as I didn't change anything.

So I restarted the OpenVPN client on the Windows Server 2019 instance to see what would happen, and now it is back to the behavior of getting a 169.254.x.x address then getting and losing the 10.8.0.2 address every 15 seconds.

334
0 + 0
Score:0
pacoverflow avatar Server
ng flag
pacoverflow

It was an IP address conflict, as indicated by the system event log on the Windows Server 2019 instance.

We have some additional Linux servers running OpenVPN clients (different from the Linux client that I mentioned in the question). Each of these Linux servers has a bridge set up with the IP address 10.8.0.2. This bridge connects the tap0 interface of the OpenVPN client to the eth1 interface which is attached to a vendor's device. This setup allows the vendor's software running on the Windows Server 2019 instance to connect to the device.

I powered off the Linux servers and rebooted the Windows Server 2019 instance. The Windows Server 2019 instance was able to obtain 10.8.0.2 without losing it. Then I booted up the Linux servers, and everything is working fine now. The Windows Server 2019 and Linux instances are happy, and the software running on the Windows Server is able to connect to the devices attached to the Linux servers through OpenVPN.

So the solution is to just make sure the Windows Server 2019 instance boots up before any of the Linux instances set up their bridge.

Edit: An easier solution is to just restart the OpenVPN server and then immediately start the OpenVPN client on the Windows Server 2019 instance. It will obtain 10.8.0.2 before any of the Linux instances are able to reconnect to the OpenVPN server.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.