Authorized Networks not working

[CapitalOrtho]

I’m currently testing DUO for RDP on a W10 VM that was setup just for testing DUO. My PC and the PC that I’m RDP-ing to are on the same network/domain and both use the same gateway to get to the internet. Doing a speedtest from each PC shows the Public IPs match.

I have our Public IP added to the allow access without 2FA. It worked when I first set it up but it has stopped working. I’ve reinstalled DUO on the PC twice and it’s still requiring 2FA even though we are on the same network. Any advice would be appreciated.
Thanks

[vincentdb]

I have the same problem. In fact I have this problem for a number of my customers. Support has so far told me that it’s a NAT problem, but I don’t believe that as I can browse fine and when I do an IP lookup, it’s working fine.

[BabbittJE]

Interesting. Most people use Duo on public IP addresses and none on private IP addresses. In other words, if I were to RDP into my computer from the Internet, Duo prompts me. If I were to RDP into my computer from within the same subnet, Duo doesn’t prompt me. That’s the desired setup but YMMV.

CapitalOrtho:

I have our Public IP added to the allow access without 2FA.

[acomadmin]

I wish we had as much luck as @BabbittJE Babbit. I went through the same thing with @vincentdb vincentdb, support pointed at our NAT policy as the culprit. I have our public IP as an authorized network but am still prompted for RDP connections within our network.

I improperly assumed it was reaching out to Duo servers and would get our public IP based on that request. But the Duo client itself seems to be scraping our internal IP for login requests and I have no idea how to make it check our public IP. If I do an IP lookup from any internal computer/server it obviously gives us the expected public IP but support insists it’s our network that’s the problem.

Curious if any others have had any luck on figuring out what the issue is or have any ideas on possible fixes.

[BabbittJE]

You are allowing RDP into a Windows 10 computer from the Internet without a Remote Desktop Gateway. What I have is RDG+DAG and RDSH. When one logs in from the Internet, it goes through the RDG+DAG. When one logs in from within internal network, it goes directly to the RDSH, bypassing RDG+DAG. For your situation, if you have the resources, set up a RDG with DAG+SSO and make that Windows 10 one of the computers you can access through RDG. Then for external DNS, use the public IP address that points to your RDG, and for internal DNS, use the private IP address to point to same. As long as the RDP has “Bypass RD Gateway server for local addresses” is enabled, it’ll bypass the RDG+DAG server, thus, won’t prompt internal users.

With Duo on Win10 instead of a RDG, you may have to work it differently. You need to authorize the public IP address/subnet of your internal users so that Duo would be bypassed. And, in the internal DNS, point that Win10 to a public IP address. Have the user route out of the firewall so it can register with a public IP address then back into the public IP address of the Win10 PC.

I do not recommend having a Win10 PC directly reachable over the Internet. I use RDG for security reason.

[acomadmin]

We use RDG for external connections (from the internet). I never said it was open to the internet.

It’s internal connections from within our network (desktop/server RDP to desktop/server within corp network) that I want to bypass MFA, which we don’t use RDG for it’s just a direct RDP connection.

I’m not sure what you mean by having the user “route out of the firewall so it can register with a public IP”. If you have any resources you can point me to I’d greatly appreciate it.

[BabbittJE]

Since you do have RDG, never mind about “route out of the firewall…”. So, set up DAG on RDG. Uninstall Duo from Win10 computer. Diagram:

[acomadmin]

Duo support’s reply on using Duo Access Gateway

“The Duo Access Gateway wouldn’t be expected to be implemented at all and doing so wouldn’t change how the authentication policies affect your RDP logins. The Duo Access Gateway is our on-premise SAML 2.0 IDP solution and neither RDP nor RD Gateway utilizes SAML when authenticating users.”

You’ve used this implementation successfully?

[BabbittJE]

Sorry. I have DAG, SSO and Duo for Microsoft Remote Desktop Gateway. The latter is likely what you need. Try looking at Two-Factor Authentication for Microsoft RD Gateway on Windows 2012 and Later | Duo Security.

[DuoKristina]

Did you try adding your internal IP to the authorized networks policy?

[acomadmin]

Duo support stated internal IPs are not allowed for the Authorized Network rules for security reasons. The configuration also states as much:

Specify networks using a comma-separated list of IP addresses, IP ranges, or CIDRs. These must be public IP addresses, and not local or private IP addresses.

Have you been able to use private/internal IPs in the auth network rules?

[DuoKristina]

@acomadmin give it a try. It doesn’t work with all integrations which is why the UI message says that, but for some applications that do not show the web-based Duo interactive 2FA prompt in a browser it is possible to specify a private or internal IP, and Duo for Windows Logon is one of them.

Here’s a Duo KB article that talks a bit more about this.

[bjames]

Are you using User Location as well? There are challenges around using both together.

[BabbittJE]

I know I’m replying to an old post but this fits in this scenario: I have a remote site that we can reach via site-to-site VPN. For some reason, Duo is prompting for authentication when trying to start a RemoteApp. It’s all internal, no public IP addresses. So, I added the private IP address to the Authorized Network and, voila, no Duo prompts. When I looked at the Duo log prior to authorizing the private IP address, it was showing the Duo request came from that private IP address. Bug? Intended? In any case, I had to add that private IP to the Authorized Network even though the description said no private IP addresses, only public ones. If a Duo engineer wants to look at my log, etc., to see why this is happening, I’d be happy to offer.

[DuoKristina]

@BabbittJE nothing you said is unexpected.