Almost all of Cisco's SBCS market is the small and medium business space. Most, if not all of these SMB's have a Microsoft Small Business Server 2003 or 2008. It will be critical, In order for Cisco to be considered as a purchase option, that the UC-5x0 integrates well into these networks.
To that end, I see a lot of talk here about how to implement parts and pieces of this, but no guidance from Cisco, no labs and no best practices or other documentation. If I am wrong, please correct me.
I am currently stumbling through and validating these configurations myself, Once complete, I will post detailed recommendations. However, it would have been nice to have a lab to follow instead of having to learn from each mistake.
Some of the challanges include;
1. Where should the UC-540 be placed: As the gateway for QOS or behind a validated UC-5x0 router/security appliance combination
2. Should the Microsoft Windows Small Business Server handle DCHP (as Microsoft's documentation says it must), or must the UC-540 handle DHCP to prevent loss of features? What about a DHCP relay scheme?
3. Which device should handle DNS?
My documentation (and I recommend that any Cisco Lab/Best Practice guidence include it as well) will assume the following real-world scenario, the same which applies to a majority of my SMB clients;
1. A UC-540 device utilizing SIP for the cost savings
2. High Speed Internet with 5 static routable IP addresses
3. An existing Microsoft Small Business Server 2003/8
4. An additional Line of Business Application or Terminal Server that utilizes the same ports (i.e. TCP 80/443/3389) as the UC-540 and the SBS, but on seperate routable IP's (Making up crazy non-standard port redirections is not an option).
5. A employee who teleworks from various places that provide a seat and a network jack, which is not under our control (i.e. a employees home, a clients' office, or a telework center). This teleworker should use the built in VPN feature within the SPA or 7925G phones because we will not have administrative access to any third party's VPN/firewall.
Your thoughs appreciated.
If you are going to start a white paper on this, I would like to raise my hand at helping with the documentation on this as well, so feel free to kick start something off and bounce it back and forth between all those who want to participate in its creation.
I am more then happy to lend my time to this.
Right now I am working ona deployment documentation program, I have taken the Cisco word source documentation on this and am customizing it to try and capture the full deployment of a UC/CME system.
Let me know if you are interested in moving this way.
I would be greatful for the assistance.
I am in the research phase now.
Here is one reference I have found that is on topic:
I think we should do our best to pass everything through this thread so that others may benefit.
I would love to get some direction from Steve DiStefano, Marcos Hernandez or anyone at Cisco before we reinvent the wheel or go down the wrong road.
Anyway, I will upload a Visio diagram of my proposed topology in a few minutes.
I see where you are going with this, ok cool i will make this a pet project, will need some time on this and will post up another version.
Thanks for that.
The following changes have been made to the router in support of the previously detailed scenario. Everything appears to be working as intended.
DHCP is still on the UC540 for now. DNS is being performed by the SBS 2008.
Interestingly, the CCA still works. The NAT module even shows all the private mapped IP's, but no the corresponding public IP's. I wouldnt recommend trying to make any changes via the CCA in the NAT module.
To review, this configuration assumes the following;
1. The UC540 has a public IP address of 22.214.171.124
2. A Microsoft Small Business Server 2008 using an internal IP of 192.168.10.10 has an external IP of 126.96.36.199.
3. A third line of business application server with www, https and RDP that has an internal IP of 192.168.10.11 and an external IP of 188.8.131.52
First, backup your current configuration via the CCA,
Next, telent into the UC540, login, edit, cut and paste the following to 1:1 NAT the 2 additional public IP addresses;
ip nat inside source static tcp 192.168.10.10 25 184.108.40.206 25 extendable
ip nat inside source static tcp 192.168.10.10 80 220.127.116.11 80 extendable
ip nat inside source static tcp 192.168.10.10 443 18.104.22.168 443 extendable
ip nat inside source static tcp 192.168.10.10 987 22.214.171.124 987 extendable
ip nat inside source static tcp 192.168.10.10 1723 126.96.36.199 1723 extendable
ip nat inside source static tcp 192.168.10.10 3389 188.8.131.52 3389 extendable
ip nat inside source static tcp 192.168.10.11 80 184.108.40.206 80 extendable
ip nat inside source static tcp 192.168.10.11 443 220.127.116.11 443 extendable
ip nat inside source static tcp 192.168.10.11 3389 18.104.22.168 3389 extendable
Next, you will need to amend your UC540's default ACL.
First, copy what you have existing as I have done below (in bold), and paste them into a notepad.
Then, im told the best practice is to delete the entire existing list first, finally adding the new rules back, along with the addition of rules for your SBS an LOB server (mine in bold) as follows;
int fas 0/0
no ip access-group 104 in
no access-list 104
access-list 104 remark auto generated by SDM firewall configuration##NO_ACES_24##
access-list 104 remark SDM_ACL Category=1
access-list 104 permit tcp any host 22.214.171.124 eq 25 log
access-list 104 permit tcp any host 126.96.36.199 eq 80 log
access-list 104 permit tcp any host 188.8.131.52 eq 443 log
access-list 104 permit tcp any host 184.108.40.206 eq 987 log
access-list 104 permit tcp any host 220.127.116.11 eq 1723 log
access-list 104 permit tcp any host 18.104.22.168.35 eq 3389 log
access-list 104 permit tcp any host 22.214.171.124 eq 80 log
access-list 104 permit tcp any host 126.96.36.199 eq 443 log
access-list 104 permit tcp any host 188.8.131.52 eq 3389 log
access-list 104 permit udp host 184.108.40.206 eq 5060 any
access-list 104 permit udp host 220.127.116.11 any eq 5060
access-list 104 deny ip 10.1.10.0 0.0.0.3 any
access-list 104 deny ip 10.1.1.0 0.0.0.255 any
access-list 104 deny ip 192.168.10.0 0.0.0.255 any
access-list 104 permit udp host 18.104.22.168 eq domain any
access-list 104 permit udp host 22.214.171.124 eq domain any
access-list 104 permit icmp any host 126.96.36.199 echo-reply
access-list 104 permit icmp any host 188.8.131.52 time-exceeded
access-list 104 permit icmp any host 184.108.40.206 unreachable
access-list 104 permit udp host 192.168.10.1 eq 5060 any
access-list 104 permit udp host 192.168.10.1 any eq 5060
access-list 104 permit udp any any range 16384 32767
access-list 104 deny ip 10.0.0.0 0.255.255.255 any
access-list 104 deny ip 172.16.0.0 0.15.255.255 any
access-list 104 deny ip 192.168.0.0 0.0.255.255 any
access-list 104 deny ip 127.0.0.0 0.255.255.255 any
access-list 104 deny ip host 255.255.255.255 any
access-list 104 deny ip host 0.0.0.0 any
access-list 104 deny ip any any log
int fas 0/0
ip access-group 104 in
Lastly, save to memory
One final note - if you need to use the Microsoft Windows VPN client from a workstation behind the UC540 to connect to a VPN server outside your network, and you were getting Error 721 and/or Error 800...you will need to use the following commands to add to ACL 104;
(config)#ip access-list extended 104
(config-ext-nacl)#7 permit gre any any
Im hoping there may be a better way to allowing VPN clients on the LAN with a much more specific and limited rule. I will update this post with that info when and if I discover one.
Thanks to Vijay in Cisco Tac for the guidence.
Ultimately this best practice documentation should address every possible scenario as depicted in the attached visio topolgy;
1. A business HQ with SBS on-premise as well as the complete suite of SBCS components from UC to IP video surveillance.
2. The branch office with an SA500 series security appliance (or third-party security appliance), a UC500 series system, and no on-premise server
3. Teleworkers at locations with a router we have no control over that mainly need access to resources in the HQ server and UC.
4. Bring it all together via site-to-site VPN between HQ and branch office, and client server VPN/Easy VPN or without a VPN using direct SSL/TLS/SRTP/etc connectivity between teleworkers and the HQ resources including access to the the SBS server and UC500 series system's full UC features, etc.
With such a best practice document, everyone will have something to take away from it. Some may only need item one for just one location with an on-premise server, some may need item 2 that has no on-premise server (perhaps a client with cloud computing such as Microsoft Online Services - BPOS), some may need either item 1 or 2 in addition to with teleworkers, and some may need the entire scenario for their deployment. So it would essentially be a best practice document to address any and every deployment scenario.
We do several UC500's a month, however I'm not a fan of using Microsoft SBS for anything more than a discounted price for WIndows and Exchange. As a best practice we typically do not use any of the Routing and/or Security features. At most we would use DHCP on the Data VLAN and SBS as a DNS server, too many patches with Microsoft to have it directly connected to the web.
Also as we work with Voice implementations of all sizes, we typically use an ASA in-front of the UC500 products which is really more of a professional preference instead of a best practice, but seems to offer much more flexability than the SR, or SA products and just a inexpensive...
Wish you all the best with this...