SRX

Model: srx345
Family: junos-es
Junos: 21.4R3-S7.9

Standalone chassis (no HA, cluster)

We are working on standing up CoS (or QoS) for our environment due to a soon-to-be provider change where we may no longer be able to rely on a direct SIP connection to our current provider.

Much has been configured already however it is still noticeable that the call quality is not consistent compared to the current VoIP phone setup in our environment where the phones get routed to a direct connection with our VoIP provider via onprem equipment. Our SRX does not touch that traffic. However, that could change soon.

During our research, we have found that the SIP ALG capability that comes enabled by default has potential to cause some issues with the ideal VoIP experience.

My current confusion is in determining whether or not we have successfully disabled SIP ALG.

Based on this, I have disabled SIP ALG (globally?):

https://supportportal.juniper.net/s/article/SRX-Default-status-of-ALGs?language=en_US

... and I can confirm that by seeing this:

user@srx345> show security alg status
ALG Status:
  DNS      : Enabled
  FTP      : Enabled
  H323     : Enabled
  MGCP     : Enabled
  MSRPC    : Disabled
  PPTP     : Enabled
  RSH      : Disabled
  RTSP     : Disabled
  SCCP     : Enabled
  SIP      : Disabled
  SQL      : Disabled
  SUNRPC   : Enabled
  TALK     : Enabled
  TFTP     : Enabled
  IKE-ESP  : Disabled
  TWAMP    : Disabled

However, when running the following, I still see flows that seem to match something related to SIP:

user@srx345> show security flow session application sip
Session ID: 231928270053, Policy name: SIP-TCP/21, Timeout: 1788, Session State: Valid
  In: Y.Y.Y.Y/34748 --> X.X.X.174/5080;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 17453, Bytes: 7959106,
  Out: X.X.X.174/5080 --> X.X.X.173/17514;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 11175, Bytes: 4152672,

We do have source NAT enabled for our SRX because it is essentially our edge node/gateway. The output directly above does not make sense assuming this is saying that it is reporting something that is being inspected by SIG ALG. We do have security policies configured that specifically match for SIP traffic (protocol/ports) and that also match for an application which itself is bound to the SIG ALG. This is what is shown above as the SIP-TCP part of the text "SIP-TCP/21" and we'd like to think that is all that is being reported.

Even though we are permitting this traffic via security policy-and even though the security policy is matching for this application traffic (which includes the SIG ALG)-we were expecting to not see these flows there in that output in lieu of disabling SIP ALG.

Our reasoning is, because the command is "show security flow session application sip", we are assuming this is referring to either a Juniper predefined service or the SIP ALG.

This page here does not really confirm what we are looking to see and so this is causing our confusion right now:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session-application.html

We also found a way to show the default applications pre-loaded with Junos OS which includes an entry for junos-sip. Is this what is being considered when we run that command or how else is Junos OS determining SIP flows here?

The command: show configuration groups junos-defaults applications

Can anyone confirm based on that output there that we do not have ALG SIP enabled? The only other flow that shows up in the output is another similar flow for a different phone we have that we are using for testing having our onprem VoIP phones (not soft phones) go through our SRX to reach our VoIP provider, make calls, etc.

Also, why do we see those flows? How is the SRX able to identify the SIP traffic?

Hello, 

I hope this helps:

++Whether the SIP ALG is enabled or disabled by default depends on the platform and release 

++The SIP ALG can be disabled using configuration mode command "#set security alg disable"

++Based on the output in your SRX345 SIP ALG is disabled

++junos-defaults is the default set of parameters of each well known application protocol (TCP,UDP) + Port that can be called in a security policy.

++Use Operational mode command ">show security alg sip counters" , counters should not increase

++You can create a custom application using just protocol (TCP /UDP) and destination-port 5060 or 5080 that completely bypasses an ALG, for example: 

set applications application CUSTOM_APP protocol tcp
set applications application CUSTOM_APP destination-port 5080

set security policies global policy TEST_POL match application CUSTOM_APP

best regards, 

Emmanuel Solano

Juniper SRX TAC

Model: srx345
Family: junos-es
Junos: 21.4R3-S7.9

Standalone chassis (no HA, cluster)

We are working on standing up CoS (or QoS) for our environment due to a soon-to-be provider change where we may no longer be able to rely on a direct SIP connection to our current provider.

Much has been configured already however it is still noticeable that the call quality is not consistent compared to the current VoIP phone setup in our environment where the phones get routed to a direct connection with our VoIP provider via onprem equipment. Our SRX does not touch that traffic. However, that could change soon.

During our research, we have found that the SIP ALG capability that comes enabled by default has potential to cause some issues with the ideal VoIP experience.

My current confusion is in determining whether or not we have successfully disabled SIP ALG.

Based on this, I have disabled SIP ALG (globally?):

https://supportportal.juniper.net/s/article/SRX-Default-status-of-ALGs?language=en_US

... and I can confirm that by seeing this:

user@srx345> show security alg status
ALG Status:
  DNS      : Enabled
  FTP      : Enabled
  H323     : Enabled
  MGCP     : Enabled
  MSRPC    : Disabled
  PPTP     : Enabled
  RSH      : Disabled
  RTSP     : Disabled
  SCCP     : Enabled
  SIP      : Disabled
  SQL      : Disabled
  SUNRPC   : Enabled
  TALK     : Enabled
  TFTP     : Enabled
  IKE-ESP  : Disabled
  TWAMP    : Disabled

However, when running the following, I still see flows that seem to match something related to SIP:

user@srx345> show security flow session application sip
Session ID: 231928270053, Policy name: SIP-TCP/21, Timeout: 1788, Session State: Valid
  In: Y.Y.Y.Y/34748 --> X.X.X.174/5080;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 17453, Bytes: 7959106,
  Out: X.X.X.174/5080 --> X.X.X.173/17514;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 11175, Bytes: 4152672,

We do have source NAT enabled for our SRX because it is essentially our edge node/gateway. The output directly above does not make sense assuming this is saying that it is reporting something that is being inspected by SIG ALG. We do have security policies configured that specifically match for SIP traffic (protocol/ports) and that also match for an application which itself is bound to the SIG ALG. This is what is shown above as the SIP-TCP part of the text "SIP-TCP/21" and we'd like to think that is all that is being reported.

Even though we are permitting this traffic via security policy-and even though the security policy is matching for this application traffic (which includes the SIG ALG)-we were expecting to not see these flows there in that output in lieu of disabling SIP ALG.

Our reasoning is, because the command is "show security flow session application sip", we are assuming this is referring to either a Juniper predefined service or the SIP ALG.

This page here does not really confirm what we are looking to see and so this is causing our confusion right now:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session-application.html

We also found a way to show the default applications pre-loaded with Junos OS which includes an entry for junos-sip. Is this what is being considered when we run that command or how else is Junos OS determining SIP flows here?

The command: show configuration groups junos-defaults applications

Can anyone confirm based on that output there that we do not have ALG SIP enabled? The only other flow that shows up in the output is another similar flow for a different phone we have that we are using for testing having our onprem VoIP phones (not soft phones) go through our SRX to reach our VoIP provider, make calls, etc.

Also, why do we see those flows? How is the SRX able to identify the SIP traffic?

Hi @Emanuel Solano,

Thank you for your feedback! I forgot to mention that we currently have a custom application that looks almost exactly like your example.

The extra part we added to our application definition is that we also specify alg sip in our definition. The idea originally was that we had no choice but to force SIP traffic through the SIP ALG but we are not trying to do that anymore.

Since we have not changed that in our config, and because we can now say SIP ALG is disabled, what is the affect of the security policy while we do not update our config to remove the alg sip parameter in our application definition?

We are now assuming because we can see those flows for SIP, it looks like it is accepting the traffic as we have configured in our security policy (great!). However, because our SRX security policy also includes a match against our custom application (which as just mentioned includes the alg sip reference), is it possible it will still send the traffic through the SIP ALG?

I am thinking it will not but I just reset the counters, did a test call, and printed the counters again and I am seeing the counters go up.

Is it possible that even though we disabled it globally, if our custom application references SIP ALG, it can still accept matched traffic and inspect it?

If so, is the preferred way to bypass SIP ALG in this scenario to simply remove any reference of it in the application definition?

Hello, 

I hope this helps:

++Whether the SIP ALG is enabled or disabled by default depends on the platform and release 

++The SIP ALG can be disabled using configuration mode command "#set security alg disable"

++Based on the output in your SRX345 SIP ALG is disabled

++junos-defaults is the default set of parameters of each well known application protocol (TCP,UDP) + Port that can be called in a security policy.

++Use Operational mode command ">show security alg sip counters" , counters should not increase

++You can create a custom application using just protocol (TCP /UDP) and destination-port 5060 or 5080 that completely bypasses an ALG, for example: 

set applications application CUSTOM_APP protocol tcp
set applications application CUSTOM_APP destination-port 5080

set security policies global policy TEST_POL match application CUSTOM_APP

best regards, 

Emmanuel Solano

Juniper SRX TAC

Model: srx345
Family: junos-es
Junos: 21.4R3-S7.9

Standalone chassis (no HA, cluster)

We are working on standing up CoS (or QoS) for our environment due to a soon-to-be provider change where we may no longer be able to rely on a direct SIP connection to our current provider.

Much has been configured already however it is still noticeable that the call quality is not consistent compared to the current VoIP phone setup in our environment where the phones get routed to a direct connection with our VoIP provider via onprem equipment. Our SRX does not touch that traffic. However, that could change soon.

During our research, we have found that the SIP ALG capability that comes enabled by default has potential to cause some issues with the ideal VoIP experience.

My current confusion is in determining whether or not we have successfully disabled SIP ALG.

Based on this, I have disabled SIP ALG (globally?):

https://supportportal.juniper.net/s/article/SRX-Default-status-of-ALGs?language=en_US

... and I can confirm that by seeing this:

user@srx345> show security alg status
ALG Status:
  DNS      : Enabled
  FTP      : Enabled
  H323     : Enabled
  MGCP     : Enabled
  MSRPC    : Disabled
  PPTP     : Enabled
  RSH      : Disabled
  RTSP     : Disabled
  SCCP     : Enabled
  SIP      : Disabled
  SQL      : Disabled
  SUNRPC   : Enabled
  TALK     : Enabled
  TFTP     : Enabled
  IKE-ESP  : Disabled
  TWAMP    : Disabled

However, when running the following, I still see flows that seem to match something related to SIP:

user@srx345> show security flow session application sip
Session ID: 231928270053, Policy name: SIP-TCP/21, Timeout: 1788, Session State: Valid
  In: Y.Y.Y.Y/34748 --> X.X.X.174/5080;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 17453, Bytes: 7959106,
  Out: X.X.X.174/5080 --> X.X.X.173/17514;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 11175, Bytes: 4152672,

We do have source NAT enabled for our SRX because it is essentially our edge node/gateway. The output directly above does not make sense assuming this is saying that it is reporting something that is being inspected by SIG ALG. We do have security policies configured that specifically match for SIP traffic (protocol/ports) and that also match for an application which itself is bound to the SIG ALG. This is what is shown above as the SIP-TCP part of the text "SIP-TCP/21" and we'd like to think that is all that is being reported.

Even though we are permitting this traffic via security policy-and even though the security policy is matching for this application traffic (which includes the SIG ALG)-we were expecting to not see these flows there in that output in lieu of disabling SIP ALG.

Our reasoning is, because the command is "show security flow session application sip", we are assuming this is referring to either a Juniper predefined service or the SIP ALG.

This page here does not really confirm what we are looking to see and so this is causing our confusion right now:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session-application.html

We also found a way to show the default applications pre-loaded with Junos OS which includes an entry for junos-sip. Is this what is being considered when we run that command or how else is Junos OS determining SIP flows here?

The command: show configuration groups junos-defaults applications

Can anyone confirm based on that output there that we do not have ALG SIP enabled? The only other flow that shows up in the output is another similar flow for a different phone we have that we are using for testing having our onprem VoIP phones (not soft phones) go through our SRX to reach our VoIP provider, make calls, etc.

Also, why do we see those flows? How is the SRX able to identify the SIP traffic?