SRX Services Gateway
Showing results for 
Search instead for 
Do you mean 
Reply
Contributor
Posts: 62
Registered: ‎07-08-2010
0
Accepted Solution

SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi there,

 

We have an Avaya Communication Manager (dmz vlan) with ip phone (voice vlan). It's ok for internal calls.

 

We'd like to make externals calls to our SIP provider through our SRX but i have no idea how to configure it.  I've seen that ALG SIP is activate per default and that we don't need to do something else, is that correct?

 

My SRX has 3 activated ports: one for the wan, one for the lan and the last for dmz. Vlans from the LAN can go to the internet and the DMZ. The servers from DMZ can go to the internet. I create a destination nat from the IP public (dedicated for voice,sip...) to the AVAYA. 

 

If someone could give me some steps to do, i will appreciate it.

 

 

nat {
    source {
        rule-set trust-to-untrust {
            from zone trust;
            to zone untrust;
            rule source-nat-rule {
                match {
                    source-address 10.0.0.0/24;
                }
                then {
                    source-nat {
                        interface;
                    }
                }
            }
        }
        rule-set trust-to-dmz_ {
            from zone trust;
            to zone dmz;
            rule source-nat-dmz-rule {
                match {
                    source-address 10.0.0.0/24;
                }
                then {
                    source-nat {
                        interface;
                    }
                }
            }
        }
        rule-set dmz-untrust {
            from zone dmz;
            to zone untrust;
            rule source-dmz-rule {
                match {
                    source-address 10.0.1.0/24;
                }
                then {
                    source-nat {
                        interface;
                    }
                }
            }
        }
    }

    destination {
        pool server-avaya {
            address 10.0.1.1/32;
        }
        rule-set nat-avaya-sip {
            from interface fe-0/0/2.0;
            rule single-adr-nat {
                match {
                    destination-address 86.155.123.1/32;
                }
                then {
                    destination-nat pool server-avaya;
                }
            }
        }
    }
    proxy-arp {
        interface fe-0/0/2.0 {
            address {
                86.155.123.1/32;
            }
        }
    }
}

screen {
    ids-option untrust-screen {
        icmp {
            ping-death;
        }
        ip {
            source-route-option;
            tear-drop;
        }
        tcp {
            syn-flood {
                alarm-threshold 1024;
                attack-threshold 200;
                source-threshold 1024;
                destination-threshold 2048;
                timeout 20;
            }
            land;
        }
    }
}

zones {
    security-zone trust {
        address-book {
            address trust_int 10.0.0.0/24;
        }
        host-inbound-traffic {
            system-services {
                all;
            }
            protocols {
                all;
            }
        }
        interfaces {
            fe-0/0/3.0;
        }
    }
    security-zone untrust {
        screen untrust-screen;
        interfaces {
            fe-0/0/2.0 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
     security-zone dmz {
        address-book {
            address dmz_int 10.0.1.0/24;
        }
        inactive: screen untrust-screen;
        interfaces {
            fe-0/0/4.0 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
}

policies {
    from-zone trust to-zone untrust {
        policy trust-to-untrust {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    }
    from-zone trust to-zone dmzr {
        policy trust-to-dmz {
            match {
                source-address any;
                destination-address dmz_int;
                application any;
            }
            then {
                permit;
            }
        }
    }
    from-zone dmz to-zone untrust {
        policy dmz-to-untrust {
            match {
                source-address dmz_int;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    }
}

 

 

 

Trusted Expert Trusted Expert
Trusted Expert
Posts: 791
Registered: ‎07-26-2008
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

It depends on how the traffic from your internal needs to take to reach the external SIP server. If the only communication is from the Avaya Communication manager to the external SIP server, then you can just use static nat together with the SIP ALG and that should work.

 

Dest nat should also work.

 

But if it does not then you need to check traceoptions to see what traffic is either getting denied or not getting natted properly.

 

Here is a link for traceoptions in case you need to troubleshoot it:

http://forums.juniper.net/t5/SRX-Services-Gateway/Troubleshooting-flow-SRX/m-p/9210/highlight/true#M...

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi,

 

Just to be sure. I read the configuration below:

 

static {
    rule-set nat-example {
        from interface ge-0/0/0.0;
        rule nat-trust-net {
            match {
                destination-address 200.0.0.0/26;
            }
            then {
                static-nat prefx 10.1.1.0/26;
            }
        }
    }
}
proxy-arp {
    interface ge-0/0/0.0 {
        address {
            200.0.0.1/32 to 200.0.0.62/32;
        }
    }
}

The destination addresss would be my IP public and the static-nat prefix would be my avaya private IP? If so, i will never notify the SIP provider IP?

 

 

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

I'm trying with dest Nat.

 

 

destination {
pool server-avaya {
    address local.12.1/32;
}
pool server-ftp {
    address local.12.15/32 port 21;
}
rule-set nat-avaya-sip {
    from interface fe-0/0/2.0;
    rule single-adr-nat {
        match {
            destination-address public.143.1/32;
        }
        then {
            destination-nat pool server-avaya;
        }
    }
    rule portNatFtp {
        match {
            destination-address public.143.3/32;
            destination-port 21;
        }
        then {
            destination-nat pool server-ftp;
        }
    }
}
}


proxy-arp
interface fe-0/0/2.0 {
    address {
        public.143.1/32;
    }
}

 I ping the public.143.1 from outside. If the connexion between my Avaya and the SIP provder, i should see something from show security alg sip * right ?

 

at the moment, i have something for sip counters:

 

Method              T            1xx            2xx            3xx            4xx            5xx            6xx
                      RT             RT             RT             RT             RT             RT             RT

   INVITE             18             18              0              0              0             18              0
                       0              0              0              0              0              0              0
   CANCEL              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
      ACK             18              0              0              0              0              0              0
                       0              0              0              0              0              0              0
      BYE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
 REGISTER            268              0              0              0              0              0              0
                    1736              0              0              0              0              0              0
  OPTIONS              2              0              0              0              2              0              0

 

Trace:

 

security flow
traceoptions {
    file flow-avaya-sip;
    flag all;
    packet-filter avaya {
        source-prefix local.12.1/32;
    }
}


 

The result of show log flow-avaya-sip | match "local.12.1" is attached. Maybe i'm wrong but the server avaya (ip local.12.1) send packet to 0.0.0.0 ??

 

 

Nota: avaya is on fe-0/0/4 (dmz) and fe-0/0/3 is my lans

Trusted Expert Trusted Expert
Trusted Expert
Posts: 791
Registered: ‎07-26-2008
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Can you try to run just "set security flow traceoptions flag basic-datapath"?

 

The sip counters are for ALG traffic, so ping will probably not get caught by those counters. From the flow trace I see some traffic going but can you take another snapshot with above setting instead of all?

 

 

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Here is the new log. I made some calls (ip phone local.10.21) from and to outside. I have more info from sip counters:

 

 

Method              T            1xx            2xx            3xx            4xx            5xx            6xx
                      RT             RT             RT             RT             RT             RT             RT

   INVITE             36             36              0              0              0             36              0
                       0              0              0              0              0              0              0
   CANCEL              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
      ACK             36              0              0              0              0              0              0
                       0              0              0              0              0              0              0
      BYE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
 REGISTER            319              0              0              0              0              0              0
                    2044              0              0              0              0              0              0
  OPTIONS              3              0              0              0              3              0              0
                       0              0              0              0              0              0              0
     INFO              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  MESSAGE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
   NOTIFY              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
    PRACK              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  PUBLISH              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
    REFER              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
SUBSCRIBE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
   UPDATE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
 BENOTIFY              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  SERVICE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
    OTHER              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0

SIP Error Counters:
  Total Pkt-in                  : 2513
  Total Pkt dropped on error    : 0
  Transaction error             : 0
  Call error                    : 0
  IP resolve error              : 0
  NAT error                     : 0
  Resource manager error        : 0
  RR header exceeded max        : 0
  Contact header exceeded max   : 0
  Call Dropped due to limit     : 0
  SIP stack error               : 0
  SIP decode error              : 0
  SIP unknown method error      : 0
  RTO message sent              : 0
  RTO message received          : 0
  RTO buffer allocation failure : 0
  RTO buffer transmit failure   : 0
  RTO send processing error     : 0
  RTO receive processing error  : 0
  RTO receive invalid length    : 0

 

How could we get SIP packets? something like numberPhone@SIPProvider and so

 

Trusted Expert Trusted Expert
Trusted Expert
Posts: 791
Registered: ‎07-26-2008
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Ah I think in that case you can try to run SIP ALG debug:

set security alg sip traceoptions flag call (for eg)

set security flow traceoptions flag basic datapath

set security flow traceoptions file sip-trace

set security flow traceoptions packet-filter 1 destination-prefix <IP Addr>

 

But one thing is that sip traces may be high so I would suggest you also configure packet filter for specific IP and turn off traces once data has been collected.

 

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Highlighted
Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Here is my config:

 

 

interfaces{
fe-0/0/2 {
    unit 0 {
        family inet {
            address publicIP.143.3/29;
        }
    }
}
}

nat{
destination {
    pool server-avaya {
        address local.12.1/32;
    }
    pool server-ftp {
        address local.12.15/32 port 21;
    }
    rule-set nat-avaya-sip {
        from interface fe-0/0/2.0;
        rule single-adr-nat {
            match {
                destination-address publicIP.143.1/32;
            }
            then {
                destination-nat pool server-avaya;
            }
        }
        rule portNatFtp {
            match {
                destination-address publicIP.143.3/32;
                destination-port 21;
            }
            then {
                destination-nat pool server-ftp;
            }
        }
  

proxy-arp {
    interface fe-0/0/2.0 {
        address {
            publicIP.143.1/32;
        }
    }
}
}
}

 

 

I set up the traceoptions:

 

>set security alg sip traceoptions flag call

security flow traceoptions {
    file sip-trace;
    flag basic-datapath;
    packet-filter avaya {
        source-prefix local.12.1/32;
    }
    packet-filter provider {
        destination-prefix providerSIP.247.103/32;
    }
}

 

 

I saw some interesting parts:

 

Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip: ------------------sip vector entry -----------------
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg..... packet received (local.12.1 -> providerSIP.247.103) len=1481
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg..... udp packet received (5060 -> 5060) len=1453, cksum=0x43b1
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg/call INCOMING call dlg0x457c8aa4
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg/call Dialog dlg0x457c8aa4 sending provisional 100 ((null))
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:SPU invalid session id 084b7144
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:SPU invalid session id 084b7144
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg/call ALG action 4
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg/call peer transaction tsx0x457c65c4 created
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg/call Dialog dlg0x457c69cc CALLING
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip_alg..... packet sent (local.12.1 -> providerSIP.247.103) len=1417
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:sip: sip alg vector finish successfully ret = 0
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:flow_alg_vector: status -1
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT:  packet dropped, sm application error
Aug  4 13:04:51 13:04:50.1138505:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

 

My avaya send to  providerSIP.247.103 but i'm not sure if my local.12.1 has been natted to publicIP.143.1?

Cause the provider might only receive something from publicIP.143.1

 

and

 

Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip: ------------------sip vector entry -----------------
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet received (providerSIP.247.103 -> publicIP.143.3) len=365
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... udp packet received (5060 -> 18138) len=337, cksum=0x5854
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c69cc received provisional 100 ((null))
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call ALG action 2
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c8aa4 sending provisional 100 ((null))
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet sent (providerSIP.247.103 -> publicIP.143.3) len=472
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:sip: sip alg vector finish successfully ret = 0
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:flow_alg_vector: status -1
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:  packet dropped, sm application error
Aug  4 13:04:51 13:04:50.1161249:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

 

The providerSIP send packet to publicIP.143.3 instead of publicIP.143.1. Mistake from my provider config?

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

it still does bip bip when calling but i have something :

 

 

>show security alg sip calls
Total number of calls: 2
Call leg 1 Zone : 7
  UAS call ID: 25814688-3489911144-575581@provider.com (pending transactions 1)
  Remote tag : 3489911144-575588
  State      : STATE_PROCEEDING
Call leg 2 Zone : 8
  UAC call ID: 25814688-3489911144-575581@provider.com (pending transactions 1)
  Local tag  : 3489911144-575588
  State      : STATE_PROCEEDING
Call leg 1 Zone : 8
  UAS call ID: 25814688-3489911144-575581@provider.com (pending transactions 1)
  Remote tag : 3489911144-575588
  State      : STATE_PROCEEDING
Call leg 2 Zone : 2
  UAC call ID: 25814688-3489911144-575581@provider.com (pending transactions 1)
  Local tag  : 3489911144-575588
  State      : STATE_CALLING

 

When i try to call from outside to inside:

 

>show security alg sip transaction
Total number of transactions: 3
Transaction Name       Method    CSeq       State         Timeout    VIA RSC ID
UAS:tsx0x457c4cfc      INVITE    1          Proceeding         -1    0
UAC:tsx0x457c1b5c      INVITE    1          Calling             1    1227
UAS:tsx0x457c69cc      INVITE    1          Proceeding         -1    0
UAC:tsx0x457c2c24      INVITE    1          Proceeding         -1    1208
UAS:tsx0x457c8eac      INVITE    1          Proceeding         -1    0
UAC:tsx0x457c134c      INVITE    1          Calling             4    1220

 

When i try from inside to outside(mob phone):

 

>show security alg sip transaction
Total number of transactions: 1
Transaction Name       Method    CSeq       State         Timeout    VIA RSC ID
UAS:tsx0x457c1754      INVITE    1          Confirmed           0    0
UAC:tsx0x457c8aa4      INVITE    1          Completed          32    1218

 

 

 

 

 

 

 

 

 

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

HI,

 

Calls froms IN to OUT works now, the call went to the provider with a wrong public IP as my public ip adddress for surfing is the publicIP.143.3 and my avayaPublicIp is publicIP.143.1. The provider might drop all packets except publicIP.143.1 

 

So i had to create a source nat and dest nat.

 

Now: from OUT to IN doesn't seem to work. I did some test.

 

-------- IN to OUT ------------

>show security alg sip calls (in to out),  => in pending
Total number of calls: 1
Call leg 1 Zone : 8
  UAS call ID: 0161c1597b3df1c6104c7a8d3b00 (pending transactions 1)
  Local tag  : 3489926430-565273
  Remote tag : 0161c1597b3df1c5104c7a8d3b00
  State      : STATE_PROCEEDING
Call leg 2 Zone : 7
  UAC call ID: 0161c1597b3df1c6104c7a8d3b00 (pending transactions 1)
  Local tag  : 0161c1597b3df1c5104c7a8d3b00
  Remote tag : 3489926430-565273
  State      : STATE_PROCEEDING

>run show security alg sip transaction (in to out) => in pending
Total number of transactions: 1
Transaction Name       Method    CSeq       State         Timeout    VIA RSC ID
UAS:tsx0x457c8aa4      INVITE    1          Proceeding         -1    0
UAC:tsx0x457c69cc      INVITE    1          Proceeding         -1    1206

>show security alg sip calls (in to out) when established
Total number of calls: 1
Call leg 1 Zone : 8
  UAS call ID: 0161c1597b3df1c6104c7a8d3b00 (pending transactions 0)
  Local tag  : 3489926430-565273
  Remote tag : 0161c1597b3df1c5104c7a8d3b00
  State      : STATE_ESTABLISHED
Call leg 2 Zone : 7
  UAC call ID: 0161c1597b3df1c6104c7a8d3b00 (pending transactions 0)
  Local tag  : 0161c1597b3df1c5104c7a8d3b00
  Remote tag : 3489926430-565273
  State      : STATE_ESTABLISHED

>run show security alg sip transaction (in to out) when established
Total number of transactions: 0

-------- OUT to IN ------------

>run show security alg sip transaction, => in pending
Total number of transactions: 1
Transaction Name       Method    CSeq       State         Timeout    VIA RSC ID
UAS:tsx0x457c65c4      INVITE    1          Proceeding         -1    0
UAC:tsx0x457c8eac      INVITE    1          Proceeding         -1    1211


>run show security alg sip calls, in pending
Total number of calls: 1
Call leg 1 Zone : 7
  UAS call ID: 26070558-3489926805-7250@provider.com (pending transactions 1)
  Remote tag : 3489926805-7256
  State      : STATE_PROCEEDING
Call leg 2 Zone : 8
  UAC call ID: 26070558-3489926805-7250@provider.com (pending transactions 1)
  Local tag  : 3489926805-7256
  State      : STATE_PROCEEDING

 

 

here is my nat config:

 

source {
    pool publicAvayaIP {
        address {
            publicIP.143.1/32;
        }
    }
    rule-set trust-to-untrust {
        from zone trust;
        to zone untrust;
        rule source-nat-rule {
            match {
                source-address local.0.0/16;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
    rule-set dmz-untrust {
        from zone dmz;
        to zone untrust;
        rule avayaToprovider {
            match {
                source-address local.12.1/32;
            }
            then {
                source-nat {
                    pool {
                        publicAvayaIP;
                    }
                }
            }
        }
        rule source-dmz-rule {
            match {
                source-address local.12.0/24;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
}
destination {
    pool server-avaya {
        address local.12.1/32;
    }
    pool server-ftp {
        address local.12.15/32 port 21;
    }
    rule-set nat-avaya-sip {
        from interface fe-0/0/2.0;
        rule single-adr-nat {
            match {
                destination-address publicIP.143.1/32;
            }
            then {
                destination-nat pool server-avaya;
            }
        }
        rule portNatFtp {
            match {
                destination-address publicIP.143.3/32;
                destination-port 21;
            }
            then {
                destination-nat pool server-ftp;
            }
        }
    }
}
proxy-arp {
    interface fe-0/0/2.0 {
        address {
            publicIP.143.1/32;
        }
    }
}

 

 

When trying to make a call to inside:

 

 

>show log trace-sip | match "provider.247.103"
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:<provider.247.103/5060->publicIP.143.1/5060;17> matched filter provider:
Aug  4 19:17:25 19:17:25.401039:CID-0:RT: find flow: table 0x4d6bc358, hash 51735(0xffff), sa provider.247.103, da publicIP.143.1, sp 5060, dp 5060, proto 17, tok 448
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip provider.247.103, x_dst_ip local.12.1, in ifp fe-0/0/2.0, out ifp N/A sp 5060, dp 5060, ip_proto 17, tos 0
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:flow_first_src_xlate: provider.247.103/5060 -> publicIP.143.1/5060 | local.12.1/5060 -> 0.0.0.0/5060: nat_src_xlated: False, nat_src_xlate_failed: False
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:  dip id = 0/0, provider.247.103/5060->provider.247.103/5060
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:  route lookup: dest-ip provider.247.103 orig ifp fe-0/0/2.0 output_ifp fe-0/0/2.0 orig-zone 7 out-zone 7 vsd 0
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:sip_alg..... packet received (provider.247.103 -> publicIP.143.1) len=1153
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:sip_alg..... packet sent (provider.247.103 -> publicIP.143.1) len=1153
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:<provider.247.103/5060->publicIP.143.1/5060;17> matched filter provider:
Aug  4 19:17:25 19:17:25.401039:CID-0:RT:  post addr xlation: provider.247.103->local.12.1.
Aug  4 19:17:25 19:17:25.410401:CID-0:RT:<local.12.1/5060->provider.247.103/5060;17> matched filter avaya:
Aug  4 19:17:25 19:17:25.410401:CID-0:RT: find flow: table 0x4d6bc358, hash 35692(0xffff), sa local.12.1, da provider.247.103, sp 5060, dp 5060, proto 17, tok 512
Aug  4 19:17:25 19:17:25.410401:CID-0:RT:sip_alg..... packet received (local.12.1 -> provider.247.103) len=426
Aug  4 19:17:25 19:17:25.410401:CID-0:RT:sip_alg..... packet sent (local.12.1 -> provider.247.103) len=426
Aug  4 19:17:25 19:17:25.410401:CID-0:RT:<local.12.1/5060->provider.247.103/5060;17> matched filter avaya:
Aug  4 19:17:25 19:17:25.410401:CID-0:RT:  post addr xlation: publicIP.143.1->provider.247.103.
Aug  4 19:17:48 19:17:48.923898:CID-0:RT:<provider.247.103/5060->publicIP.143.1/5060;17> matched filter provider:
Aug  4 19:17:48 19:17:48.923898:CID-0:RT: find flow: table 0x4d6bc358, hash 51735(0xffff), sa provider.247.103, da publicIP.143.1, sp 5060, dp 5060, proto 17, tok 448
Aug  4 19:17:48 19:17:48.923898:CID-0:RT:sip_alg..... packet received (provider.247.103 -> publicIP.143.1) len=559
Aug  4 19:17:49 19:17:48.923898:CID-0:RT:sip_alg..... packet sent (provider.247.103 -> publicIP.143.1) len=559
Aug  4 19:17:49 19:17:48.923898:CID-0:RT:<provider.247.103/5060->publicIP.143.1/5060;17> matched filter provider:
Aug  4 19:17:49 19:17:48.923898:CID-0:RT:  post addr xlation: provider.247.103->local.12.1.
Aug  4 19:17:49 19:17:48.929501:CID-0:RT:<local.12.1/5060->provider.247.103/5060;17> matched filter avaya:
Aug  4 19:17:49 19:17:48.929501:CID-0:RT: find flow: table 0x4d6bc358, hash 35692(0xffff), sa local.12.1, da provider.247.103, sp 5060, dp 5060, proto 17, tok 512
Aug  4 19:17:49 19:17:48.929501:CID-0:RT:sip_alg..... packet received (local.12.1 -> provider.247.103) len=472
Aug  4 19:17:49 19:17:48.929501:CID-0:RT:sip_alg..... packet sent (local.12.1 -> provider.247.103) len=472
Aug  4 19:17:49 19:17:48.929501:CID-0:RT:<local.12.1/5060->provider.247.103/5060;17> matched filter avaya:
Aug  4 19:17:49 19:17:48.929501:CID-0:RT:  post addr xlation: publicIP.143.1->provider.247.103.

 

I guess it's okay for the nat :  provider.247.103 => publicIP.143.1 => local.12.1

 

 

Don't know if needed but I created a policy to allow from untrust to dmz

Trusted Expert Trusted Expert
Trusted Expert
Posts: 791
Registered: ‎07-26-2008
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Looking at the trace, it seems like we are seeing some application drop errors for SIP when traffic is coming from the provider to the SRX:

 

Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:<providerSIP.247.103/5060->publicIP.143.3/18138;17> matched filter provider:
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:packet [365] ipid = 0, @423f7c9e
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423f7b00, rtbl_idx = 20416
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow process pak fast ifl 69 in_ifp fe-0/0/2.0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: find flow: table 0x4d6bc358, hash 45133(0xffff), sa providerSIP.247.103, da publicIP.143.3, sp 5060, dp 18138, proto 17, tok 448
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_create_session
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:RM populated xlate info for nsp2: local.12.1/5060->providerSIP.247.103/5060out_ifp = fe-0/0/4.0, out_tunnel = 0x0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_in_dst_nat: in <fe-0/0/2.0>, out <fe-0/0/4.0> dst_adr publicIP.143.3, sp 5060, dp 18138
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_in_dst_nat: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_rule_dst_xlate: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_routing: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_policy_search: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_reverse_mip: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_src_xlate: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_get_out_ifp: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:is_loop_pak: No loop: on ifp: fe-0/0/4.0, addr: local.12.1, rtt_idx:0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:policy is NULL (wx/pim scenario)
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 0, policy 10, app_svc_en 0, flags 0x2. not interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 1, policy 10, app_svc_en 0, flags 0x2. not interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 2, policy 10, app_svc_en 0, flags 0x2. interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_do_sm_interest_check: natp 0x4ce178d0, app_id 63, ALG & SZ vectors set, SZ 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: service lookup identified service 63.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_final_check: in <fe-0/0/2.0>, out <fe-0/0/4.0>
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_first_final_check: flow_set_xlate_vector.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: existing vector list 1080-446c8ae8.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: Session (id:52264) created for first pak 1080
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_install_session======> 0x4ce178d0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: nsp 0x4ce178d0, nsp2 0x4ce1793c
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: make_nsp_ready_no_resolve()
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: route lookup: dest-ip providerSIP.247.103 orig ifp fe-0/0/2.0 output_ifp fe-0/0/2.0 orig-zone 7 out-zone 7 vsd 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: route to publicIP.143.6
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:Installing c2s NP session wing
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:Installing s2c NP session wing
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_notify_session_creation: app_id 2, flags 0x0, ifl_in 69, zone_in 7, ifl_out 71, zone_out 8
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow got session.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow fast tcp/udp session id 52264
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_alg_vector(): VECTOR: pak_ptr(0x3fdedc70.0x423f7b00): natp(0x4ce178d0).nsp(0x4ce178d0): app_id: 63, flag: 0x00000003.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip:
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip: ------------------sip vector entry -----------------
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet received (providerSIP.247.103 -> publicIP.143.3) len=365
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... udp packet received (5060 -> 18138) len=337, cksum=0x5854
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c69cc received provisional 100 ((null))
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call ALG action 2
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c8aa4 sending provisional 100 ((null))
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet sent (providerSIP.247.103 -> publicIP.143.3) len=472
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip: sip alg vector finish successfully ret = 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_alg_vector: status -1
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: packet dropped, sm application error

 

But I also see some H323 packets seeing TTL expired error. I thought you are using SIP?

 

Aug  4 13:04:51 13:04:50.1177290:CID-0:RT:<local.10.21/3152->local.12.1/1720;6> matched filter avaya:
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:packet [40] ipid = 1743, @423e861e
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423e8480, rtbl_idx = 20416
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow process pak fast ifl 70 in_ifp fe-0/0/3.0
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: fe-0/0/3.0:local.10.21/3152->local.12.1/1720, tcp, flag 10
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: find flow: table 0x4d6bc358, hash 23999(0xffff), sa local.10.21, da local.12.1, sp 3152, dp 1720, proto 6, tok 384
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow got session.
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow session id 51516
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:flow_asp_vector tcp_proxy_inbound_handler, returned the packet m 0x423e8480, 13.
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc 5)
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: encap vector
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: no more encapping needed
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: **** pak processing end.
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT:flow_first_complete_session: Sending icmp for ttl expiry
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: packet dropped, ttl expiry
****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

You right, we use H323 in the LAN but SIP for outside.

 

What cause the application errors SIP? How could we see from the SRX some SIP packets such as its format:

 

 

Sample SIP INVITE Message from a SIP Service Provider to the Avaya SES: 
 
INVITE sip:6023334000@150.100.100.130 SIP/2.0 
Via:SIP/2.0/UDP 20.1.1.54;branch=z9hG4bK-xyz.20.1.1.54-V5060-0-951040837 
From:<sip:7336731730@20.1.1.54;user=phone>;tag=26074514-1178723120777- 
To:"ABC Corp"<sip:6023334000@150.100.100.130> 
Call-ID:BW110520777090507561442054@20.1.1.54 
CSeq:951040837 INVITE 
Contact:<sip:20.1.1.54:5060> 
Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY 
Supported:100rel 
Accept:multipart/mixed,application/sdp 
Max-Forwards:10 
Content-Type:application/sdp 
Content-Length:285 
 
v=0 
o=xyz 57542641 1 IN IP4 20.211.120.15 
s=- 
c=IN IP4 20.211.120.15 
t=0 0 
m=audio 17040 RTP/AVP 18 0 8 101 
c=IN IP4 20.211.120.15 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=no 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-16

 

 

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi guys,

 

I figured out why the inbound didn't work.

 

I had a src nat(for outbound) and dest nat(inbound) with the publicIpAvaya.143.1 . I use the publicIP.143.3 for surfing which is affected to my fe-0/0/2.0.

 

When inbound call, i found via show log sip-trace | matchh "publicIP.143." the line below:

 

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:Failed to get real out-ifp for .local..0, dst:public.143.1, in vr_id: 0

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  Output ifp is self but it is not for self packet and the IP(public.143.1) is in Source NAT pool, we don't create the session.
Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  packet dropped, self ip in src nat pool.

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  flow didn't create session, code=-1.

 

So I change src and dest for avaya to a static nat including a proxy-arp pointing to the avayaIP and then god it works !!!

 

 

Contributor
Posts: 45
Registered: ‎09-28-2009
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hello,

 

I have the same problem, can you post the last configuration you did?

 

Thanks in advance.

 

Regards.

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi,

 

My config changed to a cluster configuration so i give it from my mind Smiley Happy 

 

interfaces {
fe-0/0/0 {
        unit 0 {
            family inet {
                address pubic.143.2/29;
            }
        }
    }
}
fe-0/0/1 {
        unit 0 {
            family inet {
                address local.12.254/24; # connect to the same vlan than server avaya(dmz)
            }
        }
    }
fe-0/0/2 {
        unit 0 {
            family inet {
                address local.11.9/29; #interconnect with the switch
            }
        }
    }
}
security{
   nat {
          static {
    rule-set avaya-SIPTrunk-nat {
        from zone untrust;
        rule publicAvayaNat {
            match {
                destination-address public.143.1/32;
            }
            then {
                static-nat prefix local.12.1/32;
            }
        }
    }
}
proxy-arp {
    interface fe-0/0/0.0 {
        address {
            public.143.1/32;
        }
    }
}

   }
   zones {
        security-zone trust {
           address-book {
                address address httpAvaya local.14.3/32; # http server for update ip phone and so
           }
           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/2.0;
            }
        security-zone untrust {
           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/0.0;
            }
         security-zone dmz{
           address-book {
                address dmz_int local.12.0/24;
                address server-avaya local.12.1/32; #main IP for SIP provider
                address avayaServices local.12.0/29;
            }

           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/1.0;
            }
      policies {
          from-zone trust to-zone dmz {
                    policy voice-to-avaya {
                match {
                    source-address trust_voice; # voice vlan to avaya servers
                    destination-address avayaServices;
                    application any;
                }
                then {
                    permit;
                }
            }
            policy httpAvaya-to-avayaServices {
                match {
                    source-address httpAvaya;
                    destination-address avayaServices;
                    application any;
                }
                then {
                    permit; # for administration of avaya
                }
            }
            from-zone dmz to-zone trust {
        policy dmzAvaya-to-Dect {
            match {
                source-address server-avaya;
                destination-address trust_voice;
                application any;
            }
            then {
                permit; # Avaya server needs to connect to DECT
            }
        }
    }

          }
      }
}

 

Let me know if there is something missing. Good luck

Contributor
Posts: 45
Registered: ‎09-28-2009
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Thanks!

 

I'll go to test!

 

Regards

Contributor
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

HI Jmartinez,

 

Be carefull, i have some troubles every night. VOIP doesn't work. 

 

I use EX4200 in virtual chassis, Avaya G450 with S8300 and 2 SRX240H in cluster.

Ip Phone are on voice vlan, they pass through the SRX (that manage the DMZ vlan) to register to Avaya (dmz vlan)

 

What about yours?