SRX

Platform:SRX 3600

I 'd like to know if I enable sequence-check ,what will SRX check?

2:if I set security flow tcp-session no-sequence-check,it means seq-check will be disabled

in which case I should use this feature?

I saw in someother KB it is related to TCP sliding windows principle,not sure whether it is same in SRX

pls give me an example of this, packet capture display will be appreciated

Every TCP packet contains both a Sequence Number (SYN) and an Acknowledgement Number (ACK), which helps TCP maintain error free end-to-end communications.  It can also be used, to a limited extent, to validate a packet.

JunOS monitors SYN and ACK numbers within a certain window to ensure that the packet is indeed part of the session.  If a packet is received with numbers that fall out of the expected range, the packet is dropped.  This is normally a desired behavior, as the packet is invalid.  But sometimes some vendors will use non-RFC methods to verify a packet's validity or for some other reason a server will send badly numbered packets, expecting a return. 

Disabling no-sequence-check may be required in this scenario or another such as large file transfers as it will increase throughput.

SRX are stateful firewalls and only allow traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.

The sequence number is abbreviated as SEQ, and is not the same thing as the SYN flag.  SYN flag is used as part of the three-way handshake.  The SEQuence number is used to determine the current location (sequence) in the TCP window.

I agree that leaving this enabled by default is a good thing, as it's intent is to block illegitimate packets, such as spoofed packets, from being allowed through the session.  I also agree that there are occasionally old applications or OS stacks that misbehave (do not follow RFCs for TCP) and send packets outside the window, and expect the far side to receive them.

I do not agree that it may be necessary for large file transfers, as it will not increase throughput. 

The last paragraph of the previous poster appears to change topics to TCP syn checking, which is a different feature/check than TCP sequence checking.  The statement is true, but to be clear, is not related to sequence number checking.

Regards,

Joel

thanks for the clarification,it is very helpful

yep,I know how SYN work,I need to focus on SEQ to make it clear for mr

would u mind to show me an example on this?As I know window size will change randomly due to network condition

for example

bytes 1-10,11-20,21-30,31-40

sender                                                                          receiver

      1       ---------data 1-10------------- >

       2  -<-------ack and window size 20 bytes-------

        3    ------------data31-40------------>                                          <---- this is out of order,right?

but to achieve this,SRX need to records each window size per packet and compare history seq /window which it got from last session,

in our case, number 3 should compared 31-40 with stats on num 1 and 2

right?

it will be very helpful if u give me a correct example per packet and detail

I am not sure whether mine is right because I didn't describe SEQ on it

thanks in advance

Hi

Basically it calculates, using TCP window size, an acceptable range of sequence numbers,
and drops packets that are outside of sequence. See KB articles (they are about Netscreen
firewalls, but should be the same for SRX):

http://kb.juniper.net/InfoCenter/index?page=content&id=KB3292&smlogin=true
http://kb.juniper.net/InfoCenter/index?page=content&id=KB5814&smlogin=true

this no-sequence-check feature is used in scenario which session between host and SRX,right?

session is terminated in srx

tcp connection is between host and srx ,instead of transit traffic

host--------------SRX

right?

Hi All,

Longing to ask a few questions about the SRX series gateway hopefully will get some answers over here

Doubts :

1. Can we incrase the bandwidth of the internal interface joining RE and PFE or it is the same for all the device models or does it vary from model to model . I suppose that the bandwidth is 100 mbps as per juniper datasheets. Correct me if i am wrong

2. Do we have any limit on the number of  terms i can define with in a routing policy and a firewall filter?

3. What is the default interface mtu size in junos platforms?

4. Maximum number of VLAN's that can be created on a physical interface ? Is it the 4096 or 1024 in Junos?

5. The switch which is connected to the 2 physical interfaces , which are combined together to form a Reth interface should it necessarily be a L2 switch or an L3 switch will also do the same functionality?

6. When i use Radius server in my authentication order , do i still need to have users mapped in my device? If yes how do i map only the usernames , because anyways authorization is already defined on the radius server

7.In Firewall Authentication, lets say there is a NAT enabled device before the firewall , once the user who has the right credential gets authenticated subsequently all the users will be given access to my server because authentication table entry is stored based on the ip address and not usernames. So how do i restrict that other users who dont have the credentials without accessing my server?

8. Shoud i use application as telnet , ftp and http in the security policy when i am using pass through authentication? Because pass through supports only ftp,http and telnet traffic?

9. Can we use the primary interface ip address as the web authentication ip address or is it mandatory that we define one more ip address on the interface as web auth ip

10. When is a real time scenario that we have 2 ip address defined on the interface and both being actually used?

NAT questions : 

11. How many actual translations can we have with 1 public IP when i disable PAT ?

12. What does this actually mean D-NAT will generate allow incoming packets for voip algs?

13. Can we use the same ip for S NAT and D NAT then wat is the use of static NAT?

14. When we r doing Static NAT , can we have both the internal and external communication happen at the same time , because  there can be only one translation per one public IP when i disable PAT?

15. In source NAT with address shifting , the user will bind private IP range to public ip range . 

Lets imagine my private range starts from 10.1.10.5 to 10.1.10.254

My public pool is from 100.1.1.1 to 100.1.1.200

I map my private base address to public address from 10.1.10.5 to 100.1.1.1

So lets say 10.1.10.5 gets translated to 100.1.1.1

What happens if 10.1.10.7 intiates a session before 10.1.10.6 will he be assigned 100.1.1.3 or 100.1.1.2

VPN : 

16.Can we actualy load balance between redundant VPN tunnels between two branch offices?

17.In the IPSEC header , what does the Next Header information mean?

To srikanthsingireddy: Looks like you attended JSEC class and have some concerns, right? 🙂

I would say its better to ask 1 question per thread (and also open a new thread, not use old one).

So here is answer to No. 1 - This is platform-dependant, you can't increase it. On some platforms it is 100Mbps, on some - 1 Gbps.

To Robert: No, this is a feature to increase security for transit TCP sesions. This may also apply for host-inbound sessions to SRX.

to pk:

in transit session,SRX need to know the current seq and window size from previous  packet,and not ack'd size to decide whether this packet is out of windows,right?

if in this way,SRX needs do much to calc this.

0-10,10-20,20-30 bytes

1:if window size is 20 bytes which is informed from receiver to sender,

2:after send 0-10 ,10-20,receiver didn't ack these

3:then sender send 20-30 bytes which is out of window size

see,srx need to know lots of info to deceide this packet is out of window

Am I right?

to pk

do u have a tcp test tool to verify this ,some tool which can change seq in the sending packet