SRX

Does anyone have working SCTP over SRX345 (or any other branch SRX)?

I'm trying to connect two diameter peers and it seems that the return traffic gets dropped by the firewall.

The policy allows any traffic between two peers and I have exactly same issue on tunnel and on phy interfaces. Maybe there is a way to disable state tracking for sctp as a workaround...

It looks something like this:
Session ID: 365626, Policy name: Diameter/57, State: Active, Timeout: 1800, Valid
In: 192.168.130.246/3868 --> 192.168.120.2/3868;sctp, Conn Tag: 0x0, If: ge-0/0/4.301, Pkts: 2965, Bytes: 249060,
Out: 192.168.120.2/3868 --> 192.168.130.246/3868;sctp, Conn Tag: 0x0, If: st0.2, Pkts: 0, Bytes: 0,

show security flow session session-identifier 365626
Session ID: 365626, Status: Normal, State: Active
Flags: 0x8000040/0x0/0x3
Policy name: Diameter/57
Source NAT pool: Null
Dynamic application: junos:UNKNOWN,
Encryption: Unknown
Application traffic control rule-set: INVALID, Rule: INVALID
Maximum timeout: 1800, Current timeout: 1800
Session State: Valid
Start time: 1291124, Duration: 3937
In: 192.168.130.246/3868 --> 192.168.120.2/3868;sctp,
Conn Tag: 0x0, Interface: ge-0/0/4.301,
Session token: 0xd, Flag: 0x21
Route: 0x2a0010, Gateway: 192.168.159.2, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 3185, Bytes: 267540
Out: 192.168.120.2/3868 --> 192.168.130.246/3868;sctp,
Conn Tag: 0x0, Interface: st0.2,
Session token: 0x13, Flag: 0x20
Route: 0x3a0010, Gateway: 192.168.120.2, Tunnel: 537001987
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
Total sessions: 1

In the same time TCP/ICMP works correctly - the peers who supports Diameter over TCP are working. 

SRX345 on JunOS 15.1X49-D50.3

Hi,

It looks like the SRX is not detecting the application for this traffic and probably reading this as TCP packets.

Source NAT pool: Null
Dynamic application: junos:UNKNOWN,

_____________________________________________

The policy allows any traffic between two peers

_____________________________________________

Is the security policy matching "application any"?

I would suggest defining an explicit security policy for sctp using application junos-gprs-sctp because sctp handshake is different to tcp.

https://www.juniper.net/documentation/en_US/junos12.1x47/topics/example/gprs-sctp-policy-based-inspection-configuring.html

Also note:

• You configure one policy to permit SCTP traffic from all client IPs to all server IPs, and another policy to permit SCTP traffic from server IPs to client IPs. If one policy has an SCTP profile, then the same SCTP profile is needed for the reverse policy.

Cheers,

Ashvin

I was thinking about it but GPRS feature set seems to be unvailable on branch SRX345. My current policy allow any sctp traffic (there is junos-sctp-any pre-defined in JUNOS)

Policy: Diameter, action-type: permit, State: enabled, Index: 57, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: trust, To zone: r-hss
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    HSS(global): 192.168.120.2/32
  Application: junos-sctp-any
    IP protocol: 132, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No
  Session log: at-create

I have similar policy applied in both directions: trust->r-hss and r-hss -> trust

Hi,

The security policy sounds right as the application junos-sctp-any is IP protocol 132, i.e sctp.

Apparently, an sctp profile is also required in the security policy configuration but am not sure its configurable:

http://www.juniper.net/techpubs/en_US/junos12.1x45/topics/example/gprs-sctp-profile-configuring.html

security-flow session output indicates the application hasn't been detected as sctp.

Do you see any security-flow session for the return traffic by matching source-address of server for instance.

Would you have an idea of the payload size expected. Also, can you confirm the traffic reaches the server/destination.

Cheers,

Ashvin

Hi Ashvin,

Well, for some reason some sessions are getting thru and some are not.

In the flow debug I see some errors, maybe it is relevant:

Aug  1 11:56:07 11:56:06.291369:CID-1:RT:flow_ipv4_rt_lkup success 192.168.120.2, iifl 0x58, oifl 0x58
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:  route lookup: dest-ip 192.168.120.2 orig ifp st0.2 output_ifp st0.2 orig-zone 19 out-zone 19 vsd 0
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:  route to 192.168.120.2
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:ha_ifp: ge-0/0/4.301
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:Conflict session (365626) is VALID state
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:  packet dropped, failed to install nsp2
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:failed to install nsp2
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:first path session installation failed
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:  flow find session returns error.
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:flow_process_pkt_exception: Freeing lpak 0x51048bb0 associated with mbuf 0x42180900
Aug  1 11:56:07 11:56:06.291369:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc 0)

Hi, 

Is there any chances traffic is being load balanced and some return packets for that session is assymetric:

Aug  1 11:56:07 11:56:06.291369:CID-1:RT:Conflict session (365626) is VALID state
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:  packet dropped, failed to install nsp2
Aug  1 11:56:07 11:56:06.291369:CID-1:RT:failed to install nsp2

Cheers,

Ashvin

Hi,

No, there is no ECMP or asynchronous routing: two zones, one interface per zone (one interface is a tunnel). Both sides continiously trying to open the connection to each other (sending INIT)

Thanks,

Yury.

So, basically - SCTP FSM is broken in SRX branch and we cannot use this box for our SCTP-based applications. With all-allow policies the traffic doesn't get thru due to failing state machine/alg?  Here is another example:

Aug  5 11:45:48 11:45:48.574538:CID-1:RT:  flow_first_in_dst_nat: in <gr-0/0/0.0>, out <N/A> dst_adr 192.168.130.68, sp 5114, dp 65027
Aug  5 11:45:48 11:45:48.574538:CID-1:RT:  chose interface gr-0/0/0.0 as incoming nat if.
Aug  5 11:45:48 11:45:48.574538:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 192.168.130.68(65027)
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 172.16.14.17, x_dst_ip 192.168.130.68, in ifp gr-0/0/0.0, out ifp N/A sp 5114, dp 65027, ip_proto 132, tos 0
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:Doing DESTINATION addr route-lookup
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_ipv4_rt_lkup success 192.168.130.68, iifl 0x5d, oifl 0x4c
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  routed (x_dst_ip 192.168.130.68) from r-site14 (gr-0/0/0.0 in 0) to ge-0/0/4.301, Next-hop: 192.168.159.2
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_policy_search: policy search from zone r-site14-> zone SIGNAL (0x0,0x13fafe03,0xfe03)
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:Policy lkup: vsys 0 zone(21:r-site14) -> zone(13:SIGNAL) scope:0
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:             172.16.14.17/5114 -> 192.168.130.68/65027 proto 132
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  policy has app_id 83
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  app 83, timeout 1800s, curr ageout 1800s
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  permitted by policy iub(76)
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  packet passed, Permitted by policy.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_src_xlate:  incoming src port is : 5114.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  dip id = 0/0, 172.16.14.17/5114->172.16.14.17/5114 protocol 0
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  choose interface ge-0/0/4.301(P2P) as outgoing phy if
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:is_loop_pak: No loop: on ifp: ge-0/0/4.301, addr: 192.168.130.68, rtt_idx:0
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  check nsrp pak fwd: in_tun=0x5d, VSD 0 for out ifp ge-0/0/4.301
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  vsd 0 is active
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:-jsf : Alloc sess plugin info for session 992137575740
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:[JSF]Normal interest check. regd plugins 28, enabled impl mask 0x0
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:ha_ifp: ge-0/0/4.301
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:+++++++++++jsf_test_plugin_data_evh: 3
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:[JSF]Plugins(0x0, count 0) enabled for session = 992137575740, impli mask(0x0), post_nat cnt 0 svc req(0x61420d28)
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:-jsf : no plugin interested for session 992137575740, free sess plugin info
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:[JSF]Releasing plugin info blocks
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  service lookup identified service 83.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  flow_first_final_check: in <gr-0/0/0.0>, out <ge-0/0/4.301>
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:In flow_first_complete_session
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:flow_first_complete_session, pak_ptr: 0x51048bc8, nsp: 0x59897640, in_tunnel: 0x56a31d30
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:construct v4 vector for nsp2 and nsp
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  existing vector list 0x10024-0x4ae3d520.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  existing vector list 0x10024-0x4ae3d520.
Aug  5 11:45:48 11:45:48.574736:CID-1:RT:  Session (id:130364) created for first pak 10024
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:first pak processing successful
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  flow_first_install_session======> 0x59897640
Aug  5 11:45:48 11:45:48.574932:CID-1:RT: nsp 0x59897640, nsp2 0x598976d0
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  make_nsp_ready_no_resolve()
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:flow_ipv4_rt_lkup success 172.16.14.17, iifl 0x5d, oifl 0x5d
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  route lookup: dest-ip 172.16.14.17 orig ifp gr-0/0/0.0 output_ifp gr-0/0/0.0 orig-zone 21 out-zone 21 vsd 0
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  route to 172.16.14.17
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:ha_ifp: ge-0/0/4.301
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:Conflict session (137881) is VALID state
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  packet dropped, failed to install nsp2
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:failed to install nsp2
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:first path session installation failed
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:  flow find session returns error.
Aug  5 11:45:48 11:45:48.574932:CID-1:RT:flow_process_pkt_exception: Freeing lpak 0x51048bc8 associated with mbuf 0x43103200
Aug  5 11:45:48 11:45:48.574932:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc 0)

Hi,

You're probably right. SCTP seems to be supported on the following only:

SRX1400, SRX3400, SRX3600, SRX5400, SRX5600, SRX5800

Would be good if there's confirmation from J-TAC or other Juniper representative.

Cheers,

Ashvin

It's a bug: PR1204177

ETA is end of September, target release 15.1X49-D60. 

I'm seeing the exact same story (return traffic showing 0 packets and 0 bytes; flow debug saying failed to install nsp2) for SNMP traffic from an external host (over a tunnel) to the SRX device (loopback).

Also, Ashvin, it's the Dynamic application that's junos:UNKNOWN. I.e. AppID is either not enabled, or doesn't recognize the traffic. That has no bearing on the "match application" part of the policy.