Projects – Justin On VOIP (and more)

Ubiquit USG: Native Dynamic DNS (DynDNS) Integration

Hello World!

This morning’s post will be quick, but hopefully useful. I recently wrote about my experience with acquiring and implementing a Ubiquiti Unifi Security Gateway (USG) as my edge firewall. That post is here.

One of the really handy things that the USG supports native Dynamic DNS integration with several different providers, including mine (DynDNS (now owned by Oracle). I know this isn’t a new feature for network gear to support but it is still a handy one in my book and I’m happy to have it.

The Dynamic DNS integration is incredibly easy to configure from the Unifi Controller interface. Shown below, you can find the Dynamic DNS configuration in the controller settings under Services. I am running version 5.10.25 on this controller. Also shown below is a listing of the supported dynamic dns providers.

An example configuration for DynDNS is shown below. Click the image to enlarge. It is important to note that DynDNS does now require a nominal subscription for this service (roughly $55 a year).

Finally, the host update logs from DynDNS (shown below). My particulars are blue’d out but you get the picture. This definitely beats running an agent on one of my Windows boxes.

I know that this isn’t an exceptionally complicated or exotic feature, but with traditional ISPs not giving out static IPs like they used to it is an important one.

I hope this post has been useful. If you have any questions, please post them in the comments below. More to come on the USG in later posts!

-Justin

Forgive Me Cisco for I Have Sinned (And I Liked It!)

Hello World!

If you’ve read any of my other posts, you have no doubt figured out, that I am a Cisco guy. Cisco’s products have kept me gainfully employed for many years (and hopefully for many years to come). I enjoy their technology but I also know they aren’t the only game in town. I am also painfully aware of what it costs to play their game.

The Problem

Recently, my home network/lab Cisco ASA 5506-x died. This was a long expected outcome from a hardware clock malfunction that Cisco discovered a few years ago, you can read more about it here: https://www.cisco.com/c/en/us/support/web/clock-signal.html. If you have SmartNet support on your products this is a problem, but a covered problem. If, like me, you bought your products on Amazon or Ebay, you are screwed.

The Research

When the 5506-x died, I considered buying a Cisco Next Generation Firewall (NGFW) as a replacement (the 1010 would probably work). I’m not made of money and the thought of paying $800 on the gray market (or even from CDW) had me less than excited. I also considered buying a Sonic Wall, Juniper, or Palo Alto appliance but I don’t have support contacts/contracts for those brands and I want to be able to patch them (this is not a problem with Cisco). I then considered building an Endian or PfSense firewall but by the time I got the right appliance I would be out as much money as the Cisco option discussed above. With my home internet speed being over 100Mbps, I was going to need a very powerful box. In case you are wondering what it takes to build a custom firewall, please see this link for sizing guidelines: https://www.firewallhardware.it/en/firewall-hardware-sizing-guide/. I was quickly running out of viable and reasonably professional options. It was then that I looked at my wall and found one more.

I started using Ubiquiti’s Unifi wireless access points a couple of years ago for a family business. I was impressed by the hardware and actually really liked the controller software as well. Being able to extend SSIDs across multiple access points without giving up backhaul bandwidth (assuming you have LAN drops where you need them) is a professional feature and one that I take advantage of often. Consumer grade multi-unit systems dedicate channels (and thus a portion of total throughput) to the backhaul communication between the “access points” and the base station. I also like the Ubiquiti price. The 802.11ac access point above, was $99 on Amazon. When it came time to put access points in my home the Ubiquiti option was an easy choice to make.

“If their access points are great, maybe I should give their firewalls a try.”

The Decision

The Unifi Security Gateway (USG) is a powerful platform. The architecture follows the versatile Edge architecture that Ubiquiti was originally known for. While the Edge platform devices have individual web interfaces and operate autonomously, the USG registers to and is managed by the Unifi Controller. Luckily, the USG does still include SSH/Console access to the powerful Ubiquiti CLI. The CLI is a cross between Unix, BSD, and Cisco’s IOS but once you understand it, it is very useful.

There are currently three (3) models of the security gateway available…

USG
- 3 1G ports
- $138 + shipping on Ubiquiti Store
USG‑PRO‑4
- 4 1G ports (2 with dual-personality SFP ports)
- $344 + shipping on Ubiquiti Store
USG-XG-8
- 8 10G SFP+ ports
- $2,499 + shipping on Ubiquiti Store

I chose the USG. Small but mighty! Price aside, this little box will handle more bandwidth than I can currently throw at it*. With that said, the price is nice too.

*This is without IPS (currently beta) enabled. If you enable IPS the hardware offload is turned off and all packets are processed via software. This limits the throughput of each device as follows…

USG: 85Mbps
USG-Pro-4: 250Mbps
USG-XG-8: 1Gbps

With the above numbers, I will probably be replacing my USG with a USG-Pro-4 (or whatever the next generation option is) in a few months. I want to take advantage of the IPS functionality but don’t want to limit my Internet bandwidth. Currently, this is a minor concern.

The Configuration

Setting up the USG took more time than you might expect. Part of this was my architecture; Ubiquiti likes their routing devices (the USG in this case) to be the end-all/be-all Layer 3 device in the network. In my network, that is not the case. I traditionally run my firewalls in transparent mode and use a Layer 3 “core” switch to handle the inter-vlan routing and segregation of traffic. I want the firewall to terminate the WAN/Internet connection and secure the connection as well as handle the NAT/PAT responsibilities but I want it to end there. My logical configuration is laid out in the image below.

As you can see from the logical diagram above, my USG sits in the “normal” firewall position between the provider NIU and my LAN. I am handling all VLAN routing and inter-VLAN routing on the 3750x. On the switch I have a static default-route pointing at 10.10.0.230 (the LAN IP of the USG) (shown below).

ip route 0.0.0.0 0.0.0.0 10.10.0.230

In the USG I have routes going back to the my 3750x (10.10.0.254) for the networks configured there (shown below).

static {
        route 10.10.10.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }
        }
        route 10.10.30.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }
        }
        route 10.10.100.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }

Finally I have a NAT rule in the USG allowing everything that goes out of eth0 (WAN) to be source NAT’d accordingly (shown below). This works well as I have a DHCP connection from my ISP.

rule   type  intf     translation
----   ----  ----     -----------
6001   MASQ  eth0     saddr ANY to X.X.X.X
    proto-all         sport ANY

Conclusion

I admit it is still early (as I’ve only had the USG in place for about a week), but I am impressed by that little box. No loss in throughput and I enjoy having the Internet statistics on my Unifi mobile application. The USG wasn’t my first choice but the more I do with it the more I am convinced it was the right choice for my environment.

Below are a few quick additions that I didn’t get to cover in this post, I plan on adding posts for these features later…

NAT/PAT for Cisco Unified Border Element (CUBE)
Dynamic DNS (DynDNS) native integration
Quick and Easy VPN Client configuration

-Justin

My Linux Logging Adventure: RSyslog

Hello World!

If you are still reading after the title of this post, I commend you. Writing about logging, and more specifically, a syslog server is difficult to get excited about and I can only assume that it is equally hard to get excited about reading.

I should preface this by saying I am not a “Nix” guy. I’ve dabbled in nearly every flavor of Linux over the last 20 years or so but I’m definitely not a Linux over Windows guy (with the notable exception of purpose-built hardened linux appliances) nor will I ever claim to be. With that said, I like the simplicity of Linux specifically in the utility space. A Linux TFTP/FTP/SFTP server makes far more sense than a Windows box doing the same job, as does a Linux jump box (depending on what you are jumping to). To that end, when I decided to add a syslog server to my lab/development environment; Linux was far and away the best choice.

I am choosing to use Ubuntu as my flavor of choice for this particular Linux project as I generally like the look and feel of it. I am using the server distro and while I am now running 18.0.4 LTS, I did not start out that way. I tried 18.0.4 as a fresh install in my virtual (VMWare ESXi) environment but found that I could not get past configuring the network interface in the setup UI. I would verify the interface (it was correct) and then setup my IP address (static in this case, although I did also try DHCP). This seems simple enough, but once I attempted to save my network settings the UI would reset and I would once again be back at the start of the setup process. I experienced this several times before I gave up and went another way. The “Other Way” in this case was to first install release 16.0.4 and then allow the system to upgrade to 18.0.4. This worked without problem. I just so happened to have 16.0.4 in my software repository but I’m sure I could have upgraded from other releases as well. In doing some research, it seems that Ubuntu introduced a different network configuration manager in 18.0.4 and I’m guessing that it was not playing nice with ESXi.

Now that I have my Linux platform, the installation of the RSyslog server packages is unimpressive. The command to fetch and install the package on Ubuntu is listed below.

apt-get install rsyslog

Once the install is complete the configuration can begin. If all you want is an external place to drop your syslog data this will take no time at all.

In /etc you’ll need to edit the rsyslog.conf file. For the most basic functionality you need to make sure that RSyslog is listening. In my environment UDP for syslog is fine and I also use the standard port (514).

When you initially open the configuration file you’ll notice that UDP (and TCP as well) are commented out. This means that RSyslog is only processing local syslog events (See snippet below).

# provides UDP syslog reception
# module(load="imudp")
# input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

Since I am using UDP, I want to un-comment the module and input lines associated to that protocol (see snippet below).

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

Once I have done this, I can restart the RSyslog service and my server is now ready to receive. The restart command is below for your reference.

sudo systemctl restart rsyslog

Upon a successful restart (assuming there is a device setup to send syslogs), I should see new messages in my syslog file located at /var/log/syslog (snippet shown below).

Mar 18 06:25:02 linutil01 rsyslogd: [origin software="rsyslogd" swVersion="8.32.0" x-pid="1051" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Mar 18 15:30:01 vmhost02.sprnet.local Rhttpproxy: message repeated 2 times: [ verbose rhttpproxy[FFFC3B70] [Originator@6876 sub=Proxy Req 01543] Resolved endpoint : [N7Vmacore4Http16LocalServiceSpecE:0x1f08e318] _serverNamespace = /sdk _isRedirect = true _port = 8307]
Mar 18 15:30:01 vmhost02.sprnet.local Rhttpproxy: message repeated 2 times: [ verbose rhttpproxy[56E54B70] [Originator@6876 sub=Proxy Req 01543] Resolved endpoint : [N7Vmacore4Http16LocalServiceSpecE:0x1f08e318] _serverNamespace = /sdk _isRedirect = true _port = 8307]

In the above snippet, there are three entries. The first entry is from my local Linux box (linutil01) and the next two are from one of my VMWare ESXi hosts (vmhost02.sprnet.local).

If you have a small environment and only a handful of devices sending to your syslog server, the above configuration may be all you need. If, like me, you want something that is more organized, I think I can help.

While there are several ways of accomplishing organization in RSyslog, I am choosing to organize my logs by hostname and service name. For the purposes of this example, I have two ESXi hosts that are logging to the server.

To start, I need to go back to the rsyslog.conf file that I wrote about earlier. I need to tell the server what logs I want to be stored and where/how I want to store them. I can do this with a template. I’ve posted the template configuration snippet below.

# Templates
$template RemoteHost,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
#Remote Logging
$Ruleset remote
*.* ?RemoteHost
#Bind Ruleset to UDP Listener
$InputUDPServerBindRuleset remote
$UDPServerRun 514

In the snippet above, I have my template name RemoteHost and I have where I want to store/categorize my logs /var/log/%HOSTNAME%/%PROGRAMNAME%.log. The %HOSTNAME% and %PROGRAMNAME% sections are variables and are filled in by the servers internal syslog facilities. Note that I have logs being stored in the /var/log/ directory. If you want to store your logs here you will have to change ownership properties of the directory (snippet below) so that syslog can create and write there. I also have a Ruleset that I am binding my template to. In my configuration that ruleset is called remote. I bind my template to the remote ruleset which includes every message coming into the server on UDP port 514.

cd /var && sudo chown syslog:syslog log

Once I complete the configuration above and restart my RSyslog service, I should start seeing directory entries like the ones shown below in my /var/log/ directory.

drwxr-xr-x 2 syslog syslog 4096 Mar 16 13:56 vmhost01.sprnet.local
drwxr-xr-x 2 syslog syslog 4096 Mar 16 13:55 vmhost02.sprnet.local

If I go into one of these directories, I should see several different .log file entries (snippet shown below).

-rw-r----- 1 syslog adm 0 Mar 16 13:55 bootstop.log
-rw-r----- 1 syslog adm 10263 Mar 16 11:15 cimslp.log
-rw-r----- 1 syslog adm 97516 Mar 18 07:01 crond.log
-rw-r----- 1 syslog adm 10474 Mar 18 07:01 heartbeat.log
-rw-r----- 1 syslog adm 777730 Mar 18 07:00 hostd-probe.log
-rw-r----- 1 syslog adm 5345 Mar 18 06:01 ImageConfigManager.log
-rw-r----- 1 syslog adm 0 Mar 16 13:55 init.log
-rw-r----- 1 syslog adm 3033018 Mar 18 07:01 Rhttpproxy.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 root.log
-rw-r----- 1 syslog adm 0 Mar 16 13:55 sfcbd.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 sfcbd-watchdog.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 sfcb-ProviderManager.log
-rw-r----- 1 syslog adm 6384 Mar 18 06:36 sfcb-vmware_raw.log
-rw-r----- 1 syslog adm 16384 Mar 16 13:56 slpd.log
-rw-r----- 1 syslog adm 171223 Mar 18 06:35 smartd.log
-rw-r----- 1 syslog adm 47693 Mar 18 07:00 syslog.log
-rw-r----- 1 syslog adm 128 Mar 15 16:05 tmpwatch.log
-rw-r----- 1 syslog adm 4096 Mar 16 13:55 vmauthd.log
-rw-r----- 1 syslog adm 6189399 Mar 18 07:01 vmkernel.log
-rw-r----- 1 syslog adm 827731 Mar 18 07:00 vmkwarning.log
-rw-r----- 1 syslog adm 0 Mar 16 13:55 VMware.log
-rw-r----- 1 syslog adm 3633994 Mar 18 07:01 vobd.log
-rw-r----- 1 syslog adm 69577951 Mar 18 07:01 Vpxa.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-cdp.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-dcbd.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-net-lacp.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-net-lbt.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-nscd.log
-rw-r----- 1 syslog adm 0 Mar 16 13:55 watchdog-openwsmand.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-sdrsInjector.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-smartd.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-vobd.log
-rw-r----- 1 syslog adm 0 Mar 16 13:56 watchdog-vpxa.log

I now have an organized version of the chaos that syslog directories often hold. I can look at the systems and services that I need to without sorting through all of the other notifications that often get in the way.

I hope this has been helpful to someone, there are a lot of great resources online and mine is simply a collection of what worked for me. Thank you for reading, please ask any questions in the comments section and I’ll do my best to respond in a timely manner.

-Justin

Cisco’s Virtual CUBE & Modern IOS Toll Fraud Security

Good Morning Web World!

I found myself with a little bit of time this morning and I thought I’d share a bit of my latest tinkering.

Those of you that have followed this blog for a while may remember my first post where I talked about pointing a CUBE through an ASA out to my ITSP, Flowroute. That post is located here for your reading pleasure.

While the software/hardware has changed with my setup the idea is basically the same. I still have a CUCM system (now 11.x) running with a phone (I’ve felt like being different lately so currently I’m using a retro 7985G as my endpoint (G in this case does not mean Gigabit)). I also have a firewall, a Cisco 5506-X (it was time for an upgrade from the 5505) and I do still have a CUBE. My previous CUBE was a 3825 and it worked wonderfully but the 3825 has long since outlived its relevance in today’s enterprise environments. In my stack of possibilities I also have a 2921 and while it is still a very powerful and valid router, it just seems too easy.

Simple and straight forward is great but only until you’ve done simple and straight forward, then it becomes time to mix it up.

To that end, my replacement CUBE is virtual. Yes, I said virtual. If you follow Cisco and their products, you may already know about the Cloud Services Router, the CSR1000V. The CSR1000V is a virtual router that runs on a VMWare ESXi host. It runs IOS XE though there is some Linux/Unix on the backend that makes it tick.

When I first heard that it was possible to turn a CSR1000V into a CUBE, I was skeptical. As I have worked through the configurations and witnessed it work, I must say I am impressed. The configuration is the same as with any other IOS XE router with exception of the interface naming conventions. There are three (3) Gigabit Ethernet interfaces and they are named Gigabit Ethernet 1, Gigabit Ethernet 2 and Gigabit Ethernet 3. The configuration in ESXi is shown below.

In my case, I created three (3) separate interfaces on my vSwitch and pointed them at three (3) separate VLANs in my infrastructure. You could bond/Port Channel these interfaces if you wanted too but you will still be limited by the throughput of your host’s uplink(s).

A few important things to note…

When you deploy the OVA file in ESXi you are given a choice of multiple router “sizes” i.e. memory and processor. I am using the smallest size which is one vCPU and 4GB of vRAM. Some of the larger installations require an additional license.
Keep in mind that I am testing this configuration in a controlled lab environment. I am not sure of scalability and if you read Cisco’s CUBE configuration guide, located here, you’ll see that the virtual CUBE does have several restrictions that may make it impractical for some organizations.
The CSR1000V is a fully license-dependent platform. Once the demo runs out the router runs, but only with throttled performance. If you intend to deploy this solution, you will have to purchase licensing.
In my previous post, my 3825 CUBE was running 12.4 IOS which did not include Toll Fraud Prevention, starting in 15.x and moving through IOS XE you need to be mindful of TFP and what it means when you are trying to make/receive calls on a Cisco H.323 or SIP Gateway.

Let’s talk for a moment on Toll Fraud Prevention. As stated above, all modern IOS and IOS XE versions include Toll Fraud Prevention mechanisms and if you use a router, physical or virtual, for voice you need to be aware of them.

If you look at the configuration snippet above, you’ll see that in the voice service configuration there is a trusted IP Address list. That list contains the IPs of my ITSP and my CUCM. If I remove those IPs from the list, calls fail. If you are linking your CUBE or gateway to multiple CUCMs or other systems you’ll want to have those IPs in that list as well. What this list does is let the good/known IPs in to complete transactions/calls on the gateway/CUBE and keeps the unknown/bad IPs out to prevent them from placing calls on the system. IP addresses that are part of dial peers will be added to the list automatically but will not show up in the configuration. If you’ve ever set up an IP PBX on internet, you know that Toll Fraud is a real and serious threat. If you don’t want or need this feature you can turn it off by entering “no ip address trusted authenticate” in your voice service configuration. This is not a recommended configuration but in your environment the TFP mechanisms may do more harm than good.

Thanks for reading, I hope this has been informative.

-Justin

Configuration Example: Cisco CUBE with FlowRoute

So you’ve decided to step-up and get a “Big Boy” phone system. You’re done with CME and you’ve moved to Call Manager (Cisco can call it whatever it wants, but to many of us it will always be Call Manager). But wait, there is a problem… Call Manager won’t natively peer to your ITSP, so what do you do? While there may be many solutions, the best one that I have found involves using Cisco’s Unified Border Element or CUBE. CUBE, for those of you new to Cisco voice technology is a fancy term for a SIP proxy. The CUBE pairs with your ITSP and routes calls to and from your Call Manager via SIP or H.323 . Below is the topology that I am working with. Yours may look a little different and we’ll get into these differences as we progress.

I mentioned topology differences and the biggest one is probably the firewall (ASA 5505) sitting between my CUBE and my ITSP. In an ideal world I’d give my CUBE router a public address and let it talk directly to the internet, this is not an ideal world. My ISP is small and stingy with their public IP addresses. It took a few fights and some extra cash to get one dedicated public IP on my ASA and getting a second is simply not worth the trouble. I’ve read all of the stories regarding trying to pass SIP through a firewall and while there are some caveats, I’ve made it work.

Connectivity is Everything…

It seems like a simple enough statement, but in terms of building and maintaining voice network connectivity really is everything. I prefer to keep it simple and the simplest way to build my topology was to keep the same protocol throughout. With the exception of the SCCP Phone (Call Manager does just fine translating SCCP to SIP and vice versa) every other connection is SIP.

Call Manager to CUBE & CUBE to Call Manager – SIP
CUBE to ITSP & ITSP to CUBE – SIP

By keeping the majority of my transactions SIP, I take away at least one point of failure. I mentioned earlier that you could configure the CUBE router connection to CM via H.323 and while I know that configuration can work just fine, why make it more complicated than it needs to be? The biggest thing to keep in mind when deciding on connectivity is “Can I troubleshoot it easily when it does not work?” Its a lot easier to look at a straight SIP trace.

Bring on the configs…

We’ll start with the CUBE first (This CUBE is running archaic 12.4 code).

The voice service commands are pretty standard. In the allow-connections section sip to sip is the key portion. Remember to configure your sip registrar settings here as well.

The next piece we’ll look at, are the voice translation rules. The first rule points my DID (I only have one in this scenario) to an extension on my CM. The second rule puts my DID as the number mask for all outgoing calls. Without this second translation, I’d have to do additional configurations in CM, the translation rule is easier.

Now, we’ll look at the dial-peers. I’ve got one for the incoming calls (from the ITSP) (Dial-peer 2) One for outgoing calls (I’m just dealing with LD calls right now) (Dial-peer 10) and one for communication with CM (Dial-Peer 100). Note where I applied my translation rules.

Finally, we’ll look at the SIP-UA (SIP User Agent) configuration. This is the actual heart & soul of CUBE. This is the connection and authentication to the ITSP. You may find that your ITSP we’ll peer with your specific public IP address rather than give you a user-id and/or password. Peering with an IP is in theory much more secure as spoofing an IP end to end is much more difficult. Notice the credentials and authentication sections. They both include a username and password. The credentials line identifies your CUBE to the ITSP and the authentication line gets you through door.

Next, we’ll take a look at the CM trunk configuration (My CM is 9.x)

First the initial configuration of the trunk. You’ll assign your device pool, media resources and things of that nature here…

Now, we’ll look at the incoming calls section of the trunk config. You’ll want to make sure that you direct inbound calls to the Calling Search Space that includes the Directory Numbers that you intend to answer the calls. You can also adjust things like significant digits. Generally speaking, I always want the CUBE/router to send me everything and then I’ll configure CM to pick and choose what it wants.

Finally, we’ll look at the connectivity section of the SIP trunk config. Here you’ll specify the address of your CUBE and your SIP and SIP Security profiles. These are standard profiles from Cisco and no tweaking is required to make this work.

Like most other things that Cisco creates, there are far more options in the trunk configuration than most configurations will require.

Finally, lets take a look at the ASA (This ASA is running 8.4(7) code)

First, we’ll take a look at my network and service objects. For this scenario, I defined the RTP range and SIP protocols. While not necessary, I defined SIP with both UDP and TCP entries.

Next, we’ll take a look at the NAT statements. While the CUBE is not a NAT aware SIP Proxy, the ASA provides some assistance in maintaining the end to end SIP headers required for successful peering and usage.

Finally, we’ll take a look at the access-list portion of the configuration. These are pretty straight forward…

Additional Notes…

The phone & route pattern configurations for this example are not impressive. The phone (7961) is configured with a Directory Number and pointed at a CSS with access to PSTN calling features. The basic route pattern is configured as 9.1XXXXXXXXXX and pointed at the SIP trunk created above. I discard the 9 (pre-dot) and send 11 digits to my ITSP. You don’t need the 9 but it keeps the scenario in line with most business systems.

I’ve struggled to find an ITSP that supports a true integration with the CUBE. There are several ITSPs that work with Asterisk and other open-source IP PBX platforms but CUBE is its own animal and as such these “Asterisk ITSPs” usually don’t work properly or in many cases don’t work at all. When I came across FlowRoute http://www.flowroute.com I was initially skeptical but as I’ve used their service more and more, I’ve become a bigger and bigger fan. The first thing that you’ll notice about FlowRoute is that anyone can try it out. Simply sign up and you’ll get some free time (minutes to place test calls) to peer with them and try your system out. If your system doesn’t work and/or you aren’t happy with the performance, go another direction. If (and this is much more likely) you really enjoy the service. Deposit some money, purchase a DID and keep on going.

Final Thoughts…

I hope this example configuration has helped someone. What I’ve shown is not difficult and is actually quite simple when compared to other voice configurations. That being said, we all need to learn somewhere and hopefully I’ve helped someone do that.

**DISCLAIMER** All information posted in this article was accurate as of the date/time it was posted. Images posted in this article follow the same copyright guidelines as the article itself. Plagiarism is not a gray-area issue, it is wrong and in some cases illegal. If you like this article link to it, do not copy it.

Category: Projects

Ubiquit USG: Native Dynamic DNS (DynDNS) Integration

Forgive Me Cisco for I Have Sinned (And I Liked It!)

My Linux Logging Adventure: RSyslog

Cisco’s Virtual CUBE & Modern IOS Toll Fraud Security

Configuration Example: Cisco CUBE with FlowRoute

Menu