This isn’t exactly the latest news, and doesn’t effect the CCIE Voice Lab exam (although it very well may effect the new CCNP Voice exams), however I am hearing more and more how people are upgrading their Voice routers with newer 15.x IOS code, and not realizing how existing (working) VoIP calls are being broken due to new, intelligent feature default configurations.

Last July, Cisco decided (wisely, IMHO) to create a new style of Toll-Fraud prevention to keep would-be dishonest people from defrauding a company by placing calls through their misconfigured voice gateway(s), at the company’s expense. This new mechanism works by preventing unintended TDM (FXO/CAS/PRI) and VoIP (H.323 & SIP) calls from being able to be placed through a given company’s voice gateway(s), by simply blocking all unknown traffic. Beginning in IOS 15.1(2)T, Cisco added a new application to the default IOS stack of apps that compares all source IP address with an explicitly configured list in the IOS running config, and if the IP address(es) or subnets do not match, all VoIP traffic is denied. Also, the new default for all POTS voice-ports is to not allow secondary dial-tone, making direct-inward-dial the default for CAS/PRI, and PLAR necessary for FXO.

We can trust our VoIP sources with a few, very easy commands.
If we wanted to trust only our CUCM Publisher and Subscribers servers on our GradedLabs Voice Racks, we would add:

voice service voip
  ip address trusted list

Or possibly if we wanted to trust the entire subnet that our servers were on, we would add:

voice service voip
  ip address trusted list

We also have the ability to go back to pre-15.1(2)T behavior by simply doing either this:

voice service voip
  ip address trusted list

Or this:

voice service voip
  no ip address trusted authenticate

Also, we have the ability to configure the router for pre-15.1(2)T behavior as it relates to inbound POTS calls.
For inbound ISDN calls we would add:

voice service pots
  no direct-inward-dial isdn

And for inbound FXO calls we would add:

voice-port 0/0
 secondary dialtone

One nice thing is that when booting an IOS router with this toll-fraud functionality, a message is displayed on boot-up, letting us know about it – essentially warning us that we need to configure something if we wish VoIP calls to work.

A link to Cisco’s tech note describing this new functionality can be found here.

In summary, when upgrading a previously working H.323 or SIP VoIP gateway to IOS 15.1(2)T or later, until the proper configuration changes have been added to allow the proper VoIP source traffic into your voice gateway, all VoIP calls will cease to function properly. In general, this shouldn’t break FXO/CAS/PRI for most configurations out there – as most folks are likely to have their routers configured properly to handle inbound POTS traffic (i.e. PLAR on their FXO ports and DID on their CAS/PRI port – or so we should hope) – I suppose YMMV depending on each unique configuration.

Let me know if you think this is a good thing that Cisco has done.


Related Posts

  • Troubleshooting Voice: MGCP — Part 2
  • 18 Month Plan Released for CCNA-to-CCIE Voice
  • Call Control Discovery via Service Advertisement Framework — Part 3 of 6
  • Call Control Discovery via Service Advertisement Framework — Part 2 of 6
  • New CCNA Voice Course Ready and Newly Revised “CCIE in a Year” Study Plan
  • About Mark Snow, CCIE #14073:

    Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007. Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally. Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.

    Find all posts by Mark Snow, CCIE #14073 | Visit Website

    You can leave a response, or trackback from your own site.

    5 Responses to “Voice Toll-Fraud Caveats – No VoIP Traffic by Default!”

    1. [...] This post was mentioned on Twitter by Internetwork Expert, rodney newsfeeder and rodney newsfeeder, Sherwin Beronio. Sherwin Beronio said: Voice Toll-Fraud Caveats – No VoIP Traffic by Default! http://goo.gl/fb/nzNzC [...]

    2. PETER ESEOSA says:

      Fantastic ! , toll fraud can be a hassle , i experienced it once on a misconfigured asterix box , i am happy cisco is implementing good security measures to prevent this on IOS 15.

    3. Jozef says:

      Any idea how to implement this feature in the 12.4T branch?

      • Yep! It’s called using an ACL!
        No, but seriously, an ACL would be a quick and dirty way – something like:
        ip extended access-list PREVENT_TOLL_FRAUD
        10 permit tcp host (trusted_remote_ip) host (my_rtr_loopback_ip) eq 5060
        20 permit udp host (trusted_remote_ip) host (my_rtr_loopback_ip) eq 5060
        30 permit tcp host (trusted_remote_ip) host (my_rtr_loopback_ip) eq 1720
        40 permit udp host (trusted_remote_ip) host (my_rtr_loopback_ip) eq 1720
        50 deny tcp any host (my_rtr_loopback_ip) eq 5060
        60 deny udp any host (my_rtr_loopback_ip) eq 5060
        70 deny tcp any host (my_rtr_loopback_ip) eq 1720
        80 deny udp any host (my_rtr_loopback_ip) eq 1720
        90 permit ip any any
        ip access-group PREVENT_TOLL_FRAUD in

        This is a quick and dirty ACL that is really meant for concept only (and forgive an mistypes as I just typed it directly in here without any sort of IOS syntax verification).
        You could, of course, combine this with an IOS Zone-Based Firewall to have a much greater depth of security – and in fact this is very much a recommended practice.


    4. SIP Trunking says:

      I agree this is a good move by Cisco. There’s so much potential fraud out there that any extra security is helpful.


    Leave a Reply


    CCIE Bloggers