FPR1150 FTD 6.6.0.1 - SIP Inspection Not Taking Effect on One FTD

[TONY SMITH]

Hi,

We have two FTDs with same hardware and same software, SIP Inspection was enabled on one a few months ago and is having the expected effects, SIP and SIP headers are being re-written to show the translated external address rather than the internal.

Now we've enabled SIP Inspection on the other one, but it isn't coming into effect.  SIP and SDP headers still show the untranslated internal addresses.  Is there something else that needs be done to kick it into action?   On both FTDs SIP Inspect was originally disabled with a Flexconfig object ...

policy-map global_policy
class inspection_default
no inspect sip

And in each case re-enabled with another object 

policy-map global_policy
class inspection_default
inspect sip

Going into to the CLI I can see it there ...

policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect netbios
  inspect tftp
  inspect icmp
  inspect icmp error
  inspect ip-options UM_STATIC_IP_OPTIONS_MAP
  inspect sip

Any ideas where I should look to see why it's not taking effect?

Thanks,  Tony S

[balaji.bandi]

how are you managing this FTD ? if you using FMC, suggest to use flex config to change this?

[TONY SMITH]

Thanks, yes we're using FMC and are using Flexconfig objects/policies to make these changes.  I thought I'd mentioned that in my first post.

[Aref Alsouqi]

Do you see any hits on the service policy for SIP protocol?

Not sure if this would help, but try please to use these commands from CLISH mode on the FTD ">":

configure inspection sip disabled

configure inspection sip enabled

Technically it will do the same as what you have done with FlexConfig, but again not sure if it helps.

[TONY SMITH]

Thanks, I tried those and it made no difference.   How do I check for hits on the policy?   My guess, and it's only a guess, is that either the whole policy isn't applied, or something is in the wrong order somewhere.

Where in the FTD configuration do I see where that global inspect policy is applied?  Or is it by implication applied everywhere?

Thanks, TS

[TONY SMITH]

I think I've found where to see hits, and it is seeing some ...

> show service-policy

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns preset_dns_map, packet 78, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: ftp, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: h323 h225 _default_h323_map, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: h323 ras _default_h323_map, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: rsh, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: rtsp, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: sqlnet, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: skinny , packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: sunrpc, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: xdmcp, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: netbios, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: tftp, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: icmp, packet 10, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: icmp error, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: ip-options UM_STATIC_IP_OPTIONS_MAP, packet 0, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
      Inspect: sip , packet 118, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0

[Marius Gunnerud]

To see the hit counters on the policy-map issue the command show service-policy global_policy

We have had similar issues, but with FTP, where FTP inspection was not working for active FTP sessions (passive FTP worked fine).  If inspect ftp is configured and the issue still is present, then I would suggest opening a TAC case have have a deep-dive into this issue. 

[TONY SMITH]

Customer rebooted the FTD and now SIP inspection is working.  Well it's taking effect in that I can see the SIP headers being re-written as I'd expect.  It's broken inbound calling, but that's a service provider issue in that they're no longer sending PRACK in response to Ringing.  However they're the ones who asked for inspection to be enabled so they may need to do something their end once we have it in place.

Ideally I'd like to be able to enable or disable without rebooting the FTD.

[Marius Gunnerud]

Technically you should be able to enable and disable without needing to do a reboot.  Might have been a process that was hanging for whatever reason and a reboot cleared that process.

[Aref Alsouqi]

Enabling/disabling inspection does not require a reboot. Might be the device is hitting an unknown software bug, I would evaluate applying the latest release 6.6.1.

[TONY SMITH]

Thanks again.  I wonder whether some connection is staying alive and the inspection would only change if the connection ends or times out, and then reestablishes.   Is there a way to clear connections on the FTD, similar to clear xlate on an ASA?   I'm not even sure what the timeout is for UDP and whether it's specifically different for SIP.

[Marius Gunnerud]

I don't think clear xlate would not help in this case.  You might want to try clear conn if the issue happens again.  Just keep in mind that this will kill all connections through the ASA and those connection will need to be re-established.  Alternatively If you know the culprit IP, you can specify that specific IP and not clear all the connections. 

[TONY SMITH]

It looks like "clear conn address x.x.x.x" did the trick, where x.x.x.x was the inside rather than the translated IP address.  This was for disabling SIP inspection because the ITSP's changes, far from fixing the issue we're looking at, actually broke calling altogether.  So I've just removed SIP inspection, done that "clear conn" and reinstated service.

If they want to try again, I'll see whether it also works for enabling SIP inspection.

[Aref Alsouqi]

I don't believe that would be the case, since the inspection should get started straightaway.