Signature 1300 TCP Segment Override,

Hi again, i want to question about this signature because we has seen many alerts related with this signature on our internal network.
When i review the information about this signature in the local signature information page, i dont find nothing that say me about this.
The number of daily alerts from signature 1300 is about 30000, the sources are internal computer against internal server on our switched network.
Can someone help me to find a solution to mitigate this problem.
Thanks

I would suggest you to investigate on why you are seeing this alarm. Are you running any of the custom developed applications on the network? Sometimes this could mean someone trying to bypass your IPS.
If you are convinced that the alarm is false, you can disable the alarm on the IPS.

Similar Messages

  • ID 1300 TCP Segment Overwrite

    I keep seeing the Sig ID 1300 TCP Segment Overwrite between two hosts. This is normal traffic and I have no reason to suspect the machines as having to been compromised or misused. I was wondering if anyone has had the experience of seeing this signature fire for normal traffic. Can this be a programming error caused by our in house programmers writing custom applications?

    Personally, I error on the side of suspicion. I would recommend investigating this further. This signature is somewhat suspicious in that segmentation overwriting is something hackers use to try to bypass IPS. Is the destination address always the same, if you are always getting the error from the same source to the same destination that could be a bad sign….?
    I would suspect that it's not a program error because, most programmers will just send their data to a socket and the underlying network code will set up windowing and segmentation. In this case most socket code is pretty tried and true.
    Is this data coming from a VPN segment? It could be an MTU issue. Could be a network device behaving badly between your source and destination, if this is happening it should be true for more then just one host.
    Don’t forget you can use your reporting tool and turn on verbose reporting when ever the alert is generated or to assist in forensics you can turn on reporting of all packets between a specific host or destination….

  • Signature 1330-X: TCP segment out of order - what does it mean?

    Hi,
    on a customer's site, on one of their IPS, I get a lot of sig 1330 alerts, mainly those two:
    1330-12: TCP segment is out of order. If the signature status is set to disabled, the packet will be passed to all engines that are not stream based.
    This signature will not produce an alert in promiscuous mode regardless of the signature status.
    1330-17: TCP segment out of state order. If a packet in a stream causes this signature to produce an alert, processing will cease for that stream. This signature will not produce an alert in promiscuous mode regardless of the signature status
    I'm not sure how to interpret these alerts correctly and/or how to troubleshoot further. Does anyone have an idea?
    Thanks a lot,
    Florian

    Is your sensor monitoring more than one network segment?
    If so then these alarms are common when a TCP connection crosses both networks and gets seen twice by the sensor.
    This can confuse the sensor's tracking of the connection.
    A common scenario is to have the sensor monitor both the Inside network or a firewall as well as the DMZ. When an internal user connects to the company's web server the traffic gets seen by the sensor both on the Inside network and in the DMZ. The sensor tries to put the packets from both networks together in order to try and monitor it as a single connection. Because the packets get modified by the firewall it often results in inconsitency between traffic on the 2 sides and causes the sensor to be confused about the connection.
    The good news is that if this is your problem, then there are 2 easy workarounds.
    1) If your sensor supports virtual sensors, then create a second virtual sensor. Assign one network to default vs0, and assign the other network to the new virtual sensor. This way each virtual sensor sees traffic on just one of the networks and won't become confused.
    2) If your sensor does not support additional virtual sensors, or you've used up all 4 virtual sensors, then there is a configuration option within the virtual sensor configuration itself:
    Inline TCP Session Tracking Mode
    By default it is set to Virtual Sensor which is why it tries to put together packets from both networks to try and look at is a single connection and gets confused.
    BUT it can also be set to Interface and Vlan. This configuration allows the virtual sensor to treat the traffic on each network independantly. The connection on the first network will be monitored independant of the connection on the second network. This will prevent the virtual sensor from getting confused.
    The above is just my guess at what is going on in your network based on what we've seen on other networks. If this doesn't address the reason for the signature triggerings, then please respond back with more information about your network.
    It is possible that these could be a hacker trying to avoid detection by the sensor, but more likely something in your deployment is confusing the sensor.

  • TCP Hijack/TCP Segment Overwrite false positives?

    Hello all,
    I was just curious if anyone else has had many false positives with 3 signatures in particular: TCP Hijack (3250.0 - High), TCP Hijack Simplex Mode (3251.0 - High), and TCP Segment Overwrite (1300.0 - High). The reason I think they are false positives is because they occur everyday, and I've also seem them caused by internal network traffic that crosses an IPS sensor (that is, making the potentially dangerous assumption that the internal devices can be trusted). We usually see between a dozen and 3 dozen a day depending on the signature, and we have 8 IPS total deployed internally and on the perimeters.
    Has anyone else had similar experiences? If so, do you have any suggestions on how to decrease the number of false positives for these alerts?
    Thanks,
    Ryan

    I get TCP Hijack and TCP Segment Overwrite all the time. I opened a TAC case about it because it was getting out of hand, and the engineer said that TCP Hijack would be very very hard to execute and if it is getting fired a lot odds are it is a false positive.
    This was his response:
    5769 - Malformed HTTP Request
    This signature basically just looks for traffic destined to one of your web ports (defined by the WEBPORTS variable) and containing a valid HTTP request (i.e., GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT) but followed by malformed (i.e., not proper http protocol syntax) URI information. This type of malformed HTTP request can be used for a variety of exploits. Microsoft has malformed HTTP request vulnerabilities, another attack known as "http request smuggling" can be launched using malformed HTTP requests at a Squid web proxy, which may cause the web proxy and an upstream HTTP agent to disagree on the boundary between HTTP requests on a persistent connection. These are a couple of examples.
    If you open this signature in IDM and go to "Edit", you can see the regex it looks for within the http payload. Basically, it looks for a valid HTTP request followed by the hex code regex [\x20][\x21-\x7e]+[\x20]?[\x0d\x0a]. A properly formed HTTP request should not contain this hex code.
    It's possible that normal traffic could cause this, but unlikely. If you have further concerns about this signature firing, please capture the trigger packet context either by changing the signature action to 'produce verbose alert' or 'log attacker packet' for analysis. If you need assistance in analyzing these alerts, please contact TAC and open a case on this issue.
    3250 or 3251 - TCP Hijack and TCP Hijack Simplex Mode
    This signature detects attempts to insert packets into a TCP stream by an attacker in an effort to take over this session. However, if you're using inline ips mode, TCP Hijack attacks are impossible. Also, this type of attack is very rare and not easy to do, and is often a false positive. Types of things that can be used by network sniffers to detect that a TCP hijack may be happening is looking for repeated ARP updates, frames sent between client and server with different MAC addresses, or tcp ack storms.
    For these two hijack signatures, per MySDN information:
    "This signature fires upon detecting out of order ack packets. The most common network event that may trigger this signature is an idle telnet session. The TCP Hijack attack is a low-probability, high level-of-effort event."
    Thus, very likely to be false positives and unlikely to be a legitimate attack given the difficulties involved in doing this. However, it's worth checking out the source / destination of the attacks. Again though, if you are running inline mode, these attacks are impossible and you can ignore these signatures.
    About the TCP Segment Overwrite, mine is always fired for port 20 traffic from some sort of web cache server. Is that the same for you?

  • Java NIO - TCP segment size abnormally low

    Hi !
    After noticing a weird behaviour on our Linux production server for code that works perfectly on my Windows dev box, I used tcpdump to sniff the packets that are actually sent to our clients.
    The code I use to write the data is as simple as :
    // using NIO - buffer is at most 135 bytes long
    channel.write(buffer);
    if (buffer.hasRemaining()) {
        // this never happens
    }When the buffer is 135 bytes long, this systematically results in two TCP segments being sent : one containing 127 bytes of data, the other one containing 8 bytes of data.
    Our client is an embedded system which is poorly implemented and handles TCP packets as whole application messages, which means that the remaining 8 bytes end up being ignored and the operation fails.
    I googled it a bit, but couldn't find any info about the possible culprit (buffer sizes and default max tcp segment sizes are of course way larger that 127 bytes !)
    Any ideas ?
    Thanks !

    NB the fragmentation could also be happening in any intermediate router.
    All I can suggest is that you set the TCP send buffer size to some multiple of the desired segment size, or maybe just set it very large, like 64k-1, so that you can reduce its effect on segmentation.

  • FSG Error when using segment override

    Hi,
    I have the following error when using segment override :
    General Ledger: Version : 12.0.0
    Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
    RGRARG module: Financial Statement Generator
    +---------------------------------------------------------------------------+
    Current system time is 26-APR-2012 11:17:22
    +---------------------------------------------------------------------------+
    Starting Program RGRARG.
      Arguments are:
        0   RGRARG                    - RGRARG
        1   username/password         - username/password
        2   0                         - 0
        3   Y                         - Y
        4   Data Access Set ID        - 1030
        5   Chart of Accounts Id      - 101
        6   ADHOC Prefix              - FSG-ADHOC-
        7   Industry                  - C
        8   Flex Code Id              - GLLE
        9   Default Ledger ID         -
       10   Report ID                 - 1011
       11   Row Set ID                - 3461
       12   Column Set ID             - 1018
       13   Period of Interest        - SEP-11
       14   Unit of Measure ID        - IDR
       15   Rounding Option           - C
       16   Override Values           - ----DIV3---000000
       17   Content Set ID            -
       18   Row Order ID              -
       19   Report Display Set ID     -
       20   Output Option             - R
       21   Exceptions Flag           - N
       22   Miniumum Display Level    -
       23   Effective Date            -
       24   Parameter Set ID          - 1011
       25   Maximum Page Length       - 58
       26   Sub-Request Run ID        - -998
       27   Application Shortname     - SQLGL
    Message level is: Normal
    rgrini() 26-APR-2012 11:17:22 rgrini.build_per_arr:
    Query for period set name from GL_ACCESS_SETS
    SELECT  period_set_name
    FROM GL_ACCESS_SETS
    WHERE access_set_id = 1030
    rgrini.build_per_arr:
    period set name from GL_ACCESS_SETS:
    ACCOUNTING
    rgrini.build_per_arr:
    Query for period names from GL_PERIODS
    SELECT  period_name,
        to_number(to_char(end_date,'YYYYMMDD'))
    FROM GL_PERIODS
    WHERE period_set_name = :p_value
    ORDER BY NLSSORT(period_name,'NLS_SORT=BINARY') ASC
    control->report_id = 1011
    control->row_set_id = 3461
    control->column_set_id = 1018
    control->row_order_id = 0
    control->content_set_id = 0
    control->display_set_id = 0
    control->parameter_set_id = 1011
    control->resp_lvl = 0
    control->round_option = C
    control->output_option = R
    control->excp = FALSE
    control->sub_req_run_id = -998
    control->appl_id = 101
    control->id_flex_code = GLLE
    control->ldg_val_set_id = 1010673
    control->ledger_id = 0
    control->ledger_name =
    control->ledger_currency =
    control->access_set_id = 1030
    control->security_segnum = 0
    control->per_cnt = 162
    control->runtime_currency = IDR
    control->resp_id = 50386
    control->resp_appl_id = 101
    control->enforce_security = TRUE
    control->sec_rules = NULL
    control->reduced_ranges = NULL
    control->num_reduced_ranges = 0
    control->max_char_width = 1
    control->total_num_cols = 0
    control->page = NULL
    << rgrini() 26-APR-2012 11:17:22
    rgranl() 26-APR-2012 11:17:22Current date and time:  Thu Apr 26 11:17:22 2012
    rgrgsa() 26-APR-2012 11:17:22
    << rgrgsa() 26-APR-2012 11:17:22
    rgrdrs() 26-APR-2012 11:17:22req_id_str =
    809694
    rgrdpg.rgrdpg: Unable to read value for profile option RG_DEBUG_ON..
    rgrprt.rgrprt: Defaulting value for profile option RG_DEBUG_ON to FALSE..
    rgrgas() 26-APR-2012 11:17:22 Entering code to get axis set 1018
    << rgrgas() 26-APR-2012 11:17:22
    rgrgas() 26-APR-2012 11:17:22 Entering code to get axis set 3461
    << rgrgas() 26-APR-2012 11:17:23
    rgrgrp() 26-APR-2012 11:17:23
    << rgrgrp() 26-APR-2012 11:17:23
    COA Structure :
    Segment: LEDGER_SEGMENT : Ledger
    Segment: SEGMENT1 : COMPANY
    Segment: SEGMENT2 : ACCOUNT
    Segment: SEGMENT3 : PRODUCT
    Segment: SEGMENT4 : DIVISION
    Segment: SEGMENT5 : DEPOT
    Segment: SEGMENT6 : COST CENTER
    Segment: SEGMENT7 : FUTURE
    Segment value security is enforced for Financial Statement Generator reporting.
    rgrrsr() 26-APR-2012 11:17:23
    rgrrsf() 26-APR-2012 11:17:23
    << rgrrsf() 26-APR-2012 11:17:23
    << rgrcrl() 26-APR-2012 11:17:23
    << rgrrsr() 26-APR-2012 11:17:23
    rgrpsr() 26-APR-2012 11:17:23The COMPANY segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All COMPANY values will be processed.
    The ACCOUNT segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All ACCOUNT values will be processed.
    The PRODUCT segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All PRODUCT values will be processed.
    The DIVISION segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All DIVISION values will be processed.
    The DEPOT segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All DEPOT values will be processed.
    The COST CENTER segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All COST CENTER values will be processed.
    The FUTURE segment has security enabled. However, there are no security rules assigned to this responsibility for this segment, or this segment uses a dependent value set.  All FUTURE values will be processed.
    << rgrpsr() 26-APR-2012 11:17:23
    rgrdrs.rgrdrs: Getting value for profile option EXPAND_PARENT_VALUE equal No.
    PERF0005: Oracle error detected in get_def_ldgs - ORA-01403: no data found
    <x get_def_ldgs() 26-APR-2012 11:17:24
    <x get_def_ldgs() 26-APR-2012 11:17:24
    rgrgax() 26-APR-2012 11:17:24 rgrgax:get_axes
    Starting axis query.
    rgumsg:
    fdnwsc() is used by default
    rgrgax.get_conts - Prepare:
    ORA-00936: missing expression
    Current date and time:  Thu Apr 26 11:17:24 2012
    Entered sauulc with code 1 from line 3333 of file rg/lib/rgrgax.c.
    +---------------------------------------------------------------------------+
    Start of log messages from FND_FILE
    +---------------------------------------------------------------------------+
    +---------------------------------------------------------------------------+
    End of log messages from FND_FILE
    +---------------------------------------------------------------------------+
    +---------------------------------------------------------------------------+
    Executing request completion options...
    Output file size:
    0I have followed the following notes but it didn't help me
    R12: FSG: PERF0005 Error Detected In GET_DEF_LDGS - ORA-01403: No Data Found Common Issues [ID 1368691.1]
    Generating a FSG Report Application Does Not Find Profile Values for RG_LOGFILE_DETAIL_LEVEL and EXPAND_PARENT_VALUE [ID 165339.1]
    does anyone know how to solved the problem ??
    please advise
    thx

    I have followed the following notes but it didn't help me
    R12: FSG: PERF0005 Error Detected In GET_DEF_LDGS - ORA-01403: No Data Found Common Issues [ID 1368691.1]
    Generating a FSG Report Application Does Not Find Profile Values for RG_LOGFILE_DETAIL_LEVEL and EXPAND_PARENT_VALUE [ID 165339.1]
    does anyone know how to solved the problem ??If none of the docs help, please log a SR.
    Thanks,
    Hussein

  • TCP segment of a reassembled PDU - nsludt2.cap (0/1)

    Hi,
    I've been having some issues lately with long DNS lookups. I ran
    PacketScan on the DNS server (10.10.10.20), and saw many occurences of
    "TCP segment of a reassembled PDU". This mainly occurred during
    communication between the DNS server and other servers on our network.
    Could this segmentation issue be the cause of processing delays on DNS
    querys? Is this something I should be concerned about? Does it
    indicate MTU mismatches between servers? All servers are NW6 SP4.
    Please see the attached CAP file.
    Thanks,
    Jeff Palmer

    1) The messages "TCP segment of a reassembled PDU" are not problems. They
    are just indicators that the main traffic of that connection occured
    earlier. In fact, looking at the actual packets shows that these are
    simply TCP keepalive packets. E.g. there are some open connections to your
    server and the other end that has the connection open sends keepalive
    packets from time to time.
    2) Your DNS traffic is perfectly "normal". All requests are properly
    replied to. The delays you get are entirely due to the external server
    216.68.4.10 (ns1.zoomtown.com) which is slow in responding to you. It
    takes 0.8 seconds for the first query your DNS does to it, and 1.7 seconds
    for the followup Akamai DNS query. Overall, this leads to a delay of about
    2.5 seconds for answering your workstation's query.
    If you want to speed up your DNS you should investigate why the queries to
    216.68.4.10 take so long and maybe you should consider forwarding your DNS
    requests to a different faster server.
    Marcel Cox (using XanaNews 1.18.1.6)

  • TCP segment Overwrite

    Recently, I've been seeing a ton of messages on the IPS Event Viewer stating that TCP Segment Overwrites have been detected. The events are from either the IPS-A to our DMZ or vice versa. It just started whenever we added some servers to the network. Does anybody have any suggestions? We traced the packets, it's not hacker related. It seems like maybe a server or app. may be causing the issue. The problem is isolating it. I would appreciate any feedback you could provide. Thanks!

    TCP normalization
    Through intentional or natural TCP session segmentation, some classes of attacks can be hidden. To make sure policy enforcement can occur with no false positives and false negatives, the state of the two TCP endpoints must be tracked and only the data that is actually processed by the real host endpoints should be passed on. Overlaps in a TCP stream can occur, but are extremely rare except for TCP segment retransmits. Overwrites in the TCP session should not occur. If overwrites do occur, someone is intentionally trying to elude the security policy or the TCP stack implementation is broken. Maintaining full information about the state of both endpoints is not possible unless the sensor acts as a TCP proxy. Instead of the sensor acting as a TCP proxy, the segments will be ordered properly and the normalizer will look for any abnormal packets associated with evasion and attacks.
    http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00804cf52e.html

  • TCP Segment Overwrite - IDSM2 with IPS5.1(1d)

    Hi,
    I have an IDSM2 running IPS5.1(1d)S220 upgraded recently from 4.x. My network has windows desktops (spanned on multiple subnets) whose default gateway is a Cisco 6500 FWSM module.
    Since I upgraded to IPS 5.x, I am seeing lots and lots of TCP Hijack and TCP Segment Overwrite alarms. The source addresses of these alarms are my windows PCs, destination addresses are Windows 2003 servers..Sometimes, the destination address is 0.0.0.0 and ports are empty.
    It is difficult to ignore so many alarms unless there is a technical explanation to see if the placement of FWSM is causing IPS to treat this as a threat.
    Can someone help me to get out of this issue?

    I found this on a previously written thread. I cannot find the thread anymore. All credit is given to the message owner. i hope the reply helps.
    mlhall of - CISCO SYSTEMS wrote:
    Oct 6, 2003, 11:06am PST
    I have several packet traces from several customers that see this alert. There appears to be a bug in the microsoft TCP stack when connections go stale. What happens is that the last successful segment's last byte is resent with a value of 0xff. This is after the other endhost has ACK'ed the sequence from the last segments.
    So for example.
    a->b seq=100 data="ABCDEFG"
    b->a ack=107 no data
    a->b seq=106 data="(0xff)"
    The last packet in the example is overwriting the G in the first packet with an 0xff. This causes the IDS to fire. We are working on detecting this stack bug in a new version.

  • MiFi4510L sporatically hangs on Web sites w/ IE Win6&7 (THIS URL!); TCP Segment Lost

      I had to use Dial-Up just to get this far!!!
      Sometimes it works fine; other times it hangs FOREVER (TCP Segment Lost)! Must manually STOP..
    I've let it hang for over 10 minutes; nothing ever happens after the last trace entry. No re-xmits.
      The last time it hung, I collected dumps&traces, then Stop & Refresh in IE and it worked fine.
    During the hang, I successfully TELNET'ed to the DNS (same IPAddr), so it's NOT apparently a connection issue.
    Certainly YOUR OWN URL should NOT be having constant problems!
      I powered off&on your device. Still occasionally hangs.
      WHAT IS GOING ON? The only solution seems to be to use Dial-Up!!! I have NEVER had this problem in all the many years
    using Dial-Up.
      Here are NETMON traces from a recent hang
    669 {DNS:131, UDP:130, IPv4:4} 4:01:19 PM 8/4/2011 127    DNS 0x1    192.168.1.2 8.8.8.8 DNS:QueryId = 0xCAB, QUERY (Standard query), Query  for www.goes.noaa.gov of type Host Addr on class Internet
    670 {DNS:131, UDP:130, IPv4:4} 4:01:19 PM 8/4/2011 247    DNS 0x2    8.8.8.8 192.168.1.2 DNS:QueryId = 0xCAB, QUERY (Standard query), Response - Success, 129.15.96.23, 140.90.33.23 ...
    671 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x1 Half Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=......S., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442312612, Ack=0, Win=8192 ( Negotiating scale factor 0x2 ) = 8192
    672 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=49248, PayloadLen=0, Seq=3625396553, Ack=3442312613, Win=5840 ( Negotiated scale factor 0x9 ) = 2990080
    673 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 104 iexplore.exe 0x12d4  TCP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=...A...., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442312613, Ack=3625396554, Win=4380 (scale factor 0x2) = 17520
    674 {HTTP:133, TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 497 iexplore.exe 0x12d4 Request, GET /GIFS/ECIR.JPG  HTTP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 HTTP:Request, GET /GIFS/ECIR.JPG
    675 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 104 iexplore.exe 0x12d4  TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49248, PayloadLen=0, Seq=3625396554, Ack=3442313006, Win=14 (scale factor 0x9) = 7168
    676 {HTTP:133, TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 1286 iexplore.exe 0x12d4 HTTP Payload, URL: /GIFS/ECIR.JPG  IPHTTPS 0x2 Connected Good 0x1 129.15.96.23 192.168.1.2 IPHTTPS
      Frame: Number = 676, Captured Frame Length = 1286, MediaType = WiFi
    - WiFi: [Unencrypted Data] F.....P, (I) RSSI = -49 dBm, Rate = 67.5 Mbps
      - MetaData: RSSI = -49 dBm, Rate = 67.5 Mbps
         Version: 2 (0x2)
         Length: 32 (0x20)
       - OpMode: Extensible Station Mode
          StationMode:           (...............................0) Not Station Mode
          APMode:                (..............................0.) Not AP Mode
          ExtensibleStationMode: (.............................1..) Extensible Station Mode
          Unused:                (.0000000000000000000000000000...)
          MonitorMode:           (0...............................) Not Monitor Mode
         Flags: 0 (0x0)
         PhyType: 802.11g
         Channel: 1, Center Frequency: 2412 MHz
         lRSSI: -49 dBm
         Rate: 67.5 Mbps
         TimeStamp: 08/04/2011, 22:01:19.606165 UTC
      - FrameControl: Version 0,Data, Data, F.....P(0x4208)
         Version:        (..............00) 0
         Type:           (............10..) Data
         SubType:        (........0000....) Data
         DS:             (......10........) DS to STA via AP
         MoreFrag:       (.....0..........) No
         Retry:          (....0...........) No
         PowerMgt:       (...0............) Active Mode
         MoreData:       (..0.............) No
         ProtectedFrame: (.1..............) Yes
         Order:          (0...............) Unordered
        Duration: 48 (0x30)
        DA: 1C659D CA2550
        BSSID: Novatel Wireless, Inc. 04C0AF
        SA: Novatel Wireless, Inc. 04C0AF
      - SequenceControl: Sequence Number = 889
         FragmentNumber: (............0000) 0
         SequenceNumber: (001101111001....) 889
    - LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
      - DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         IG:      (.......0) Individual Address
      - SSAP: SNAP(Sub-Network Access Protocol), Command
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         CR:      (.......0) Command Frame
      - Unnumbered: UI - Unnumbered Information
         MMM:  (000.....) 0
         PF:   (...0....) Poll Bit - No Response Solicited
         MM:   (....00..)
         Type: (......11) Unnumbered(U) Frame
    - Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
        OrganizationCode: XEROX CORPORATION, 0(0x0000)
        EtherType: Internet IP (IPv4), 2048(0x0800)
    - Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 44701, Total IP Length = 1222
      - Versions: IPv4, Internet Protocol; Header Length = 20
         Version:      (0100....) IPv4, Internet Protocol
         HeaderLength: (....0101) 20 bytes (0x5)
      - DifferentiatedServicesField: DSCP: 0, ECN: 0
         DSCP: (000000..) Differentiated services codepoint 0
         ECT:  (......0.) ECN-Capable Transport not set
         CE:   (.......0) ECN-CE not set
        TotalLength: 1222 (0x4C6)
        Identification: 44701 (0xAE9D)
      - FragmentFlags: 16384 (0x4000)
         Reserved: (0...............)
         DF:       (.1..............) Do not fragment
         MF:       (..0.............) This is the last fragment
         Offset:   (...0000000000000) 0
        TimeToLive: 46 (0x2E)
        NextProtocol: TCP, 6(0x6)
        Checksum: 63171 (0xF6C3)
        SourceAddress: 129.15.96.23
        DestinationAddress: 192.168.1.2
    - Tcp: [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49248, PayloadLen=1182, Seq=3625399474 - 3625400656, Ack=3442313006, Win=14 (scale factor 0x9) = 7168
    ALL HANGS GET "SEGMENT LOST"
        SrcPort: HTTP(80)
        DstPort: 49248
        SequenceNumber: 3625399474 (0xD81734B2)
        AcknowledgementNumber: 3442313006 (0xCD2D872E)
      - DataOffset: 80 (0x50)
         DataOffset: (0101....) 20 bytes
         Reserved:   (....000.)
         NS:         (.......0) Nonce Sum not significant
      - Flags: ...AP...
         CWR:    (0.......) CWR not significant
         ECE:    (.0......) ECN-Echo not significant
         Urgent: (..0.....) Not Urgent Data
         Ack:    (...1....) Acknowledgement field significant
         Push:   (....1...) Push Function
         Reset:  (.....0..) No Reset
         Syn:    (......0.) Not Synchronize sequence numbers
         Fin:    (.......0) Not End of data
        Window: 14 (scale factor 0x9) = 7168
        Checksum: 0xF6BE, Good
        UrgentPointer: 0 (0x0)
        TCPPayload: SourcePort = 80, DestinationPort = 49248
    - Http: HTTP Payload, URL: /GIFS/ECIR.JPG
        payload: HttpContentType = NetmonNull
      IPHTTPS:
    677 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=...A...., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442313006, Ack=3625396554, Win=4380 (scale factor 0x2) = 17520
      Comments?

    11103 {TCP:736, IPv4:735} 7:02:15 AM 8/24/2011 104 iexplore.exe  0x598 TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
      Frame: Number = 11103, Captured Frame Length = 104, MediaType = WiFi
    - WiFi: [Unencrypted Data] F.....P, (I) RSSI = -51 dBm, Rate = 67.5 Mbps
      - MetaData: RSSI = -51 dBm, Rate = 67.5 Mbps
         Version: 2 (0x2)
         Length: 32 (0x20)
       - OpMode: Extensible Station Mode
          StationMode:           (...............................0) Not Station Mode
          APMode:                (..............................0.) Not AP Mode
          ExtensibleStationMode: (.............................1..) Extensible Station Mode
          Unused:                (.0000000000000000000000000000...)
          MonitorMode:           (0...............................) Not Monitor Mode
         Flags: 0 (0x0)
         PhyType: 802.11g
         Channel: 2, Center Frequency: 2417 MHz
         lRSSI: -51 dBm
         Rate: 67.5 Mbps
         TimeStamp: 08/24/2011, 13:02:15.623759 UTC
      - FrameControl: Version 0,Data, Data, F.....P(0x4208)
         Version:        (..............00) 0
         Type:           (............10..) Data
         SubType:        (........0000....) Data
         DS:             (......10........) DS to STA via AP
         MoreFrag:       (.....0..........) No
         Retry:          (....0...........) No
         PowerMgt:       (...0............) Active Mode
         MoreData:       (..0.............) No
         ProtectedFrame: (.1..............) Yes
         Order:          (0...............) Unordered
        Duration: 48 (0x30)
        DA: 1C659D CA2550
        BSSID: Novatel Wireless, Inc. 04C0AF
        SA: Novatel Wireless, Inc. 04C0AF
      - SequenceControl: Sequence Number = 2338
         FragmentNumber: (............0000) 0
         SequenceNumber: (100100100010....) 2338
    - LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
      - DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         IG:      (.......0) Individual Address
      - SSAP: SNAP(Sub-Network Access Protocol), Command
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         CR:      (.......0) Command Frame
      - Unnumbered: UI - Unnumbered Information
         MMM:  (000.....) 0
         PF:   (...0....) Poll Bit - No Response Solicited
         MM:   (....00..)
         Type: (......11) Unnumbered(U) Frame
    - Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
        OrganizationCode: XEROX CORPORATION, 0(0x0000)
        EtherType: Internet IP (IPv4), 2048(0x0800)
    - Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 62246, Total IP Length = 40
      - Versions: IPv4, Internet Protocol; Header Length = 20
         Version:      (0100....) IPv4, Internet Protocol
         HeaderLength: (....0101) 20 bytes (0x5)
      - DifferentiatedServicesField: DSCP: 0, ECN: 0
         DSCP: (000000..) Differentiated services codepoint 0
         ECT:  (......0.) ECN-Capable Transport not set
         CE:   (.......0) ECN-CE not set
        TotalLength: 40 (0x28)
        Identification: 62246 (0xF326)
      - FragmentFlags: 16384 (0x4000)
         Reserved: (0...............)
         DF:       (.1..............) Do not fragment
         MF:       (..0.............) This is the last fragment
         Offset:   (...0000000000000) 0
        TimeToLive: 46 (0x2E)
        NextProtocol: TCP, 6(0x6)
        Checksum: 46808 (0xB6D8)
        SourceAddress: 129.15.96.23
        DestinationAddress: 192.168.1.2
    - Tcp: Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
        SrcPort: HTTP(80)
        DstPort: 49472
        SequenceNumber: 3370795655 (0xC8EA4287)
        AcknowledgementNumber: 3806480488 (0xE2E24868)
      - DataOffset: 80 (0x50)
         DataOffset: (0101....) 20 bytes
         Reserved:   (....000.)
         NS:         (.......0) Nonce Sum not significant
      - Flags: ...A....
         CWR:    (0.......) CWR not significant
         ECE:    (.0......) ECN-Echo not significant
         Urgent: (..0.....) Not Urgent Data
         Ack:    (...1....) Acknowledgement field significant
         Push:   (....0...) No Push Function
         Reset:  (.....0..) No Reset
         Syn:    (......0.) Not Synchronize sequence numbers
         Fin:    (.......0) Not End of data
        Window: 14 (scale factor 0x9) = 7168
        Checksum: 0x14A8, Good
        UrgentPointer: 0 (0x0)
    11104 {HTTP:737, TCP:736, IPv4:735} 7:02:15 AM 8/24/2011 1286 iexplore.exe HTTP Payload, URL: /GIFS/ECIR.JPG  0x598 HTTP 0x2 Connected Good 0x1 129.15.96.23 192.168.1.2 [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49472, PayloadLen=1182, Seq=3370798575 - 3370799757, Ack=3806480488, Win=14 (scale factor 0x9) = 7168 HTTP:HTTP Payload, URL: /GIFS/ECIR.JPG
      Frame: Number = 11104, Captured Frame Length = 1286, MediaType = WiFi
    - WiFi: [Unencrypted Data] F.....P, (I) RSSI = -51 dBm, Rate = 67.5 Mbps
      - MetaData: RSSI = -51 dBm, Rate = 67.5 Mbps
         Version: 2 (0x2)
         Length: 32 (0x20)
       - OpMode: Extensible Station Mode
          StationMode:           (...............................0) Not Station Mode
          APMode:                (..............................0.) Not AP Mode
          ExtensibleStationMode: (.............................1..) Extensible Station Mode
          Unused:                (.0000000000000000000000000000...)
          MonitorMode:           (0...............................) Not Monitor Mode
         Flags: 0 (0x0)
         PhyType: 802.11g
         Channel: 2, Center Frequency: 2417 MHz
         lRSSI: -51 dBm
         Rate: 67.5 Mbps
         TimeStamp: 08/24/2011, 13:02:15.626528 UTC
      - FrameControl: Version 0,Data, Data, F.....P(0x4208)
         Version:        (..............00) 0
         Type:           (............10..) Data
         SubType:        (........0000....) Data
         DS:             (......10........) DS to STA via AP
         MoreFrag:       (.....0..........) No
         Retry:          (....0...........) No
         PowerMgt:       (...0............) Active Mode
         MoreData:       (..0.............) No
         ProtectedFrame: (.1..............) Yes
         Order:          (0...............) Unordered
        Duration: 48 (0x30)
        DA: 1C659D CA2550
        BSSID: Novatel Wireless, Inc. 04C0AF
        SA: Novatel Wireless, Inc. 04C0AF
      - SequenceControl: Sequence Number = 2339
         FragmentNumber: (............0000) 0
         SequenceNumber: (100100100011....) 2339
    - LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
      - DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         IG:      (.......0) Individual Address
      - SSAP: SNAP(Sub-Network Access Protocol), Command
         Address: (1010101.) SNAP(Sub-Network Access Protocol)
         CR:      (.......0) Command Frame
      - Unnumbered: UI - Unnumbered Information
         MMM:  (000.....) 0
         PF:   (...0....) Poll Bit - No Response Solicited
         MM:   (....00..)
         Type: (......11) Unnumbered(U) Frame
    - Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
        OrganizationCode: XEROX CORPORATION, 0(0x0000)
        EtherType: Internet IP (IPv4), 2048(0x0800)
    - Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 62249, Total IP Length = 1222
      - Versions: IPv4, Internet Protocol; Header Length = 20
         Version:      (0100....) IPv4, Internet Protocol
         HeaderLength: (....0101) 20 bytes (0x5)
      - DifferentiatedServicesField: DSCP: 0, ECN: 0
         DSCP: (000000..) Differentiated services codepoint 0
         ECT:  (......0.) ECN-Capable Transport not set
         CE:   (.......0) ECN-CE not set
        TotalLength: 1222 (0x4C6)
        Identification: 62249 (0xF329)
      - FragmentFlags: 16384 (0x4000)
         Reserved: (0...............)
         DF:       (.1..............) Do not fragment
         MF:       (..0.............) This is the last fragment
         Offset:   (...0000000000000) 0
        TimeToLive: 46 (0x2E)
        NextProtocol: TCP, 6(0x6)
        Checksum: 45623 (0xB237)
        SourceAddress: 129.15.96.23
        DestinationAddress: 192.168.1.2
    - Tcp: [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49472, PayloadLen=1182, Seq=3370798575 - 3370799757, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
        SrcPort: HTTP(80)
        DstPort: 49472
        SequenceNumber: 3370798575 (0xC8EA4DEF)
        AcknowledgementNumber: 3806480488 (0xE2E24868)
      - DataOffset: 80 (0x50)
         DataOffset: (0101....) 20 bytes
         Reserved:   (....000.)
         NS:         (.......0) Nonce Sum not significant
      - Flags: ...AP...
         CWR:    (0.......) CWR not significant
         ECE:    (.0......) ECN-Echo not significant
         Urgent: (..0.....) Not Urgent Data
         Ack:    (...1....) Acknowledgement field significant
         Push:   (....1...) Push Function
         Reset:  (.....0..) No Reset
         Syn:    (......0.) Not Synchronize sequence numbers
         Fin:    (.......0) Not End of data
        Window: 14 (scale factor 0x9) = 7168
        Checksum: 0xD681, Good
        UrgentPointer: 0 (0x0)
        TCPPayload: SourcePort = 80, DestinationPort = 49472
    - Http: HTTP Payload, URL: /GIFS/ECIR.JPG
      - payload: HttpContentType = NetmonNull
         HTTPPayloadLine: 4ïücvÖ#8íÒª×wªx!fÕ.î Ô-`µ’whð˜URÇT1Ç ªsxXLdß«Ç(Ü’¤YVú‘ÈèGZ

  • TCP segmentation offload (TSO) and vmxnet3/1000v - bug?

    NOTE: My knowledge of ESX and the 1000v does not run deep so I do not have a thorough understanding of the relationship / integration between those two components.  If anything I'm saying here is out-of-line I apologize in advance.
    Yesterday a report came in that an IIS application on a staging server in our test environment was not working (in Internet Explorer it returned "Page cannot be displayed").  The IIS server sits behind an F5 load balancer.  Both the F5 and the IIS server are VM guests on a VMware ESX host.  Both the IIS server and the F5 had recently been moved to a new environment in which the version of 1000v changed and the vnic driver changed (from E1000 to vmxnet3) and this appeared to be the first time that anybody noticed an issue.
    After some digging we noticed something peculiar.  The problem only manifested when the IIS server and the F5 were on the same physical host.  If they were not co-resident everything worked just fine.  After reviewing packet captures we figured out that the "Page cannot be displayed" was not because the content wasn't making it from IIS server to client but rather because the content was gzip compressed and something happened in-transit between the IIS server and the client to corrupt the payload thereby making the gzip decompressible.  As a matter of fact, at no time was IP connectivity ever an issue.  We could RDP to the IIS server and SSH/HTTP into the F5 without any issues.
    I started digging in a little deeper with Wireshark (details of which are included as an attached PDF).  It turns out that a bug??? involving TCP segmentation offload (TSO) was causing the payload of the communication to become corrupted.  What I'm still trying to figure out is who is responsible for the bug?  Is it VMware or Cisco?  I'm leaning towards Cisco and the 1000v and this is why.
    Referring to the attached PDF, TEST #2 (hosts co-resident) and TEST #3 (hosts not co-resident) show packet captures taken from the IIS box, the 1000v and the F5.  Figure 6 shows that the contents of the gzip'd payload can be deciphered by Wireshark as it leaves the IIS box.  Figure 8 shows capture data from the 1000v's perspective (spanning rx/tx on the F5 veth port).  It's still good at this point.  However, figure 10 shows capture data taken on the F5.  At some point in time between leaving the egress port on the 1000v and entering the F5 it cannot be decompressed (corrupt data).  There is no mention that the TCP checksum failed.  In my mind the only way that the data could be corrupt without a TCP checksum failure is if the corruption occurred during the segmentation of the packet.  However, if it was due to the guest OS-level vnic driver then why did it still look good to the 1000v egress towards the F5? 
    The most curious aspect of this whole thing is the behavior I described earlier related to onbox vs. offbox.  This problem only occurs when the traffic is switched in memory.  Refer to figure's 11 - 16 for capture data that shows the very same test when the F5 and IIS are not co-resident.  Is the 1000v (or vnic) savy enough to skip TSO in software and allow the physical NIC to do TSO if it knows that the traffic is going to have to leave the host and go onto the physical wire?  That's the only way I can make sense of this difference in behavior.
    In any case, here are all of the guest OS-level settings related to offload of any type (along with the defaults) and the one we had to change (in bold) to get this to work with the vmxnet3 NIC:
    IPv4 Checksum Offload: Rx & Tx Enabled
    IPv4 TSO Offload: From Enabled to Disabled
    Large Send Offload V2 (IPv4): Enabled
    Offload IP Options: Enabled
    Offload TCP Options: Enabled
    TCP Checksum Offload (IPv4): Rx & Tx Enabled
    UPD Checksum Offload (IPv4): Rx & Tx Enabled

    Hi sdavids5670
    Did you ever find a proper fix to your issue? was updating the N1Kv a solution?
    I have exactly the same symptoms with a N1Kv [4.2(1)SV2(1.1a)], F5 (ASM), vmxnet3 guests, however I'm failing all RDP (win2k8r2) and SSH large packets (redhat); the rest of my traffic appears fine. This only occurs when the F5 resides on the same VEM or VMware host as you have seen. My packet captures are similar.
    My work around is two fold. Firstly create rules to isolate the F5 onto hosts where guests are not utilising it and secondly, disable TCP offloading (I use IPv4 only). Neither of these are solutions.
    I have not tried a non-F5 trunk (ie, perhaps a CSR1000v) to replicate this without the F5.
    I suspected that the onbox / offbox issue was something specific about the logic of the VEM installed on the host (that's how I justified it to myself) rather than VEM->VEM traffic. It appears that only vEth -> vEth traffic on the same VEM is the issue. Also, I can only replicate this when one of the vEth ports is a trunk. I have yet to be able to replicate this if both are access port-groups (vEths).
    I have yet to log a TAC as I wanted to perform testing to exclude the F5.
    Thought that I would just ask....
    Cheers
    David

  • %FW-4-TCP_OoO_SEG: Dropping TCP Segment

    Any idea what this means? Why are these packets being dropped?
    Mar  2 13:46:11.315: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1826858942 1492 bytes is out-of-order; expected seq:1826829902. Reason: TCP reassembly queue overflow - session 10.2.31.31:50052 to 31.13.69.42:80
    Mar  2 13:52:13.439: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1264022358 1492 bytes is out-of-order; expected seq:1263984606. Reason: TCP reassembly queue overflow - session 10.2.31.31:50228 to 184.84.239.17:80
    Mar  2 14:08:46.261: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:3591782745 1492 bytes is out-of-order; expected seq:3591717405. Reason: TCP reassembly queue overflow - session 10.2.31.13:58412 to 207.46.206.46:80
    Mar  2 14:08:47.825: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:3591726117 1492 bytes is out-of-order; expected seq:3591720309. Reason: TCP reassembly queue overflow - session 10.2.31.13:58412 to 207.46.206.46:80

    Ronni,
    It looks like you are running some firewall inspection features on your router. What's happening is your out-of-order queue is getting full and dropping packets.
    One thing you can try is increasing the queue size:
    ip inspect tcp reassembly queue length
    I would suggest starting with a size of about 80 to see if it has any effect on the logs. If you are still seeing an issue, could you provide a 'show ip inspect statistics' and any relevant configuration?
    Thanks!
    Joey

  • TCP Segmentation Offload and Jumbo Frames.

    I have VmWare-OpenSolaris and VMXNET3 network card.
    Can i enable subj?
    #:> ifconfig vmxnet3s mtu 5000
    ifconfig: setifmtu: SIOCSLIFMTU: vmxnet3s0: Invalid argument

    Hi sdavids5670
    Did you ever find a proper fix to your issue? was updating the N1Kv a solution?
    I have exactly the same symptoms with a N1Kv [4.2(1)SV2(1.1a)], F5 (ASM), vmxnet3 guests, however I'm failing all RDP (win2k8r2) and SSH large packets (redhat); the rest of my traffic appears fine. This only occurs when the F5 resides on the same VEM or VMware host as you have seen. My packet captures are similar.
    My work around is two fold. Firstly create rules to isolate the F5 onto hosts where guests are not utilising it and secondly, disable TCP offloading (I use IPv4 only). Neither of these are solutions.
    I have not tried a non-F5 trunk (ie, perhaps a CSR1000v) to replicate this without the F5.
    I suspected that the onbox / offbox issue was something specific about the logic of the VEM installed on the host (that's how I justified it to myself) rather than VEM->VEM traffic. It appears that only vEth -> vEth traffic on the same VEM is the issue. Also, I can only replicate this when one of the vEth ports is a trunk. I have yet to be able to replicate this if both are access port-groups (vEths).
    I have yet to log a TAC as I wanted to perform testing to exclude the F5.
    Thought that I would just ask....
    Cheers
    David

  • Verify TCP reset is actually working

    How do I see if the TCP reset is working,
    I have IDM, IEV, IDS MC, and for some reason I cannot locate the information
    Thanks in advance

    Hi,
    Beside logging direct to IDM or using IDS MC, you may use IEV to view the tcp reset action taken by the IDS.
    1. Launch your IEV
    2. Under 'View', double-click the "Sig Name Group".
    2. Right-click the log associated to the signature you've selected, for example "TCP Segment Overwrite" (SID 1300)
    I assumed you have already set the "EventAction" under your selected signature (tcp-based) to include 'reset'.
    3. Back to IEV, right-click the signature log and choose 'Expand Whole Details'. A window will popup with details on the attack log.
    4. Right-click this event, and choose 'View Alarms'.
    5. Scroll to the right, and look under 'TCP Reset Sent'. If the stated value is 'true', the IDS has performed the tcp reset to the attack event.
    Cheers!
    AK

  • Signature 1330 causes packet drops

    Hello Members,
    i see in my IPS-NME module a hign number of packet drops because of the following signatures:
    1330-17: TCP segment out of state order
    1330-12: TCP segment is out of order.
    the targets and the attacers are internal hosts.
    are these signatures triggered because of not propper configured policies or is this an indicator for problems in the internal network.
    thanks for your inputs.
    regards
    alex

    Hello Sid,
    thanks for your answer. I learned that most of packets where the Signature 1330 triggers are packets from the IPS module to the IPS Express Manager. I added wireshark dump to the case.
    That's really odd, i ran a traceroute from the IPS Manager to the IPS Module and vice versa and the flow look ok to me.
    Trace from the IPS module to the IPS Manager
    # trace 10.0.128.5
    traceroute to 10.0.128.5 (10.0.128.5), 4 hops max, 40 byte packets
    1  172.16.1.9 (172.16.1.9)  1.479 ms  1.327 ms  1.275 ms
    2  172.16.1.1 (172.16.1.1)  3.616 ms  2.952 ms  1.907 ms
    3  10.89.27.10 (10.89.27.10)  2.288 ms  2.044 ms  2.136 ms
    4  10.89.27.21 (10.89.27.21)  8.106 ms  9.148 ms  8.266 ms
    return path
    C:\Users\Administrator.NOS-POC>tracert 172.16.1.11
    Tracing route to 172.16.1.11 over a maximum of 30 hops
      1    <1 ms    <1 ms    <1 ms  10.0.128.1
      2     2 ms     3 ms     2 ms  172.16.2.1
      3     1 ms     1 ms     1 ms  10.89.27.22
      4     9 ms     9 ms     9 ms  10.89.27.9
      5     8 ms     8 ms     8 ms  172.16.1.6
      6     8 ms     8 ms     8 ms  172.16.1.11
    Trace complete.
    trace from the IPS module's gateway
    #traceroute vrf CENTRAL 10.0.128.5 source 172.16.1.9
    Type escape sequence to abort.
    Tracing the route to 10.0.128.5
      1 172.16.1.1 0 msec 0 msec 0 msec
      2 10.89.27.10 0 msec 0 msec 4 msec
      3 10.89.27.21 8 msec 8 msec 8 msec
      4 172.16.2.6 8 msec 8 msec 4 msec
      5 10.0.128.5 4 msec 4 msec 4 msec
    what make me wonder is that the IPS module doesn't show hops further than 4 hops.
    regards
    alex

Maybe you are looking for

  • Error while creating a new component

    Dear I'm trying to create a component to delete the "blank" value from an option list so that the default value would be the first value on the list. I did all the steps in the "Component Wizard" and at the end when clicking finish the following erro

  • Unlocking external hard drive that was locked with time machine

    I use a MBP Retina (Mid 2012) with OSX 10.9.4.  I left the MBP at Apple for repair and they changed the mother card and reformatted my HD (SSD).  Since I had a backup on a WD My Passport external drive I was not too worried to restore.  I had clicked

  • Raw Images opened and saved as TIFF of PSD in photoshop not added to LR library

    Images opening from LR to PS6 are opened as CR2 files (canon) and then saved in PS - the resulting saved images are PSD files. These files are not added to the LR catalog without re-importing them. This behavior is different than it was in CS5 - in C

  • Release date for ECC 6.0.

    Hi, Can anybody please tell me the release date for ECC 6.0. Full points will be assigned. Thanks, JB

  • Connection Pool Metrics in ASC - doesn't seem to reflect the usage

    Guys, So i am trying to monitor the jdbc connection pool usage using the Application server Console (following the link --> Cluster Topology > Application Server: engas-machine > OC4J: oc4jinstance > JDBC Resources > Connection Pool Metrics: "myconne