02-06-2019 04:17 AM - edited 03-08-2019 05:15 PM
Hey everyone,
I hope someone can give me some advice on this as I'm going around in circles at the moment. I can see why it is happening, but can't get to a resolution as yet. Anyway:
At our company we have a switch stack comprised of four 3650 switches. I have recently made the WiFi network secure by providing a guest network on a separate, isolated VLAN to the staff network (guest: 70, staff: 60). Side note: we have eight WAP121 on two clusters.
To this end, I created a DHCP pool for the isolated network that gets its DNS from Google's servers, to keep it separate. There is also an ACL in place for this network to keep it from accessing anything on the staff VLANs.
My problem occurs when anyone connects to the guest WiFi network and attempts to connect to our remote desktop servers by name.
For example, we have four RDS that can be accessed externally (or on the staff network) by remote.example.com, which takes the end user to the RDS broker (192.168.0.100) and from there to the best server to service their request. On the guest network I can access the RDS broker via RDP directly by IP after I have added it in as a permit rule on the ACL. However, this can't be done with remote.example.com.
Obviously, as DHCP from the switch pool applies Google's DNS servers, the clients look up the external address and this is then denied somewhere (excuse my ignorance!).
Is there any way I can apply the DNS from the switch for the guest network, without affecting the existing network? Or get remote.example.com to point to the internal IP of the broker when on the guest network? Or is this an issue at the firewall?
Probably a silly question, but I'm quite new to this and would appreciate some help.
Thanks in advance!!
Example of relevant lines in the running config:
ip dhcp pool GuestWifi
network 192.168.70.0 255.255.255.0
default-router 192.168.70.254
dns-server 8.8.8.8 8.8.4.4
interface GigabitEthernet1/0/25
description WAP
switchport mode trunk
spanning-tree portfast disable
interface Vlan60
description Internal Wifi
ip address 192.168.60.254 255.255.255.0
ip helper-address 192.168.0.1
!
interface Vlan70
description Wireless Guest Network
ip address 192.168.70.254 255.255.255.0
ip access-group blockguest in
ip default-gateway 192.168.0.254
ip http server
ip http authentication local
ip http secure-server
ip route 0.0.0.0 0.0.0.0 192.168.0.253
!
ip access-list extended blockguest
permit tcp any host 192.168.0.100 eq 3389
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
Solved! Go to Solution.
02-08-2019 04:09 AM
Okay.... I've got it working (with a small caveat).
Turns out the ACL on my guest VLAN was to blame. As you know, first I had to allow my restricted network to use my internal DNS server to get the local address correct for the RDS broker (otherwise it was getting our company's external IP). Now I've also had to allow access to all ports on the RDS broker and that seems to have got it working!
So, previously (as per my above config dumps) I had allowed tcp on 3389 to the RDS broker. I have now changed this so any port is accessible and this seems to work. I will need to narrow down what other port it is using (other than 3389) to establish the connection, but it's got me going now. Which is all I need at the moment.
My ACL for the isolated guest Wi-Fi network is now:
5 permit tcp any host 192.168.100.130
10 permit udp any host 192.168.100.1 eq domain
15 deny ip any 192.168.0.0 0.0.255.255
20 permit ip any any
(Where .130 is the broker and .1 is the DC).
Many thanks to all of you for your help with this, especially JC. Glad to find an acceptable solution :)
02-06-2019 04:50 AM
Hi Steve,
Why don't you let your Guest Wifi provide your internal DNS to Guest Users and change your ACL to allow udp/53 ?
Ideally, you should have internal DNS for your users and DNS servers also in your DMZ where your Guest Wifi sould be connected.
Cheers,
JC
02-06-2019 05:48 AM
Hi JC,
Looking through the VAPs on the 121 cluster, it does not allow me to specify DNS servers - I believe these are picked up from the domain controller?
As you see, I specified DNS in the DHCP pool for the guest network on the switches themselves so this kept it separate. If anyone knows of some way to set DNS from the WAPs on the guest network though, that would be perfect!
Unfortunately, it's the good old story of an inherited network. That old chestnut.
Thanks again!
02-06-2019 09:57 AM
You are already allowing RDP access from the guest network so I can't see how allowing DNS is going to make it any worse to be honest.
Jon
02-08-2019 01:17 AM
Sorry for being such a beginner, but I'm not sure how I can enable DNS in the way that you are describing.
I cannot enable it on the WAPs as there is no option to do so for the guest network. I just want to enable the guest network to go to the RD broker via name not IP.
Can I configure the switch to act as a DNS server for the guest network only? If so, what is the possible impact on the rest of the organisation. I want to guarantee no bleed through into the other VLANs that could potentially take the entire network down.
If anyone has any actual commands I can try, that'd be great.
Thanks for your help again!
02-08-2019 01:23 AM
Hi Steve,
In your first post, you show us your DHCP Pool configuration, which makes me believe that the Switch/Router owning this configuration is providing the IP address to the Wifi Guest Client isn't it ?
If your Wifi Guest Client are not receiving their IP address from this pool, then you have to find who is providing IPs to change the DNS that will be devlivered.
Hope this help.
Cheers,
Jean-Christophe
02-08-2019 02:04 AM
Hey Jean-Christophe,
That did clarify things a bit - thank you.. I have now updated the running config to contain the below lines and it is picking up DNS from the internal DNS server okay now (192.168.100.1), but still unable to connect to the broker via RDP. It seems a bit more complicated than I thought.. Any other ideas?
ip dhcp pool GuestWifi
network 192.168.70.0 255.255.255.0
default-router 192.168.70.254
dns-server 192.168.100.1
ip access-list extended blockguest
permit tcp any host 192.168.0.100 eq 3389
permit udp any host 192.168.100.1 eq domain
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
N.B. I also tried allowing RDP access to the DNS server, but this didn't work. To be honest, I'd not want that anyway as it is our DC.
02-08-2019 02:08 AM
Ok.
Can you confirm that your Guest Client have the correct DNS?
If yes, then also allow (temporarly) ICMP from your Guest Client to your DNS Server.
If this doesn't work check your firewall and your routing table.
Cheers,
JC
02-08-2019 02:52 AM
Thanks again, JC, I believe we're getting closer to a solution!
Before enabling ICMP I tried connecting to the RD broker directly via mstsc instead of using the icon we provide to our end users and found that I can connect to the RDS fine. I narrowed it down to the RD connection settings and specifically the fact that it is using RD Gateway server settings (obviously, a standard mstsc connection sets this to automatically detect the RD Gateway server settings).
These RD Gateway server settings are vital for external connections for our home users, so I cannot remove them. And ideally, I don't want to confuse the end users with two icons (one for in the office, one for out), if possible.
On my PC (which is on the internal VLAN) I can use the icon with the RD Gateway server settings fine. It is just the guest network that won't allow this traffic through. I'm now looking into why this might be the case..................
02-08-2019 03:31 AM
Thanks again, JC, I believe we're getting closer to a solution!
Before enabling ICMP I tried connecting to the RD broker directly via mstsc instead of using the icon we provide to our end users and found that I can connect to the RDS fine. I narrowed it down to the RD connection settings and specifically the fact that it is using RD Gateway server settings (obviously, a standard mstsc connection sets this to automatically detect the RD Gateway server settings).
These RD Gateway server settings are vital for external connections for our home users, so I cannot remove them. And ideally, I don't want to confuse the end users with two icons (one for in the office, one for out), if possible.
On my PC (which is on the internal VLAN) I can use the icon with the RD Gateway server settings fine. It is just the guest network that won't allow this traffic through. I'm now looking into why this might be the case..................
02-08-2019 04:09 AM
Okay.... I've got it working (with a small caveat).
Turns out the ACL on my guest VLAN was to blame. As you know, first I had to allow my restricted network to use my internal DNS server to get the local address correct for the RDS broker (otherwise it was getting our company's external IP). Now I've also had to allow access to all ports on the RDS broker and that seems to have got it working!
So, previously (as per my above config dumps) I had allowed tcp on 3389 to the RDS broker. I have now changed this so any port is accessible and this seems to work. I will need to narrow down what other port it is using (other than 3389) to establish the connection, but it's got me going now. Which is all I need at the moment.
My ACL for the isolated guest Wi-Fi network is now:
5 permit tcp any host 192.168.100.130
10 permit udp any host 192.168.100.1 eq domain
15 deny ip any 192.168.0.0 0.0.255.255
20 permit ip any any
(Where .130 is the broker and .1 is the DC).
Many thanks to all of you for your help with this, especially JC. Glad to find an acceptable solution :)
02-08-2019 04:23 AM
Happy to hear it's working.
Probably, you should have a look at M$ Documentation about RDS Broker configuration:
So that you can allow only necessary port in your ACL.
Cheers,
JC
02-08-2019 05:33 AM
Cool thanks, mate. I already tried the following ports:
135
445
3391
5504
88
53
389
I'll try a few more from the MS doc and let everyone know what it was later, just in case anyone else has a similar set up.
Thanks again, very helpful!
02-08-2019 08:47 AM
And just so everyone knows: the other port I needed to allow was tcp 443. So tcp 3389 and 443 are open to the broker, udp 53 to the DC, the guest wireless DHCP pool is set to the internal DNS server on the switch stack and everything else to the internal network is denied.
Good to have it sorted finally.
Thanks everyone for your input! Much appreciated!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide