Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 5264 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Intermittent VPN Issues

Alan Spark

Hi,

One of our users has reported being unable to access one of the servers over the VPN, but only intermittently.

When they tried to ping the server they got "Request timed out" but soon after it started working again. I replicated this and saw two timeouts followed by successful replies. After this the connection will be stable for some time before it happens again.

Pinging *.*.*.* with 32 bytes of data:
Request timed out.
Request timed out.
Reply from *.*.*.*: bytes=32 time=51ms TTL=63
Reply from *.*.*.*: bytes=32 time=51ms TTL=63

I cannot see any sign of ICMP being blocked in the firewall log but I have seen some "Invalid Traffic" entries around the time that they reported the problem. The message is simply "Invalid packet.". I note that there is another entry with exactly the same source and destination port soon after where the traffic is allowed.

I would appreciate any suggestions for debugging this.

Regards,

Alan



This thread was automatically locked due to age.
  • 0 in reply to FormerMember

    Hi Harsh,

    We have not experienced the issue again but we feel that it is too soon to say for certain that it has been fixed. We'll continue to monitor it.

    However, we would still like the issue to be fixed so that we can enable the firewall acceleration option again.

    I note that 18.0.5 MR-5 is now available. I don't see anything about this issue in it though?

    Regards,

    Alan

  • FormerMember
    0 FormerMember in reply to Alan Spark

    Hi ,

    This issue has been investigated internally with the ID (NC-69286 - ICMP times out when Firewall Acceleration is turned on). A fix for this issue would be tentatively included in firmware release 18.0 MR6. 

    The temporary workaround is to turn off the firewall acceleration. 

    I'd suggest you turn on the blog notification to get notified about the new releases & news here: Release Notes & News

    Thanks,

  • 0 in reply to FormerMember
    Unknown said:
    I'd suggest you turn on the blog notification to get notified about the new releases & news here

    Thanks, noted.

    Alan

  • 0 in reply to FormerMember

    Hi Harsh,

    We had the need to reboot the UTM today for some electrical work and soon after putting it back online I received a report from one of our users that they couldn't access one of the servers in the way described above.

    I verified that the firewall acceleration option is still disabled and after checking the logs I saw a corresponding message: "Could not associate packet to any connection.".

    This error message is reported on TCP ports 445 and 10444. Looking back through the logs, I can see similar errors from before our reboot so I think that can be discounted. However, I do see occurrences of at least 445 being allowed. So it is a bit random.

    I would appreciate your feedback.

    Regards,

    Alan

  • 0 in reply to Alan Spark

    , I'm just following up on my last message to make sure that you received it. This case should no longer be considered resolved.

  • FormerMember
    0 FormerMember in reply to Alan Spark

    Hi ,

    I think your original post only refers to the issue related to the ICMP timeout, which is internally identified with the ID (NC-69286 - ICMP times out when Firewall Acceleration is turned on). A fix for this issue would be tentatively included in firmware release 18.0 MR6. 

    However, the issue with the communication on TCP ports 445 and 10444 might not be related to the firewall acceleration; I'd suggest you investigate this issue separately, take a packet capture when the issue occurs, if you don't have a support case, open one for further investigation. 

    Thanks,

  • 0 in reply to FormerMember

    Ok, thanks for your quick reply. I will try to create a support case but from past experience I get much better support from you and your colleagues on here. I could wait weeks for a reply to a support case.

    However, it will be very difficult to do what you suggest and take a packet capture as the issue is intermittent and it is happening for a remote colleague so I don't have control over the software.

    Regards,

    Alan

Unfiltered HTML