Skip to main content
Dickie
Dickie
New Member
November 6, 2014
Solved

V5.2.1 TCP Reset Issue

  • November 6, 2014
  • 8 replies
  • 23449 views

Hi All,

A heads up here.  We had some downtime for a bandwidth upgrade so at the same time we thought we would upgrade our 200D to V5.2.1. - which we have working fine elsewhere.  This worked fine in most aspects BUT:

An Ironport cluster and a VMware application running over an IPsec VPN would disconnect almost every 59mins 23 (ish) seconds.  Then reconnect.  VPN's would stay up no errors or other notifications.   It was so regular we knew it must be a timer or something somewhere - but we could not find it.  We did packet traces of the disconnects and found that at the time of the disconnects 'something' was causing the application(s) to reset all its sessions. 

We chased the ISP blaming the new link and looking at all manner of things that could be causing this, all to no avail.  Today we reverted to V5.2.0 Build 589 - so far we have not had one disconnect (3hrs).  The config on the Firewall is exactly the same. 

 

I hope this stops someone else pulling their hair out.    If the resets 'come back' I'll update this post.

 

 

    Best answer by Dickie

    Hi,

     

    I can't find the relevant article but I believe you will find that is related to interface MTU / TCP MSS - try the following:

    set tcp-mss 1380

    set mtu-override enable set mtu 1454

     

    These will be set on your WAN interface.  You can play with the sizes to optimise them.

     

    Cheers

    8 replies

    Uwe_Sommerfeld
    Uwe_Sommerfeld
    New Member
    November 6, 2014

    Thank for the info.

    Did you vary the TCP timeout settings to verify it is not related to connection tracking in any way?

    Dickie
    DickieAuthor
    New Member
    November 6, 2014

    Hi - indeed we did to BIG numbers but it made no difference.

    Dickie
    DickieAuthor
    New Member
    November 6, 2014

    Errors just started happening again!!!!! - Sorry turns out this was the ISP resetting THEIR router...so it still might be an issue.  I'll get less trigger happy and let you know at the end of the day.

    emnoc
    emnoc
    New Member
    November 6, 2014

    If it's regular, than it sounds like a  timer. A question or two

     

    Q1: you say it's 60min and regular?

     

    Q2: And the traffic is only effected over the vpn

     

    Q3: is this by any chance a SA time count down

     

    I would monitor the  SA lifetime and then seen any thing relates.

     

     

     

     

    Dickie
    DickieAuthor
    New Member
    November 6, 2014

    HI - yes our thoughts were a timer.  In answer to your questions:

     

    Q1: you say it's 60min and regular?

    Never quite the full 60mins - and regular(ish) sometimes we get a rogue fail.   Q2: And the traffic is only effected over the vpn

    That's as far as we can track it as these application run over the VPN   Q3: is this by any chance a SA time count down

    Possibly but we've played with all manner of settings, the VPN's never drop.  AND after reverting to the earlier code the problem appears to have gone away using the same config / vpns etc 

    emnoc
    emnoc
    New Member
    November 6, 2014

    Do you have logging on if the vpn is resetting in a 60min interval or less? if the SA are being torn down and restarting to a underlaying problem, it could cause the issues that you are seeing.

     

    Also ensue the SA lifetime on near and far peers.

     

    e.g

    show vpn  ipsec phase2 "< phase2 interface name  >" | grep key         set keylifeseconds 3600

     

     

    Dickie
    DickieAuthor
    New Member
    November 6, 2014

    emnoc wrote:

    Do you have logging on if the vpn is resetting in a 60min interval or less? if the SA are being torn down and restarting to a underlaying problem, it could cause the issues that you are seeing.

     

    Also ensue the SA lifetime on near and far peers.

     

    e.g

     

    show vpn  ipsec phase2 "< phase2 interface name  >" | grep key        set keylifeseconds 3600

     

     

    Emnoc,

     

    Thanks for the reply. Would be happy to do this - but since we have downgraded the firmware we are not seeing the issues so cannot track it.  It could be related to SA's but the settings are the same as they were before, timers everything.  So if it is, it is still related to the 5.2.1 release I would think?

    snobs
    snobs
    New Member
    December 2, 2014

    Hello, one of our customers complained about TCP RST while downloading source code (file by file) with wget from a homepage.

    (Take a look at http://forums.gradle.org/gradle/topics/unable_to_pull_from_maven_central_connection_reset_by_peer)

    I could confirm the behavior with wireshark. When I download the files outside the firewall I do not see any TCP RSTs within wireshark. I have 311B with 5.0.7 firmware installed. (I do not have UTM/IPS enabled for that "Port 80"-policy)

     

    Any ideas what could cause this?

     

    Regards

     

     

    Dickie
    DickieAuthorAnswer
    New Member
    December 2, 2014

    Hi,

     

    I can't find the relevant article but I believe you will find that is related to interface MTU / TCP MSS - try the following:

    set tcp-mss 1380

    set mtu-override enable set mtu 1454

     

    These will be set on your WAN interface.  You can play with the sizes to optimise them.

     

    Cheers

    flajax1
    flajax1
    New Member
    December 19, 2014

    Dickie wrote:

    Hi,

     

    I can't find the relevant article but I believe you will find that is related to interface MTU / TCP MSS - try the following:

    set tcp-mss 1380

    set mtu-override enable set mtu 1454

     

    These will be set on your WAN interface.  You can play with the sizes to optimise them.

     

    Cheers

    You are awesome!  I had a customer with a broken application that worked prior to the FWF-60D being installed.  We could telnet to the correct ports, but the application would fail.  I applied the above changes to WAN1 and it works.  Please note, this was on 5.08.

    Terms & ConditionsAccessibility statement