Service-engine x/y/z may need to be included in a zone for voice traffic to pass

[sdavids5670]

I ran into an interesting issue today and thought it'd be nice to share since we didn't have much luck finding an answer on The Google.  Here's the gist of the issue.  We have ZBFW features enabled on a 4331.  We have only two zones; INSIDE and INTERNET.  This router also has a combo FXS/FXO module.  Well, a user complained that a machine attached to the FXS port wasn't working.  An analog phone was attached and a test call revealed that there was one-way audio (the caller could hear us but we couldn't hear the caller - audio from the attached phone, via the FXS port, wasn't working).  Upon further testing, we learned that the FXO port was having a one-way audio issue, too.  In a nutshell, if the traffic was received over analog and then converted into IP traffic and transmitted on an INSIDE interface it was dumped.  It turns out that there's a simple fix for this issue.

interface Service-EngineX/Y/Z
 zone-member security YOUR_ZONE_NAME_HERE

[voip7372]

I had this issue and we solved it (partially) the way you did, however, we have more than two zones and we use a ip policy route-map assigned to the interfaces to get the traffic where it needs to go.  However, apparently it's not possible to assign an ip policy route-map to a service-engine so we still have a problem with one-way audio in one of our zones.  If you've ever resolved this issue with 3 or 4 zones in play, I'd appreciate any tips on how you solved it.  I've had a ticket open with Cisco for awhile and so far they're just telling us to make some changes our company doesn't normally allow for various reasons...so for the moment, we're stumped on how to solve this.

[JASON VLAD]

Hey Voip7372.

I have the exact same issue as you with multiple FBFW zones / SIP / FXS and can only get audio one way.

Did you or Cisco ever come up with a fix for this issue by any chance. 

Any insight will be much appreciated.

[JASON VLAD]

Ahh figured it out and here are my 2 cents on this problem. Kind of dumb but now that its been resolved it kind of makes sense. Just like the 1st post there is not a lot of information on these types of setups and to figure out the Service-Engine needing to be part of firewall zones i spent over a week with cisco support and they didnt know either. To this day i personally cannot find a way to view what is being blocked easely with one command.

Fix Based on: CSCuu86175
Place the service engine interface(s) applicable to the voice cards (which will be the "Service-Engine" interfaces with an "Up" state) in a zone that is used by the zone-based firewall and is on the normal path of the voice traffic. Contact Cisco TAC for more details about how to implement this workaround option.

On 4000 series routers anyway the DSP module has its own Service-Engine0/4/0 interface.

But so do the FXS and FXO voice-ports as in my case the FXO is Service-Engine0/2/0 and the FXS is Service-Engine0/3/0.

You can find which one is which in your case with "show int Service-Engine0/3/0" and look in the details at the top of output.

To get it working i had to add my inside security zone to the service-engine interfaces. In my case i added it to the FXO and FXS service-engine interfaces but you may or may not have to depending on your needs.

interface Service-Engine0/2/0
description FXO-Ports--NIM-4FXO
zone-member security Z-INSIDE
!
interface Service-Engine0/3/0
description FXS-Ports--NIM-4FXS
zone-member security Z-INSIDE
!
interface Service-Engine0/4/0
description DSP-Module--PVDM4-64
zone-member security Z-SIPnetwork

!

!

!

voice-port 0/3/0
cptone CA
description FXS Port - Cambridge FAX DN-519xxxxxxx x7253
station-id name Cambridge FAX
station-id number 7253
caller-id enable
!
voice-port 0/3/1
shutdown
!
voice-port 0/3/2
shutdown
!
voice-port 0/3/3
cptone CA
description FXS Port - Cambridge ProxAir DID-519xxxxxxx x7254
station-id name Cambridge ProxAir
station-id number 7254
caller-id enable

Hope its helpfull to whomever is searching.

[Giuseppe Larosa]

Hello @JASON VLAD ,

interesting point few years ago I built a terminal server on aux ( typical CCIE R&S lab)  with a ZBFW and I had to add the aux interface to security zone inside.

I think I posted here in the forum around November 2017.

Hope to help

Giuseppe

[JASON VLAD]

Yeah I learned a lot about ZBFW and how finnicky they can be compared to the previous style FW configurations.
The number of lines required compared to previous FW configuration has gone through the roof but I do see the benefit on how granular you can get now.
My only beef with ZBFW is the class-map and policy-map statement don't seem to stay organized very well and thing are all over the place which may not be a big deal in small deployment but in setups with tones of rules it can be a pain in the ars to track down and troubleshoot especially in configs that were not done by you. Even after coming up with a proper alphanumeric naming convention they still seem to get all mixed up. CMAP1-IN... CMAP1-OUT... CMAP2-IN... CMAP2-OUT. But when all is done the config is all mixed up with CMAP2-IN... CMAP1-OUT... CMAP1-IN... CMAP2-OUT. They just wont stay in the proper order. Wish cisco would fix this a bit as they do with ACL's.
BUT atleast is working now.