Using F5 APM 12.1.2 Build 0.93.249 Engineering Hotfix We have selected to register machines in DNS when connecting through the VPN. We do this since we have many employees using laptops issued by us and our support staff needs to be able to do remote support on any VPN connected machines. We only allow VPN access to our machines – privately owned machines are not allowed to use the VPN. We have noticed recently that when these machines connect via VPN and register their addresses in DNS, they are registering the IP address of the local Ethernet adapter – not the address assigned to the virtual VPN adapter. Here’s a quick list of what happens: The employees logs in through the VPN and receives one of the addresses from our iP pool (routable addresses on our subnet). The machine registers in DNS with the correct address from the IP Pool. After about 5 or 10 minutes the DNS record is updated to reflect the address of its local Ethernet connection – not the address assigned to the virtual adapter.This local address is usually a private address (192.168.x.x) and is of course un-reachable from our network. The following options are selected: Register this connection's addresses in DNS Use this connection's DNS suffix in DNS registration Enforce DNS search order The following options are NOT selected: Allow local subnetAllow local DNS servers Prohibit routing table changes during Network Access connection. There is no negative impact to the connected user. They can still access the resources they need.Any ideas as to what is causing the registered address to change from the pool address issued to the virtual adapter to the local address issued to the Ethernet connection? Thanks.

Hi All, This is no longer a problem for us, but it is not because of a simple solution or checkbox. Basically the inability to fix this issue caused us to completely redo the way we register dynamic records in DNS. To try and get a handle on this issue we went with a managed DNS environment using a service account to register all DHCP clients in DNS on behalf of the client itself. Then we applied Group Policy to all our workstations which disallowed them from registering themselves in DNS. This worked well in that it stopped us having multiple DNS records for a single machine (Wi-Fi, Wired, and VPN). The problem we then ran into, predictably, was that since we had disallowed our workstations to register themselves in DNS and instead had the DHCP server do it on their behalf, machines that were coming through VPN no longer registered in DNS at all, since they were getting addresses from a pool on the BIG-IP and not our DHCP server. We went from having multiple DNS entries for a VPN connected computer to having none. While looking for a solution for this issue, we ran across the following page: https://devcentral.f5.com/s/articles/APM-DHCP-Access-Policy-Example-and-Detailed-Instructions . This solution allows VPN clients to get an IP address from our DHCP server rather than from a local IP address pool on the BIG-IP. The end result is that any machine that logs in through the VPN gets an address from our DHCP server, which then registers that address in our DNS. None of the other NICs on the connecting machine are registered since the machine itself is not allowed to register itself in DNS. The combination of having a managed DNS implementation and using our own DHCP server to grant leases to machines connecting via VPN has resolved the issue for us, but it was a long slog.

Hi, Please let us know how/where you configured dns servers, so when user connects to VPN he receives DNS server. You are using any iRules for DNS assignment?

Hello, Thanks for replying. We do not use any iRules for DNS registration or to set our DNS servers. We set our DNS servers on the "DNS/Hosts" page of the VPN configuration under "Access Policy/Network Access". We have 2 DNS servers defined there, and they are both valid. I would be curious to see if an iRule could force only the virtual adapter to register, but I'm not really familiar enough with iRules to be able to know if I can do that or how to do it if it's possible. -John

John_T__Morgan_

Nimbostratus

Sep 20, 2017

VPN Connected Machines are registering incorrect IP address in our DNS

Using F5 APM 12.1.2 Build 0.93.249 Engineering Hotfix

We have selected to register machines in DNS when connecting through the VPN. We do this since we have many employees using laptops issued by us and our support staff needs to be able to do remote support on any VPN connected machines. We only allow VPN access to our machines – privately owned machines are not allowed to use the VPN.

We have noticed recently that when these machines connect via VPN and register their addresses in DNS, they are registering the IP address of the local Ethernet adapter – not the address assigned to the virtual VPN adapter.

Here’s a quick list of what happens:

The employees logs in through the VPN and receives one of the addresses from our iP pool (routable addresses on our subnet).
The machine registers in DNS with the correct address from the IP Pool.
After about 5 or 10 minutes the DNS record is updated to reflect the address of its local Ethernet connection – not the address assigned to the virtual adapter.
This local address is usually a private address (192.168.x.x) and is of course un-reachable from our network.

The following options are selected:

Register this connection's addresses in DNS
Use this connection's DNS suffix in DNS registration
Enforce DNS search order

The following options are NOT selected:

Allow local subnet
Allow local DNS servers
Prohibit routing table changes during Network Access connection.

There is no negative impact to the connected user. They can still access the resources they need.

Any ideas as to what is causing the registered address to change from the pool address issued to the virtual adapter to the local address issued to the Ethernet connection?

Thanks.

application delivery

BIG-IP

BIG-IP Access Policy Manager (APM)

John_T__Morgan_
Nimbostratus
Mar 27, 2019
Hi All,

This is no longer a problem for us, but it is not because of a simple solution or checkbox. Basically the inability to fix this issue caused us to completely redo the way we register dynamic records in DNS.

To try and get a handle on this issue we went with a managed DNS environment using a service account to register all DHCP clients in DNS on behalf of the client itself. Then we applied Group Policy to all our workstations which disallowed them from registering themselves in DNS. This worked well in that it stopped us having multiple DNS records for a single machine (Wi-Fi, Wired, and VPN). The problem we then ran into, predictably, was that since we had disallowed our workstations to register themselves in DNS and instead had the DHCP server do it on their behalf, machines that were coming through VPN no longer registered in DNS at all, since they were getting addresses from a pool on the BIG-IP and not our DHCP server. We went from having multiple DNS entries for a VPN connected computer to having none.

While looking for a solution for this issue, we ran across the following page: https://devcentral.f5.com/s/articles/APM-DHCP-Access-Policy-Example-and-Detailed-Instructions .

This solution allows VPN clients to get an IP address from our DHCP server rather than from a local IP address pool on the BIG-IP.

The end result is that any machine that logs in through the VPN gets an address from our DHCP server, which then registers that address in our DNS. None of the other NICs on the connecting machine are registered since the machine itself is not allowed to register itself in DNS.

The combination of having a managed DNS implementation and using our own DHCP server to grant leases to machines connecting via VPN has resolved the issue for us, but it was a long slog.
RaghavendraSY_7
Cumulonimbus
Oct 09, 2017
Hi,

Please let us know how/where you configured dns servers, so when user connects to VPN he receives DNS server. You are using any iRules for DNS assignment?
- John_T__Morgan_
  Nimbostratus
  Oct 09, 2017
  Hello,
  
  Thanks for replying.
  
  We do not use any iRules for DNS registration or to set our DNS servers.
  
  We set our DNS servers on the "DNS/Hosts" page of the VPN configuration under "Access Policy/Network Access". We have 2 DNS servers defined there, and they are both valid.
  
  I would be curious to see if an iRule could force only the virtual adapter to register, but I'm not really familiar enough with iRules to be able to know if I can do that or how to do it if it's possible.
  
  -John
RaghavendraSY
Altostratus
Oct 09, 2017
Hi,

Please let us know how/where you configured dns servers, so when user connects to VPN he receives DNS server. You are using any iRules for DNS assignment?
- John_T__Morgan_
  Nimbostratus
  Oct 09, 2017
  Hello,
  
  Thanks for replying.
  
  We do not use any iRules for DNS registration or to set our DNS servers.
  
  We set our DNS servers on the "DNS/Hosts" page of the VPN configuration under "Access Policy/Network Access". We have 2 DNS servers defined there, and they are both valid.
  
  I would be curious to see if an iRule could force only the virtual adapter to register, but I'm not really familiar enough with iRules to be able to know if I can do that or how to do it if it's possible.
  
  -John
MisterG
Nimbostratus
Apr 25, 2018
It's seems to be that we have the same issue using SVPN via F5 with version 12.1.2 HF1 and BIG-IP Edge Client on Windows 10 laptops.

In most cases the private IPv4 ip address given by the home router is registered to internal company DNS and the virtual IPv4 ip address provided by the F5 device. In some cases also the IPv6 ip address provided by the ISP from home is registered to internal DNS.

Questions: Is this a known issue in this release train? How to overcome this issue?

Many thanks ... Sandro
Fredo_376785
Nimbostratus
Nov 14, 2018
Hello,

I have the same issue as you. LAN interface is registered to internal DNS and Virtual IPv4 ip adress. So I Have duplicate DNS records in DNS Server. Do you have the solution for this problem???

Thanks.

Fred.
Martin_375761
Nimbostratus
Feb 20, 2019
F5 APM 13.1.1.4 Build 0.0.4

Hi,

This problem appeared recently in our DNS. Did anyone figure out what the issue was/is?
bepositive_3870
Nimbostratus
Mar 27, 2019
Hello,

We have exactly the same issue. Did you solve it ? If yes, How ?

Can F5 answer to this post ? It would be great

Thank you for your help
Martin_375761
Nimbostratus
Mar 27, 2019
We first identified this issue about a month ago when users could not get access to external/internet websites. Upon investigating the issue we confirmed that the users were getting the IP address assigned from BIG-IP. However, when confirming this address with our Windows DNS we found that certain users were registered with their 192.168.x.x address. F5 Support recommended that we create an additional DNS zone for the remote users using the Edge client. We done so and also made the change in BIG-IP to reflect the new DNS suffix. However, this did not made any difference to how the client connected to our network. The client connected using the same DNS suffix as before and ignored the new DNS zone that we created for it. We even deleted the DNS suffix from BIG-IP and the Edge client connected as normal. This left us a bit confused as to why this would not as least stop the Edge client from successfully connecting to our network. We have spoken to F5 Support at create length regarding this behavior and are awaiting further assistance.

The initial post is from 2017 and I am concerned that this issue hasn't been answered from someone from F5 Support. Are we able to ask for someone at F5 Support to provide any assistance with this? Its odd that this problem is happening in more than one environment and nobody has an answer why or how to resolve it.
bepositive_3870
Nimbostratus
Mar 27, 2019
Hello Martin,

Thank you for your answer and for the description of steps you already went through with F5. I found another post which seems related to this issue :
https://devcentral.f5.com/s/feed/0D51T00006i7h63SAA
The next days we are going to work with a external security company to solve that issue and update this case.
bepositive_3870
Nimbostratus
Mar 28, 2019
Hello John,

Thank you for your enlightment. Straight away, we organised a meeting this morning to discuss about it. Your solution seems great and answering our issue but as you said it will be "a long slog". A POC will be planned this year and the result won't appear tomorrow.
- John_T__Morgan_
  Nimbostratus
  Mar 28, 2019
  It actually was a bit of a blessing in disguise as it made us address our entire DNS/DHCP infrastructure.
  
  Feel free to reach out if you have questions moving forward.