SRX

In SRX3600, is it possible to bypass the SIP ALG for specific IPs?  I was planning on setting up packet-mode until I found out that selective packet mode is not supported on the SRX3600.  I don't want to disable SIP ALG altogether.  I'm running 11.2R7 on an SRX3600 cluster.

Hi,

To achieve this you can configure a customer application for SIP and in that application select "application-protocol" as ignore.

Now for the IPs where you want to disable SIP alg configure a policy and put it at the top and use this customer application that you have configured. This will disable SIP alg for matching traffic.

Regards

Sarab

Wow, thanks!  I'll try that and see how it goes.  I won't forget to give kudos, either.

Thanks Evt  🙂

I hope it helps, will wait for your update on this.

Hi,

Unfortunately, this did not work.  Here's my application:

    application SIP-Problems {
        application-protocol ignore;
        protocol udp;
        destination-port 5060;
        inactivity-timeout 3600;
    }

It is called in my policy as the second term, underneath the one that matches all RTP:

            policy 15-bypass_ALG {
                match {
                    source-address sip-problems;
                    destination-address [ host-gen-s3-sipcust host-gen-s3-sipsup ];
                    application SIP-Problems;
                }
                then {
                    permit;
                    count;
                }
            }

I've got the right source/destination addresses and port number, all verified with packet captures.  When we initiate a call to the problem SIP trunk, the counters on the policy never increment and the call fails.  For the heck of it, I also put a matching policy in the outbound direction, but that didn't help, either.  Once I disable the SIP ALG, calls begin working.  Am I doing something wrong here?

Now since counter didnt increment policy that means traffic didnt hit our new policy.

Two possibilities here :

1. Already existing session which you need to clear first.

2. The new policy is not before the any other policy which the traffic is taking. So you need to move this new policy to top of policy stack.

It might be that there's an existing session - I didn't think to check that.  There's only one policy match above this and it defines a completely different destination address:

policy 10-allow_rtp {
    match {
        source-address [ customer-ips ];
        destination-address host-gen-s3-media;
        application voip-rtp;
    }
    then {
        permit;
    }
}

I think it was the existing session.  After re-enabling the ALG and clearing the session ID, the traffic is now hitting the 'ignore' policy, as well as getting established within the right policy:

Session ID: 140337198, Policy name: 15-bypass_ALG/18, State: Active, Timeout: 3588, Valid
  In: x.x.x.58/52065 --> x.x.x.51/5060;udp, If: ge-13/0/11.1, Pkts: 3, Bytes: 1435
  Out: x.x.x.51/5060 --> x.x.x.58/52065;udp, If: reth0.0, Pkts: 0, Bytes: 0
Total sessions: 1

We'll test with our customer later this morning.  Thanks!

That's exactly what it was - the session needed to be cleared.

Thanks!