Bug #1636
closedoutbound state timeout control not possible?
0%
Description
it does not appear to be possible to control the timeout on an outgoing NAT connection.
you can control the setting for inbound connections by adding a firewall rule to match the connection, then under 'advanced settings' adding a state timeout (broken for UDP, see bug #1635), HOWEVER, each 'connection' through a NAT seems to have two states, one for the incoming packets arriving from the LAN (and the timeout can be controlled), and another state generated as the packet leaves the WAN interface via NAT rules (which cannot be controlled).
my example is a SIP phone. being a dumb phone (and a dumb provider), they set the registration timeout at one hour, and don't send keepalive messages. the result is that after a few minutes the NAT rule drops and the phone is no longer 'registered'. changing the firewall setting to 'conservative' boosts the timeout to 15 minutes by forcing the udp.multiple timeout globally to 900 (which has other side effects), but is still too short a timeout.
the outbound rules creating the states which can't be controlled are these:
pass out all keep state allow-opts label "let out anything from firewall host itself"
pass out route-to ( igb1 66.x.x.x ) from 66.x.x.x to !66.x.x.x/29 keep state allow-opts label "let out anything from firewall host itself"
these seem to be pretty much hard coded. what would be ideal would be if a timeout could be set on a NAT rule, and it would then in addition to the NAT rule itself, also generate a 'pass out' rule with the timeout specified, eg:
nat on $WAN proto udp from 10.y.y.0/24 any to any port 5060 -> 66.x.x.x/32 port 1024:65535
pass out proto udp from 10.y.y.0/24 any to any port 5060 keep state ( tcp.established 7200, udp.multiple 7200 ) allow-opts label "increased timeout for SIP"
a related point: it is typical for SIP ALGs built into consumer routers, sip_conntrack in Linux etc, to automatically boost the NAT timeout of SIP connections for this exact reason.
Updated by Chris Buechler over 13 years ago
- Status changed from New to Rejected
NAT states have the same timeout as the filter state and there isn't any scenario where doing otherwise would be a good idea
Updated by Adam Gundy over 13 years ago
huh? which filter state?
I agree that you shouldn't have to set the timeout in two different places, but currently there ARE two places that create states for the same connection - inbound on LAN, which can be caught with a firewall rule and the timeout set (once the UDP bug is fixed), and outbound on WAN, which CANNOT be caught or adjusted, because there doesn't seem to be any way to create 'outbound' firewall rules.
I've tested this and examined the states for a live SIP connection. with an LAN firewall rule forcing a timeout of 7200 for port 5060, one state (LAN) has a two hour timeout, the other (WAN, NAT) has a 15 minute timeout (conservative setting). the result is the connection is basically dropped after 15 minutes.
Updated by Peter Brauner over 13 years ago
I too agree with Adam. I have this problem all the time with my SIP connection. It keeps dropping. Have not timed it but I guess 15 minutes is about right. I have set everything by the book as well.
Where do I set the timeout for states, weither it is NAT or filter?
Updated by Chris Buechler over 13 years ago
this isn't the place to ask questions, please post to the forum or mailing list.