Main Nav

As much as I hate it, I’ve been told to setup an open wireless network for our campus.  I created a vlan with access lists that deny  all traffic to inside our network, and created the open SSID to put on it.  Traffic can flow freely now from the open wireless to the internet.

 

However, I’m using a public DNS for the clients and they’re unable to reach our locally hosted (NAT’d) web servers.  We’re currently using a Cisco ASA at the edge of our network which does all of our NAT’ing.  I could open up the VLAN access list a bit and allow them access to our internal DNS & web servers, but I’d rather not.

 

Has anyone run into this issue before?  What’s the “best practices” at this point… other than removing the public network in the first place! 

 

Thanks in advance,

 

Allen

 

Comments

You have a couple of options. 

What we do is have split DNS (our inside network is RFC1918, outside is public, only public servers are on our external DNS).  The external nameservers technically live inside our firewall/IPS/etc protection, so they're "on-campus".  We can point guest/etc "outside" users at the external DNS, and they get "outside" IPs for any internal resources, so they "hair-pin" out to the edge and back through the firewalls to gain access (we also ACL block direct).

It sounds like you have uniform DNS.  You can still point them there, allow their range recursive access, but be careful that you don't do "DNS inspection" on that traffic or they'll get converted back to private inside addresses.

If you have true internal vs external DNS, this is much easier to swing that trying to make a uniform one "dual personality"  :)

If you have them using public DNS (I don't know if you are referring to "your" public DNS, or a 3rd-party "public" DNS) they should be getting outside IPs, and it's just a matter of allowing their range to hair-pin back through the firewall (you may need to loop through your edge/border if you don't allow same-interface traffic).  Or are  you "wanting" them to get internal IPs?  In the latter case you might reinstate the DNS inspection / NAT rewrites, but again, be careful with the split-personality roles.

Jeff

On 10/2/2012 9:56 PM, Allen Wood wrote:

As much as I hate it, I’ve been told to setup an open wireless network for our campus.  I created a vlan with access lists that deny  all traffic to inside our network, and created the open SSID to put on it.  Traffic can flow freely now from the open wireless to the internet.

 

However, I’m using a public DNS for the clients and they’re unable to reach our locally hosted (NAT’d) web servers.  We’re currently using a Cisco ASA at the edge of our network which does all of our NAT’ing.  I could open up the VLAN access list a bit and allow them access to our internal DNS & web servers, but I’d rather not.

 

Has anyone run into this issue before?  What’s the “best practices” at this point… other than removing the public network in the first place! 

 

Thanks in advance,

 

Allen

 


Message from ahockett@warnerpacific.edu

Jeff, Good read. How are you handling DHCP on what I'm assuming is your core firewall that keeps the public away from the private? We're facing a similar push and I'm looking at moving all resnet and wireless to a "public" vlan that just dumps it to the net with public DNS (Google or Century link) but I'm looking for suggestions on how to handle DHCP off a single public IP via NAT. Thanks. -Aaron Warner Pacific College Network Engineer Jeff Kell wrote: You have a couple of options. What we do is have split DNS (our inside network is RFC1918, outside is public, only public servers are on our external DNS). The external nameservers technically live inside our firewall/IPS/etc protection, so they're "on-campus". We can point guest/etc "outside" users at the external DNS, and they get "outside" IPs for any internal resources, so they "hair-pin" out to the edge and back through the firewalls to gain access (we also ACL block direct). It sounds like you have uniform DNS. You can still point them there, allow their range recursive access, but be careful that you don't do "DNS inspection" on that traffic or they'll get converted back to private inside addresses. If you have true internal vs external DNS, this is much easier to swing that trying to make a uniform one "dual personality" :) If you have them using public DNS (I don't know if you are referring to "your" public DNS, or a 3rd-party "public" DNS) they should be getting outside IPs, and it's just a matter of allowing their range to hair-pin back through the firewall (you may need to loop through your edge/border if you don't allow same-interface traffic). Or are you "wanting" them to get internal IPs? In the latter case you might reinstate the DNS inspection / NAT rewrites, but again, be careful with the split-personality roles. Jeff On 10/2/2012 9:56 PM, Allen Wood wrote: > > As much as I hate it, I've been told to setup an open wireless network > for our campus. I created a vlan with access lists that deny all > traffic to inside our network, and created the open SSID to put on > it. Traffic can flow freely now from the open wireless to the internet. > > > > However, I'm using a public DNS for the clients and they're unable to > reach our locally hosted (NAT'd) web servers. We're currently using a > Cisco ASA at the edge of our network which does all of our NAT'ing. I > could open up the VLAN access list a bit and allow them access to our > internal DNS & web servers, but I'd rather not. > > > > Has anyone run into this issue before? What's the "best practices" at > this point... other than removing the public network in the first place! > > > > Thanks in advance, > > > > Allen > > >
On 10/2/2012 11:49 PM, Aaron Hockett wrote: > Jeff, > > Good read. How are you handling DHCP on what I'm assuming is your core firewall that keeps the public away from the private? We're facing a similar push and I'm looking at moving all resnet and wireless to a "public" vlan that just dumps it to the net with public DNS (Google or Century link) but I'm looking for suggestions on how to handle DHCP off a single public IP via NAT. We are also an Aruba shop (to follow-on to Bruce Osborne's reply) so all of the wireless users traffic comes back to the controllers, but the traffic is routed by an attached router that terminates each of the user "roles" (vlans). The "guest" role consists of a couple of vlans (to differentiate what sort of guest, we have slightly different policies) in a guest VRF. We also have some wired guest vlans in the same VRF and can offer the same limited/restricted access over wired and wireless (wired being popular with media folks at sporting events). The guest VRF is basically just a default route to our border, and DHCP hands out our external name servers (rather than internal) so you get only the public services we offer to anyone else on the internet. As for DHCP, you're going to have to hand out some RFC1918 network to the guests; the NAT will be handled by your router and/or firewall. If you "truly" terminate the guests outside your firewall, you're going to have to find another way to handle NAT. Ours are physically inside our firewall, but the traffic is "escorted to the door" (outside access) as soon as it lands, and NAT occurs on the way out. Jeff
Message from mail@jeffmoore.com

Interesting. That sounds like a model we originally started with on our wireless. Initially our wireless was a broadcast ssid that was wide open. Because of this we treated it as a non trusted network and gave it its own firewall and external address space(Just enough to do PAT). Also we forced it to use the smaller of our two links so that if things went south the rest of our traffic would be unaffected. Also we didnt give it any IPs from our nets that are associated to our ASNs. So if the link failed the open network failed(small trade off for isolation. and one that has worked with the QOS we provided. This is changing). We have changed allot since then and are working toward full individual client authentication via our new PaloAlto firewalls.
As for DNS We simply pointed to our external DNS. We have two domains one internal and one external. With the PIX/ASAs you can use the "dns" flag in your statics and the firewall will then automatically translate to the internal IP even though DNS is replying with an external address. But I am assuming you are setup the other way around with an internal DNS that you want to pull from. Am I reading this correctly? Not sure if the DNS flag will work downstream. Would be interesting to see.Maybe that will help. Sorry for the rudimentary answer.
 One of our perl gurus here has written a nice web page here to get guest credentials setup for radius. Is that something you all have considered? If you would like I can put you in touch with him. I am sure he would be more than happy to share his script. Its version 1.0 and hasn't been deployed yet but he is really good so I doubt there will be much polishing needed. Also if you are wanting ammo to push back on open networks use the ol CALEA ammo! That will stop administration in their tracks! ;)

Good Luck!

Jeff M
CCC

Best Practices:

* Disallow all other protocols than HTTP and HTTPS on the standard ports.
* Allow VPN.
* NAT to a public IP outside your public IP address space.
* Require a capture page with a 'Accept our policy' button (along with your legal notice).  But don't rely on any info (this is why we don't ask for the guest's email).
* Restrict the bandwidth (or you will end up having your internal students, staff and faculty using guest wireless rather than your secure wireless.
* Make certain that guest wifi traffic has to pass through your external firewall rather than being handled by just a router.
* Log the WiFi physical addresses using your guest wifi (e.g. Log at the DHCP server and/or NAT) to track if internal users are using the guest network rather than secure wifi???

From: Allen Wood <awood@HILLCOLLEGE.EDU>
Reply-To: EDUCAUSE Listserv <SECURITY@LISTSERV.EDUCAUSE.EDU>
Date: Tuesday, October 2, 2012 9:56 PM
To: EDUCAUSE Listserv <SECURITY@LISTSERV.EDUCAUSE.EDU>
Subject: [SECURITY] Public Use VLAN (x-posted to netman listserv)

As much as I hate it, I’ve been told to setup an open wireless network for our campus.  I created a vlan with access lists that deny  all traffic to inside our network, and created the open SSID to put on it.  Traffic can flow freely now from the open wireless to the internet.

 

However, I’m using a public DNS for the clients and they’re unable to reach our locally hosted (NAT’d) web servers.  We’re currently using a Cisco ASA at the edge of our network which does all of our NAT’ing.  I could open up the VLAN access list a bit and allow them access to our internal DNS & web servers, but I’d rather not.

 

Has anyone run into this issue before?  What’s the “best practices” at this point… other than removing the public network in the first place! 

 

Thanks in advance,

 

Allen

 

 

 

From: H Morrow Long [mailto:morrow.long@YALE.EDU]
Sent: Wednesday, October 03, 2012 11:24
To: SECURITY@LISTSERV.EDUCAUSE.EDU

Best Practices:

 

*              Disallow all other protocols than HTTP and HTTPS on the standard ports.

 

  Note that this means no Skype.  I’m still hoping Microsoft will fix that, and preferably make the “supernode” function visible and OFF by default…..

Skype does open up and listen on TCP ports 80 and 443 (in addition to one random high-numbered TCP port).

 

Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.