Can't Load Redirects to ADFS through Meraki Wireless Network

SOLVED
knewyousir
Here to help

Can't Load Redirects to ADFS through Meraki Wireless Network

Hi all- new poster here.

 

I recently set up a new Meraki Org and WAP at one of our orgs' hub sites. I created new SSIDs, installed a demo Meraki MR36, setup a winServer 19 radius server (NPS) onsite, and have authentication against two of our AD groups working properly. For purposes of argument, I will call this SSID "NewNet-Emps".

 

I also have a legacy Meraki WiFi network onsite at the same hub site, housed in a different Meraki Org that was set up by my predecessors. It authenticates to a different radius server across a VPN tunnel to our parent site. For purposes of argument, I will call this SSID "OldNet-Emps".

 

When clients are connected to "OldNet-Emps", they are able to successfully redirect to our org's ADFS page. When clients are connect to "NewNet-Emps" however they are unable to redirect to the same ADFS page. Everything else appears to be working fine.

 

It appears that the connection attempt is timing out because the connection is not considered secure. When connecting to our ADFS site, clients on "OldNet-Emps" show a secure connection via TLS 1.3 while clients on "NewNet-Emps" show "connection not secure" and time out when trying to load the page.


Does anyone know why clients on the "OldNet-Emps" network would be able to make a secure connection with our ADFS page while clients on the other network "NewNet-Emps" cannot?

I would be glad to try any testing suggestions you might have that could help lead to a resolution of these issues.

Thanks for your kind help in advance 🙂

1 ACCEPTED SOLUTION

OK- solved.

 

The other side of the VPN tunnel had a manually configured topology which had an old entry overlapping the range of IPs assigned to "OldNet-Emps". There was no defined topology for the new range I created for "NewNet-Emps".

 

Adding that range of IPs for "NewNet-Emps" on the parent-site side of the VPN tunnel fixed the issue.

Was not a Meraki issue in the end.

 

Thanks for your help.

View solution in original post

5 REPLIES 5
PhilipDAth
Kind of a big deal
Kind of a big deal

Are you using bridge mode on the new WiFi?  And I presume you are not using a splash page?

 

You are allowing local LAN traffic?

https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/'Deny_Local_LAN'_settings_in_Cisco_... 

 

Are the users on the old and new WiFi using the same DNS servers?  Are they in the same subnet?

Hi Philip,

Thanks for your reply.

 

I am using Bridge mode, no splash page (direct access), and am allowing local Lan traffic.

Our router just inside our edge firewall allows all internal networks to communicate with each other.

 

Each SSID has it's own subnet and VLAN on our internal network.

Both IP ranges have separate DHCP servers that hand out addresses properly, and both point at the same DNS servers. Clients can ping the DNS from either SSID/subnet successfully.

Any chance ADFS sits behind a firewall and is not allowing the new WiFi range?

Maybe although I don't understand how if so.

 

I nslookup'd and tracerouted the ADFS site- it's showing as being hosted on an amazon cloud server, so I would think the traffic get's NAT'd by our firewall and handled outside of our site-to-site VPN tunnel. Traceroute showed only WAN hops once outside our firewall.

 

So I moved the addressing and traffic for that SSID to "NAT mode" rather than "Bridge Mode" and the ADFS page now loads fine (Secure connection HTTPS/TLS1.3). Seems like the traffic for the meraki nat'd range of addresses is traversing the network fine while the our local LAN DHCP assigned addresses are not.

 

I guess I can live with the Meraki NAT'ing if I have to, but I'd definitely like to understand why it's behaving this way. Any ideas?

OK- solved.

 

The other side of the VPN tunnel had a manually configured topology which had an old entry overlapping the range of IPs assigned to "OldNet-Emps". There was no defined topology for the new range I created for "NewNet-Emps".

 

Adding that range of IPs for "NewNet-Emps" on the parent-site side of the VPN tunnel fixed the issue.

Was not a Meraki issue in the end.

 

Thanks for your help.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels