What are talking about today?
We all know how strapped the small business can be when it comes to resources. Staff, cash, cash flow, technical skills, and time. Another item is IP space.
When it comes to trifecta of IP space, cash, and technical skills, and then throwing the desire to have Skype for Business (SfB) deliver all communication modalities things can get a bit dicey. Between the need to communicate and the need to conserve cash, what usually gets hammered is the technical skills. So a pricey consultant is called in, who promptly tells you that you need to spend huge wads of cash on a firewall that will accept and deal with larger IP address space. This is counter-productive you might think, and you would be right.
But, Netgear has some answers, and combined with some judicious telecom provider shopping, you may be able to find the answers in the form of a /29 CIDR block.
I won’t try to answer all the questions here, but I do want to illustrate the configuration of the Netgear ProSAFE to support SfB. My issue is that the stock documentation for the Netgear ProSAFE is a bit shy on details. Past the statements that it supports multiple IP’s there is not much in the way of “how to do it” and if you think your ITSP provider is going to help, think again.
Tsoorad to the Rescue
As you might have guessed, Tsoorad.net falls into this category. First off, I am a cheap ba$tid. Second, I have particular needs what with the technical lab and all. Finally, I face the ca$h situation just like everyone else, and when combined with “first off” I decided against purchasing the more expen$ive “indu$try $tandard $olution$.” Still with a bit of reading and learning and poking your nose where the vendors don’t want you to poke it, you can make your system play well with others. I will NOT cover the SIP trunk provider or the reverse proxy stuff here; that you can get elsewhere in other articles.
IP Space
SfB, if you want the full suite of operations and features, is going to require a minimum of two (2) public IP addresses. No way around it. One (1) for the external side of the SfB edge server, and one (1) for the reverse proxy. You can do away with the reverse proxy address, but you will give up inviting outsiders to your web conferences and forget about your mobile clients working. As a side note, you may be able to piggy-back your reverse proxy needs onto an existing IP with 443 and content redirects, but that is usually well past internal SMB technical chops and will have you calling in a provider or con$ultant.
If you want to investigate the minimum IP requirement solution, see this section of the SfB documentation. You can also work up this requirement using the SfB Planning tool. For those tech heads out there, you should be reading this first. Adelante!
The biggest problem with the minimum IP space solution is using port 444 for web conferencing. In my experience, most larger environments will not allow port 444 outbound willy-nilly. Which will mean that crucial web conference that you are hosting on your minimum IP space solution will most likely not have any large corporate attendees.
Enter the /29
Offering 5 usable addresses, the /29 CIDR block is the smallest block that is usually provisioned by providers – other than giving out singles. I use a /29. One IP for general use, one IP for my SIP trunk with Intelepeer (they are great), and three for SfB. For my lab use, I have Office 365 in hybrid, and I also bring port 25 into one of my SfB-assigned addresses and use the firewall to pick off the SMTP traffic and send it to the proper internal server. Works great, less filling. And yes, the Netgear ProSAFE can be configured to support all of this (see how I worked around to the beginning thesis?)
ProSAFE Configuration
Ignoring the unboxing and basic connection steps, the first thing you need to do is configure the firewall for your public IP space.
Next, you may wish to change your things to match your internal subnet to which you are connecting.
Now onto the real fun
SfB has a variety of port requirements. You can refresh your memory here. Assume the following
- IP #1 = SIP
- IP #2 = WebCon
- IP #3 = AV
- IP #4 = reverse proxy
So, IP #1 needs TCP 443, 5061, 5269. Depending on your DNS source, opening TCP/UDP 53 may be needed – this is the for CRL check. IP #2 needs TCP 443. IP #3 needs TCP 443, UDP 3478, and optionally TCP/UDP 50,000-59999. Simple, right? IP #4 needs TCP 443 and 80. If you are confused about the 50k range, see this. Nothing has changed here since Lync 2013.
The Netgear issue
Netgear, like any firewall, blocks by default. So we need to poke some holes. Netgear, like almost everyone else, also provides some predefined services – and you can use them; like HTTPS or SMTP. No sense in re-inventing wheels, eh? The other issue with the ProSAFE is that ALL traffic, by default, goes OUT on whatever IP you assigned as the device primary in that first screen shot. The solution here is to create outbound bindings so SfB traffic goes out on the IP that is expected.
Create Services
Because we are going to use the pre-defined HTTPS service, here is what is needed. I feel that the construction of these services is very self-explanatory.
Inbound/Outbound Services
So here is where the rubber meets the road, or, to not mix metaphors and to maintain our focus, where the electrons meet the transistors. When creating your new outbound rule, what you need to know in advance, is what your NAT is that matches the service to the IP. Enter an IP that is valid for the your CIDR mask and it will work. Typos count against you.
For the inbound service you need to know the exact same thing, and guess what, it looks pretty much the same. A few things of note here. First, you need the NAT information in advance. Also, see the “WAN Destination IP Address:” thing? This is where the Netgear documentation falls flat. Doing multiple IP is simply not mentioned as to HOW. But here you go. Enter an IP that is valid for the your CIDR mask and it will work.
OK. Now that we have that sorted, here is the full outbound rule set…
…and the full inbound rule set.
But wait! The sharp-eyed critic will notice that the rules appear to be doubled-up for the HTTPS and TCP/UDP for WebCon and AV. Yes, they are. Inbound rules are dependent on External DNS resolution, and the outbound rules are dependent on the sending entity having an IP that matches the rule. I keep my lab ready to demonstrate for the unbelievers that doing a single IP SfB (or Lync) edge will result in THEIR environment not being able to connect to a web conference hosted on a single IP Edge server (because of the port 444 thing). Which usually brings them out of the dark into the light which is the greater good. I can live with some topology builder work and some server re-ip – it only takes a few minutes, and saves much teeth-gnashing later. And the firewall don’t care if it has a few rules that aren’t in active use.
Furthermore, the really critical reader will complain that I have said squatoosh about the reverse proxy in all of this. Here’s why: Inbound rule #4 lands on my HLB, which is, by definition, a reverse proxy. I bring ALL miscellanous web traffic for my domains to this one address, land it on my HLB layer, and use content redirect rules to parcel things out to the appropriate target service/server. Works very nice, is totally less filling, and makes me wonder why anyone does anything else.
Let’s Wrap This Up
Netgear ProSAFE can be a great solution for the smaller SMB. Skype for Business can also be a great solution for the smaller SMB. But, to get all that both offer, you need to dig a little deeper than just throwing things at the wall to see what sticks. Single IP Edge works, but it may not be the best choice. Finally, we demonstrated how to make a ProSAFE work with a CIDR block, and also showed the rules needed to enable all of SfB through a ProSAFE device.
YMMV
No comments:
Post a Comment