cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1012
Views
0
Helpful
9
Replies

Presence not working correctly with SIP inspection

Hello Community,

I would like to bring up a problem that I'm having...

Clients connecting via IPsec VPN and using Personal Communicator.

CUCP 7/ASA 8.2

Clients can connect via VPN, log in to the Personal Communicator and make calls (the chat is not working because all collegues appear offline).

If disabling SIP inspection in the ASA, then the chat works.

Problem is we need SIP inspection enabled.

The Presence server resides behind the ASA and it works fine locally.

Problem is only via VPN due to SIP inspection, how to fix it?


Thank you all!

Federico.

9 Replies 9

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Federico,

I'm not sure if you got an answer to this already in any other way.

First of all SIP inspection like any other inspection is used to open up dynamically connection and pre-create xlates and a little bit of voo-doo when NAT is involved.

When using VPN connections by default should be permitted and usually we don't do NAT - so you should not normally need sip inspection for VPN flows.

That being said I agree that it looks like a problem with interoperability, I'm not aware of any problem with this - nor do I have access to check right now if this is known or not.

Let me know if someone already looked into this, if not I'll have a check tomorrow.

Marcin

Marcin,


There's no NAT for the presence server through the tunnel, but the client will requiere static NAT for public access later on... so SIP inspection will be needed eventually.

Right now... I turned off SIP inspection and the chat works fine through VPN.

If I enable SIP inspection the chat won't work.

What I would like here is to be able to allow the chat to work with SIP inspection enabled.

I'm still having the problem so I would definitely appreciate your help with this one

Thank you!

Federico.

Sure thing Federico, I'll dig in tomorrow ;-)

Federico,

No spectacular finding on my side.

One would be this:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtc62281

I also remember having something similar to this in the past. But I'd need to dig into presence protocol, I believe CUCM had two possible options for presence (transport? not sure what CUCM phrasing on this was), can you check that for me?

Marcin

Marcin,

All I know at this moment is that with SIP inspection enabled the chat won't work... so what I'll do is run some tests and check what messages do I get to see if we can identify the problem.

I will post the findinds and what you're asking too... thank you :-)

Federico.

Federico,

TAC would typically request, ingress and egress captures + syslogs to get started (SIP debugs too ;-))

If you can get that I'll have a look.

Marcin

Marcin,

I'm including the logs and debug SIP for a connection from a VPN user dporras.

The behavior is the same... with SIP inspection enabled the chat won't work for personal communicator.

I don't see SIP drops in ''sh service-policy'... I'm not sure if I should see packet drops...

If you can take a look at the attachment I'll appreciate it :-)

Federico.

Federico,

I remembered there was something exchanged via different connection then SIP:

Nov 30 2010 10:32:29: %ASA-6-302013: Built inbound TCP connection 1357720 for SHDSL:172.16.13.11/53599 (172.16.13.11/53599) to inside:172.16.10.249/443 (172.16.10.249/443) (dporras)
Nov 30 2010 10:32:30: %ASA-6-302014: Teardown TCP connection 1357720 for SHDSL:172.16.13.11/53599 to inside:172.16.10.249/443 duration 0:00:00 bytes 2889 TCP FINs (dporras)

Regarding what SIP inspection might be up to.


I see for example:

SIP::Found Event header field with presence package
Created SIP session for SHDSL:172.16.13.11/53607 to inside:172.16.10.249/5060, 18 total
        From: sip:dporras@fusionetcorp.local (30);tag=c917b560 (8)
        To: sip:dporras@fusionetcorp.local (30)
        Call-ID: 5a16f7020c59da0aNDdlOGM5MjAyMGRmZmFmZmIzYjA0MWQ2OTQ4OWQxNjM. (60)
Created SIP Transaction for SHDSL:172.16.13.11/53607 to inside:172.16.10.249/5060
        Call-ID: 5a16f7020c59da0aNDdlOGM5MjAyMGRmZmFmZmIzYjA0MWQ2OTQ4OWQxNjM. (60)
        CSeq: 1 PUBLISH
        Branch: z9hG4bK-d87543-3c4409660751743c-1--d87543-
>>>> SIP::Payload not modified

SIP::Found valid SIP URI: sip:dporras@172.16.13.11:50021
SIP::Found Contact sip:dporras@172.16.13.11:50021
SIP::Found Content-length 0
SIP::Found Event header field with presence package
Created SIP Transaction for SHDSL:172.16.13.11/53607 to inside:172.16.10.249/5060
        Call-ID: 5a16f7020c59da0aNDdlOGM5MjAyMGRmZmFmZmIzYjA0MWQ2OTQ4OWQxNjM. (60)
        CSeq: 2 PUBLISH
        Branch: z9hG4bK-d87543-80599b0c83043903-1--d87543-
>>>> SIP::Payload not modified

I don't see any obvious notion of ASA doing something wrong I don't think the packets are being dropped I suspect they are somehow mangled so the manager doesn't recognize them correctly.

I think we'd need more in depth investigation. Traffic capture before and after firewall, with and without SIP inspection + debugs would be a good place to start - but it's not something to be dragged in forum.

Can you open a TAC case? We'll have a look at this one.

Marcin

Marcin,

It was a bug in the ASA code.

Originally I mentioned version 8.2, but the ASA was running 8.0(4) my mistake :-(

I upgraded the ASA to 8.2(2) and now the chat function works perfectly for Personal Communicator through the VPN (with SIP inspection enabled).

Thank you very much.

Federico.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: