You are hereSonicwall and Sonicpoint Keep Killing My TCP Connections to Databases

Sonicwall and Sonicpoint Keep Killing My TCP Connections to Databases

By steve - Posted on 07 August 2012

I have a client that upgraded, due to some other issues, to a Sonicpoint wireless access point that directly connects to their Sonicwall firewall.

This solved a lot of problems, but one of the problems that lingered was that their database connections would get cut off at seemingly random times.

It wasn't one application, either. It was their connection to a postgresql database and a different program connecting to a Filemaker (Pro) server.

It took some real "sitting down" diagnostics to test this. Here's how I solved it...

  1. I set up a duplicate system that was the same as one of the systems that were having problems and connected up with the wireless network.
  2. I started the application that was dropping the database connection to postgresql.
  3. I jotted down the start time to the nearest minute.
  4. After 1 minute I was OK and the connection worked, so I waited 2 minutes from that point.
  5. I repeated this until I found I would consistently lose the connection after around 5 minutes. After 3 or 4 tries, it became clear the magic number was 5 minutes.
  6. I went into the Sonicwall and found a couple of timeout settings that were set to 5 minutes!
  7. Under Firewall Settings, Flood Protection, TCP Settings, Default TCP Connection Timeout (minutes), it was set to 5 minutes. I tested that being changed to 1440, but nothing improved. I did more research and it turns out this is the default setting for new rules. All existing firewall rules keep their settings. I set it back to 5 minutes.
  8. Note: when changing the firewall rules, the changes are immediate and you don't need to reboot the firewall!
  9. Under Firewall, Access Rules, WLAN, I found the WLAN rules for the Sonicpoint bridge that I had set up. I had two rules there (a subnet rule that was auto-added and an Any rule that I think I added). I opened the configuration and sure enough, under the Advanced tab there was the TCP Connection Inactivity Timeout (minutes) setting and it was set to 5. I changed it to 1440 to allow 24 hours of inactivity on the wireless. I did this for all the rules there.
  10. I was disappointed after 6 minutes when I found out the connection timed out, but I was still sure I was on the right track.
  11. I kept sniffing around and, sure enough, under the LAN section another auto-added rule was there for the LAN->WLAN side of things. A few more clicks and I could see it was set to 5 minutes as well. A quick flick to 1440 and I tested again.
  12. This time, JOY!
  13. I waited 20 minutes, then an hour after that and each time my connections stayed up!
  14. So far, this has seemed to solve the issue and we are no longer losing database connections that don't have traffic!
  15. The keys to solving this was finding the 5 minute drop and finding ALL the rules that affected the drop. The users reported "random" drops, but that was because they would come back from 5 to 30 minutes later and it wouldn't work anymore. Finding the WLAN->LAN rules was needed, but the clincher was finding the corresponding rule for LAN->WLAN.

Did this help you? You can help me!

Did you find this information helpful? You can help me back by linking to this page, purchasing from my sponsors, or posting a comment!

+One me on Google:

Follow me on twitter:


Affiliation Badges