01-24-2019 12:31 AM - edited 02-21-2020 08:41 AM
Hi Cisco IOS SMEs,
there have been some prior posts on this subject, but they are very old and relate to much less recent IOS versions:
here: https://community.cisco.com/t5/firewalls/zbfw-quot-sip-protocol-violations-quot/m-p/1251998
I am running IOS 15.5(3)M7 on 2901 ISR Router and am in process of trying to get SIP Trunk configured with CME on the router, but has issue with this and so started to test with SW sip user agent (Blink Pro). My trunk provider is using Cisco Broadworks SIP Server.
As part of testing I have put SIP devices in DMZ with public IP address so as to avoid any potential NAT/SIP complications.
Based on reading other posts relating to getting SIP_PROTOCOL_VIOLATION reports (via log) I have configured the following set of definitions into my configuration:
<<start of snippet>>
class-map type inspect sip match-any SIP-MESSAGE
match protocol-violation
class-map type inspect match-all SIP-FW-PROTOCOL
match protocol sip
policy-map type inspect sip SIP-ACTION
class type inspect sip SIP-MESSAGE
log
allow
policy-map type inspect POLICY-DMZ-OUT
class type inspect SIP-FW-PROTOCOL
inspect
service-policy sip SIP-ACTION
class class-default
drop log
<<end of snippet>
So even when I have configured this I am getting the following result:
004654: Jan 24 08:25:14.844 UTC: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Content length invalid / Non-SIP MSG recvd) - dropping udp session 203.XX.XX.40:62509 45.XX.1XX.232:5060 on zone-pair ZP-DMZ-OUT class SIP-FW-PROTOCOL
My testing has found that the violation occurs during INVITE exchange. REGISTER completes successfully, without any SIP Protocol Violations.
So the documented work around for protocol violations itself does not appear to be working.
Can anyone please advise.
As the response is coming from Cisco Broadwork server, I am very surprised that Cisco IOS FW is not handling traffic ...
Thanks in advance for any suggestions.
John.
01-24-2019 11:19 PM - edited 01-25-2019 03:42 PM
Hi IOS SMEs,
can anyone please confirm expect behaviour of the work around outlined in this bug report, which is consistent with the configuration I posted.
Here is bug link: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtl58680
In the text of link it says:
"This is an enhancement to just drop the packet in these cases and not the entire UDP session and child connections"
My expectation of added the service-policy:
<<-- snippet -->>
class-map type inspect sip match-any allow-violations
match protocol-violation
policy-map type inspect sip allow-violations
class type inspect sip allow-violations
allow
policy-map type inspect self->out
class type inspect self->out
inspect
service-policy sip allow-violations
class class-default
drop log
<<-- snippet -->>
would be to not drop the packet and let it pass through.
Am I wrong in this thinking ?
Thank you.
Regards,
John.
04-07-2020 07:16 AM
We simply removed the "match protocol sip" and let it default to "match protocol udp" for outgoing. There are apparently quite a few problems with inspecting SIP with ZBFW
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide