FTD 6.6.0.1 - SIP Inspection Error - "Via" header incorrectly re-written

[TONY SMITH]

Hi,

I'm not sure if this belongs in the Security, or the UC sections, but here goes.

The scenario is a CUBE gateway on an internal IP address, communication with the ITSP over the Internet via an FTD firewall.  The FTD has a one-to-one NAT so communications to and from the CUBE use that specific external IP address, which is different from the PAT address used for normal Internet access.

To deal with a particular issue the ITSP has asked for SIP inspection to be enabled, which I have done.

The problem is that now interferes with the Via headers on responses sent for incoming calls.  In these responses, for example Trying and Ringing, Via should show the originating IP address, ie the service provider's proxy and that is how the message leaves the CUBE.  For some reason with SIP inspection enabled, the FTD changes that header, replacing the service provider's IP with the FTD's interface IP address.

For outgoing calls Via originally contains the CUBE's IP and that is correctly re-written to the external NAT address.

Any ideas?   It looks like a fault in the inspection, unless there are tuning options available other than just Enabled or Disabled.

Thanks, Tony S

[TONY SMITH]

Any ideas on this?

We did some testing the other day and as I feared that incorrect header is absolutely fatal to the ITSP comms.  They use the Via header as part of the sanity checking for responses received, so seeing an irrelevant IP address there causes the responses to be discarded.

Furthermore I have found it putting incorrect addresses into some SDP headers as well.

Comparison of cases where SDP is correct or incorrect shows that all the errors I've spotted so far consist of the Inspection replacing the service provider IP address with this incorrect address.  So it seems like the behaviour is ...

- Headers originally containing CUBE internal IP, re-write with CUBE NAT address.  This is correct

- Headers originally containing ITSP,  re-write with FTD's interface IP address.  This is incorrect, that address has no place in the conversation at all.

Thanks, Tony S

[Mohammed al Baqari]

Hi,

It seems that you have inspection enabled under the global service-policy
which is causing this issue for you. Unfortunately, when you enable
inspection from FTD CLISH it goes under the global policy. You need to
disable global inspection and enable it on the interface facing the
provider only. Don't enable it on the interface facing the CUBE. This way
responses from providers are not overwritten.

You can do this using flexconfig.

**** please remember to rate useful posts

[TONY SMITH]

Hi,

Thanks for the response.   I'm not quite sure that's the issue though, the responses that are being incorrect re-written are outgoing responses, replies from the customer voice gateway back to the ITSP,  packets received on the inside I/F of the firewall and transmitted on the outside.   To my mind it is correct that these should be inspected.

Looking at my existing debugs and captures, I don't think that packets coming the other way are being affected.  However I only have incoming calls, where the Request comes from the ITSP and Response from the CUBE.

I'll need to do a test outbound call and see where the Responses from ITSP are being similarly re-written.

Thanks, Tony S

[TONY SMITH]

Actually I'm getting confused.  Incoming messages should be inspected, to carry out the reverse re-writing.   I've just tested with an outbound call, and just looking at the 183 Response from the ITSP it is seen on the outside of the firewall with the following IPs ..

SIP - Via and To - customer's voice gateway, external IP address after NAT

SDP - Contact, Session Owner, Connection - ITSP Proxy address

On the inside the packet received by the CUBE has Via and To re-written to show the CUBE's inside IP address.

The headers showing the ITSP proxy address have been left unchanged.

That looks correct, unless I've missed something or misunderstood.

Thanks,

[TONY SMITH]

After an amazingly slow TAC case, it appears that there may be a work around by using a Prefilter Policy, matching traffic between the Internal address of the CUBE gateway and the ITSP, with "Fast Path" action.   I've not yet tested all the scenarios that the SIP inspection broke before, but it is looking hopeful.