| FVS318 TCP/UDP Timeout Values This is for an FVS318 V3 hardware with firmware 3.0.28 Under Advanced/Sessions are fields for TCP and UDP timeout values. The reference manual appears to not address these at all best I could find. The help text on the right side of the screen has:
Sessions Help
All open TCP and UDP sessions are stored in a connections table by the firewall. A TCP session is removed when it is actively closed by the local and remote hosts, or when it has been idle for a specified timeout period. A UDP session is removed after an idle timeout.
The default timeout periods are 600 seconds for TCP and 75 seconds for UDP, and the maximum setting is 2147483646 seconds. There is usually no need to change these timeouts unless you are having problems with application sessions dropping prematurely.
So, what I'm wondering, is if this only applies to connections made through NAT/PAT to the internet or also via tunnel to remote VPN peers? We're having some issues with clients communicating with MySQL to a remote server over tunnels managed by FVS318's. Trying to determine if the connection is timing out as a result of the router intentionally dropping the connection or not. We doubled the TCP timeout from 600 to 1200 and that appeared to help, even though we were fairly consistently getting a disconnect at around the 300 seconds point. Hard to be 100% certain it wasn't something else though, too many variables...
Thanks. |
|
| On the Netgear FVS336Gv2 the defaults are...
TCP Timeout: 1200 (Seconds)
UDP Timeout: 180 (Seconds)
ICMP Timeout: 8 (Seconds)
On Cisco ASA...
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
...just FYI. I'd be interested to hear other people thoughts on this as well. |
|
 GrimshawWhats This?
join:2002-12-23
England | reply to ArkiMage
The timeout values for TCP and UDP only applicable for connections being tracked by the firewall, such as those inside to outside or vice-versa. There is no filtering or traffic monitoring between ports on the internal interfaces on the FVS series routers. |
|
|
|
| said by Grimshaw:no filtering or traffic monitoring between ports on the internal interfaces on the FVS series routers.
...agreed, but since a VPN tunnel is usually a different subnet then the local subnet, and you can apply ACL's between these, the question still remains is VPN traffic subject to TCP/UDP/ICMP timeouts - my vote without having actually tested anything is still yes, yes it is. |
|
GrimshawWhats This?
join:2002-12-23
England | Hhmm, you could be right. They didn't update the manual after the timeout feature was added in the more recent firmware. A quick look on my own FVS338 doesn't make it any clearer. |
|
| reply to ArkiMage
Of course, we're now having an entirely different problem with this router. Or possibly it's related... It's locking up, no packet routing, not even pingable on the LAN side. We've replaced it with another of the same model and that hasn't helped. We enabled syslog logging and are seeing about ~1500 per hour connections similar to this:
Nov 9 11:14:06 router Wed, 2011-11-09 11:14:08 - TCP packet - Source: 172.20.9.2 - Destination: 68.142.250.160 - [Attempt to access URl: l.yimg.com Src 33479 Dst 80 from LAN]
Nov 9 11:14:06 router Wed, 2011-11-09 11:14:08 - TCP packet - Source: 172.20.9.2 - Destination: 68.142.250.161 - [Attempt to access URl: l2.yimg.com Src 57918 Dst 80 from LAN]
Nov 9 11:14:06 router Wed, 2011-11-09 11:14:08 - TCP packet - Source: 172.20.9.2 - Destination: 67.195.146.181 - [Attempt to access URl: ichart.finance.yahoo.com Src 33024 Dst 80 from LAN]
So, does anyone know roughly how many NAT/PAT connections a router of this class can easily handle? What's the threshold where it's really just not appropriate and a more powerful device is required?
Oh and I'm not sure if this really amplifies the problem, but we have some "Double NAT" happening as well. The FVS318 directly connects to the internet and has a single server and about 4 PCs connected to it. Also connected to it though is the WAN port of a small Linksys router that has probably a dozen PCs connected to it. So for ~1100/hour of those connection attempts, the double NAT. The Linksys is NATting the traffic from those PCs and it's all seen by the NetGear as a single IP, that of the WAN port of the Linksys. Is that exaggerating the problem do you think?
Thanks. |
|
GrimshawWhats This?
join:2002-12-23
England | I don't know how many connection the router can handle. The FVS318 is intended for small offices, so your 20 or so PC's should be ok, though of course the biggest factor will be all the concurrent connections from those PC's. If you've raised the timeout thresholds then you'll have more concurrent connections to track in the NAT table.
I don't know about the FVS318 but with the 338 you can get a packet dump (can be opened with wireshark) from the diagnostics page to see what's going on.
Also why the double NAT? The router should support multi-homing if that solves your particular requirement. |
|
| Heh, long story... Consider the two routers and subnets as logical department separators. Of sorts... Different vendors maintaining equipment for different groups...
Anyway the more we think about it, that is likely a problem. The dozen or so PCs behind the one router all get NATted and appear like a single IP to the NetGear. So from it's perspective that's a lot more traffic from a single IP than would seem typical. We've not done so yet but will probably try dropping the timeout values as you mentioned. Keeping track of a lot of open connections probably will become easier if it can purge them off quicker.
Thanks. |
|
| reply to ArkiMage
FVS318G
LAN-to-WAN: 25 Mbps total
IPsec VPN (3DES): 7 Mbps
Connections: 6,000 concurrent sessions
FVS336G
LAN-to-WAN: 60 Mbps total
IPsec VPN (3DES): 16 Mbps
SSL VPN: 10 Mbps
Connections: 10,000 concurrent sessions
FVS318N
LAN-to-WAN: 95 Mbps total
IPsec VPN (3DES): [unknown]
SSL VPN: [unknown]
Connections: 6,000 concurrent sessions
...I'd be leaning to double NAT as the problem before anything else, but consider...
All of the Netgear series I mention above have the same "bug" that if the WAN port is disconnected (no link) for even a fraction of a second, the whole device "gets strange" for about 2 minutes while it tries to "reinitialize" the WAN port and rebuild the routing table. While this is happening, the web-based GUI seems sluggishly slow, and takes forever to save a change. This is true even if the WAN interface is programmed with a static IP. Sometimes the only solution is to remove power, wait a few seconds, and plug it in again. I find this behavior odd, as other devices don't seem to have this problem - but other than this (which should be entirely avoidable) there great. Perhaps whatever you have this plugged into has a bad port or patch cable? |
|
