Some questions on vlans/switching/routing

[dougken444]

Hi All,

Please forgive If I posted this in the wrong forum. I am still learning how to manage my ASA-5506X device. I have a question regarding vlan, and I was wondering if the experts here can guide me in the right direction. 

Background Info: 

Cisco ASA-5506X Device 

Cisco Smart Switch for VOIP

Ubiquiti Unifi Switch 

4 Interface already setup (Verizon, Comcast, DMZ, and Inside) 

Verizon is used for VOIP as well a failover in case Comcast is down, the ASA will direct all traffic to Verizon.

Inside is the internal network 

and DMZ is DMZ

I am trying to create a wireless guest network, but I would like it to be on its separate subnet. People that are on the guest wireless network should not have access to the internal network. I believe I can do this with a vlan.  As far as accessing the DNS and DHCP go, they should be able to access a public DNS, and I have to tweak the ACLs so it can either access my DHCP server or use the ASA as a DHCP server (not sure if that even works). Can someone please tell me how I can achieve this? 

I added a vlan to the inside interface because the cable coming from that interface goes into the switch. The guest wireless network works, but it doesn't use its subnet. It still points to the internal network for an ip address. 

[dougken444]

Hi Rick,

Thanks for the response. I did monitor the ASA, it doesn't even receive a DHCPRequest which tells me the problem lies somewhere in the switches. 

6 Access points are connected to 6 different ports on the ubiquiti switch. The 6 ports that the access points are connected to are part of a vlan group called corp + Guest which has the corp vlan and guest vlan 30. 

The ubiquiti switch is then connected to SG300 via port 1(trunk & uplink) on ubiquiti to GE25 on SG300. GE25 is setup as an access port. The SG300 is then connected to ASA via port GE3. GE3 is a trunk port which has vlan1 as untagged and vlan30 as tagged. I hope this makes sense. 

Do I have to restart SG300 for changes to effect or it is good to go as soon as the running config is saved? 

[Richard Burts · Accepted solution]

If the ASA is not seeing the DHCP request then it does seem that the problem is something in the switches. I am a little unclear about what is happening on the ubiquiti switch, but the rest of your description does seem appropriate.

Assuming that the SG300 operates similar to the other Cisco switches that I am familiar with (mostly the IOS based switches) then you should not need to restart the SG300 after making a config change. The change should take effect immediately after you make it.

HTH

Rick

[dougken444]

Thanks Rick, 

I was able to figure this out. The access points are now able to contact the ASA for an IP address. The ASA is a little slow in issuing IP addresses, but I think a firmware upgrade should fix that. Thank you so much for helping me figure this out. I appreciate it.

[Richard Burts]

Thanks for posting back to the forum to let us know that you have figured out the issue and that access points are now able to contact the ASA for an IP address. I am glad that you were able to find the solution and that my suggestions were helpful.

HTH

Rick

[dougken444]

Hi Rick,

Back with another quick question. Now that I have setup the Guest_Wifi vlan and the access to the internet is working I want the guests to access a sperate portal and accept the TOS before getting to the web. The unifi controller creates a very nice UI that users are redirected to for TOS acceptance, and I would like to use that. The problem I am running into is that the portal is on my corporate network and user connecting to the guest wifi cannot access the portal (obviously, since the guest vlan is on a lower security level than the corporate network). I figured this would be solved by creating an ACL and allowing https traffic to access the server running the portal. I did create the ACL, but the I still can't reach the portal when I am on the guest network. Any Suggestions? 

[Richard Burts]

Based on what you have described I would think that an access list should be what you need. Perhaps you can post the details of what you configured in the access list and how you applied the access list.

Other suggestions would be to check and make sure that there are no devices in the path in your inside network that might have a problem with packets with a source address in 192.168.18. Also check and make sure that traffic from your portal knows how to communicate with 192.168.18.

HTH

Rick 

[dougken444]

I created a host network object called "guest_portal" and give the internal IP address of the server where the portal software is installed. I then created an ACL on the Comcast interface to allow "any" packets to the host network object that has the service tcp/https. 

[Richard Burts]

Perhaps there is something in your environment that I do not understand. But I am puzzled why you created an ACL on the Comcast interface to allow this traffic. If it is traffic from the Guest Wifi to the portal how would it get to the Comcast interface? I would expect the ACL to be assigned inward on the Guest Wifi interface.

HTH

Rick

[dougken444]

Hi Rick, 

I created the ACL on the guest vlan interface. Below you will find some more details. 

When people connect to my guest network, the ASA issues an address of 192.168.18.x to the host. Then a browser page opens up that will redirect them to guestservices.domain.com:8843. That is where they will accept the TOS, and then they will be redirected to our website domain.com. 

I created an ACL on the guest interface, and the info is below: 

Source: GuestWifiNetwork/24 

Destination: Guest Captive Portal (A network object that holds the IP of the server hosting the guest portal) this server is connected to my internal network. 

Service: https, 8443, and 8843. 

I enabled ICMP, and it works just fine. But for some reason, it still can't connect to guestservices.domain.com:8843. 

Any suggestions? 

[Richard Burts]

If you enabled ICMP and it works fine that is a good start and shows that routing is working. If users still can not connect to guestservices.domain.com:8843 then there must be some other issue. Is it possible that there is an ACL permit for ICMP but not for 8843? Is it possible that there is some NAT issue that impacts these packets? Is it possible that there is logic in the device running guestservices that does not like traffic from 192.168.18?

HTH

Rick

[dougken444]

Dear Rick, 

I am sorry for the late reply. I found some more information that will help us narrow down the issue. By default, in the guest interface, there is an Implicit rule created on the ASA that will allow traffic from any source to any destination with a less secure network, see the image below. When I create the ACL to allow traffic destined for port 8843 it overrides the Implicit rule, and therefore nothing works. How do I preserve the implicit rule (or turn it into an explicit rule) and add an extra rule to allow traffic destined to port 8843? Does it make sense?