SRX

last person joined: 3 days ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
Expand all | Collapse all

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

  • 1.  SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 07-30-2010 09:53

    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;
                }
            }
        }
    }

     

     

     



  • 2.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-02-2010 02:00

    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#M34



  • 3.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-02-2010 06:37

    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?

     

     



  • 4.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-03-2010 11:48
      |   view attached

    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

    Attachment(s)

    txt
    avayaLog.txt   28 KB 1 version


  • 5.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-03-2010 18:28

    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?

     

     



  • 6.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 02:03
      |   view attached

    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

     

    Attachment(s)

    txt
    avayaLog.txt   28 KB 1 version


  • 7.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 02:53

    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.

     



  • 8.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 04:41
      |   view attached

    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?

    Attachment(s)

    txt
    sip-trace.txt   645 KB 1 version


  • 9.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 04:56

    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

     

     

     

     

     

     

     

     

     



  • 10.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 10:27

    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



  • 11.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-04-2010 18:38

    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


  • 12.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-05-2010 03:24

    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

     

     



  • 13.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider
    Best Answer

    Posted 08-06-2010 02:33

    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 !!!

     

     



  • 14.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-15-2010 23:59

    Hello,

     

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

     

    Thanks in advance.

     

    Regards.



  • 15.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-17-2010 07:45

    Hi,

     

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

     

    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



  • 16.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-19-2010 23:23

    Thanks!

     

    I'll go to test!

     

    Regards



  • 17.  RE: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

    Posted 08-20-2010 04:03

    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?