cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
900
Views
0
Helpful
9
Replies

WLAN Isolation Exceptions (Need Recommendation)

wkeit
Level 1
Level 1

Hello,

I just inherited a Cisco network several months ago and found a few issues that I thought would be easy to resolve. It's actually giving me some grief since I've not had much exposure to network configs.

 

Currently our WLAN is isolated so that all 192.168.200.x (WLAN) cannot traverse to our core 192.168.100.x (LAN) with a rule of:

 

50 deny ip 192.168.200.0 0.0.0.255 192.168.0.0 0.0.255.255

The problem is, our roaming nodes that are over WiFi cannot connect to our Exchange Server in the 192.168.100.x (LAN).  Split-DNS typically resolves this issue by having the node traverse through the external IP address. Since Split-DNS cannot be achieved as the last company that set up the domain, used the main domain.com space instead of sub.domain.com. 

 

I wanted to see if anyone has any suggestions on what I could to to temporarily fix this issue until I can permanently fix our domain configuration and refresh our network architecture.

 

This has been a sore issue for all staff and would be an easy win for me if it's achievable.

 

Thanks!

9 Replies 9

Hello,

 

I don't know what your security policy is, but you could amend the access list and just allow SMTP/POP3/LDAP from your WLAN network to the exchange server (192.168.1.100 in this sample config).

 

Is that an option ?

 

permit tcp 192.168.200.0 0.0.0.255 host 192.168.1.100 0.0.255.255 eq 25
permit tcp 192.168.200.0 0.0.0.255 host 192.168.1.100 0.0.255.255 eq 110
permit tcp 192.168.200.0 0.0.0.255 host 192.168.1.100 0.0.255.255 eq 389

Thanks Georg. It was something I actually did before posting, but it didn't work. Found out I had it in the wrong order (bottom top, instead of top bottom).

Here's the now completed access-list (with me adding 41, 42, 43):

 

10 permit udp any any eq bootpc
20 permit udp any any eq bootps (1601 matches)
30 permit udp any any eq domain
40 permit icmp 0.0.0.0 255.255.255.0 host 192.168.97.254
41 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq smtp
42 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq 443
43 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq www
50 deny ip 192.168.200.0 0.0.0.255 host 192.168.200.55
60 deny ip 192.168.200.0 0.0.0.255 10.0.0.0 0.255.255.255 (3 matches)
70 deny ip 192.168.200.0 0.0.0.255 172.16.0.0 0.15.255.255
80 deny ip 192.168.200.0 0.0.0.255 192.168.0.0 0.0.255.255 (3174 matches)
90 permit ip any any (34192 matches)

I was thinking the above (41-43) rules should allow me to get from 192.168.200.0/24 traffic and traverse to 192.168.100.11 (exchange server). It doesn't seem to be the case. Tried telnet-ing port 80 and 25 while i was on the 192.168.200.0/24 wifi network to the mail server and it was not letting me through.

 

Thanks again!

Hello,

 

depending on what your network looks like, you might want to change the direction the access list is applied. So if you have it applied outbound (ip access-group x out) try ip access-group X in, or vice versa.

Thanks for the help Georg.  Unfortunately, even with allowing dns, smtp, and http/s for those isolated subnets - the email traffic did not work still.  HTTP/S traffic seemed to work fine, so I know the rules are working.  This may be an unrelated issue to the Cisco ACLs.

 

It may just be easier to re-architect or implement 802.1x at this point since it's on my list of to-dos.

Hello,

 

try and add the keyword 'established' to all the lines in the access list that specify TCP traffic:

 

10 permit udp any any eq bootpc
20 permit udp any any eq bootps (1601 matches)
30 permit udp any any eq domain
40 permit icmp 0.0.0.0 255.255.255.0 host 192.168.97.254
41 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq smtp established
42 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq 443 established
43 permit tcp 192.168.200.0 0.0.0.255 host 192.168.100.11 eq www established
44 permit tcp 192.168.200.0 0.0.0.255 host 192.168.1.100 0.0.255.255 eq 110 established
45 permit tcp 192.168.200.0 0.0.0.255 host 192.168.1.100 0.0.255.255 eq 389 established
50 deny ip 192.168.200.0 0.0.0.255 host 192.168.200.55
60 deny ip 192.168.200.0 0.0.0.255 10.0.0.0 0.255.255.255 (3 matches)
70 deny ip 192.168.200.0 0.0.0.255 172.16.0.0 0.15.255.255
80 deny ip 192.168.200.0 0.0.0.255 192.168.0.0 0.0.255.255 (3174 matches)
90 permit ip any any (34192 matches)

Thanks Georg, I will try your suggestion and get back to you.

Perhaps you just don't have the ports open Exchange needs; SMB comes o mind.

You might try a quick test letting all traffic through to the Exchange server.

Hi Joseph. Thank you for your comment and suggestion.
I am positive that Exchange 2013 only requires 80, 443, 53 and 25 to be opened for our environment. We do not utilize pop/imap or other services. Opening 389 for ldap/ad was even a stretch as the domain controller and exchange server are on the same subnet. Authentication should be going through 443/80 against the activesync service.

 

As far as opening up all service ports - I have done this and it does work.

ref: https://technet.microsoft.com/en-us/library/bb331973%28v=exchg.150%29.aspx

If it works with all ports open to its IPs, but not with your ACL restricting ports, you could then try adding a deny (to its IP) with logging the failure. That should show what it's trying to use that your port permits are missing.