Forum Discussion

Nom_55811's avatar
Nom_55811
Icon for Nimbostratus rankNimbostratus
Sep 01, 2009

nPath Triggering Router Intrusion Detection

Hi All,

 

 

We've recently deployed a pair of BIG-IP 1600's in a redundant configuration in front of our corporate web site. Since then, we've discovered several customers using Billion (http://au.billion.com/) modems, are having the website blocked by the Intrusion Detection built into their router.

 

 

The web servers were previously running under a DSR configuration behind a pair of Foundry ServerIron's (very old, and unstable), so nPath was the best solution for us in the short term, until we had time to properly design and deploy a separate VLAN for F5 powered hardware.

 

 

What the customers are seeing is something like:

 

Aug 26 18:31:38 home.gateway:firewall:info: 1524.121 Intrusion TCP FIN scan(17)

 

 

Last week we created a new Fast L4 profile with the following configuration options changed from the default:

 

- Idle Timeout: 120 seconds

 

- Loose Initiation: Off

 

- Loose Close: On

 

- TCP Close Timeout: 120 seconds

 

 

These changes were based on some old F5 documentation we found which described nPath in more detail. Following these changes, users are now seeing the following errors:

 

 

Intrusion TCP reset scan(18)

 

 

So, it would seem that we've gone from one set of problems to another.

 

 

Has anyone else encountered similar problems? Do you have any solution that would rectify this issue?

 

 

Thanks in advance.

2 Replies

  • It might help to have an idea of what the exact problem is before trying to modify the LTM configuration. You might try contacting billion to get details on the message. Here are a few related posts found searching for that log message:

     

     

    TCP FIN?

     

    http://www.dslreports.com/forum/remark,604069

     

     

    Google cache of a billion's forum post:

     

    http://209.85.229.132/search?q=cache:sbdNFyQ9nPMJ:au.billion.com/forums/index.php%3Fshowtopic%3D9643+Intrusion+TCP+FIN+scan%2817%29&cd=1&hl=en&ct=clnk&gl=uk

     

     

    If this is caused by the server (or LTM) sending a FIN after the connection has already been closed, you might consider disabling Loose Close on the FastL4 profile. This is a stab in the dark as I'm not sure what triggers the error.

     

     

    Aaron
  • Hey Guys,

     

     

    I have found some reference to something which may resolve this, however I can't find the information which is referred to. I found this snippet in the "BIG-IP® Reference Guide version 4.2":

     

     

     

    Finally, you can prevent a virtual server from sending a TCP reset

     

    when a connection is timed out. For more information, see the Virtual

     

    Servers section in Chapter 4, Configuring the High-Level Network.

     

     

     

     

    However, after reading Chapter 4 forwards, and backwards, I can't see anything referring to how to disable this. Does anyone know which setting this is referring to?

     

     

    Thanks