> On 07.02.2019, at 14:21, Stuart Henderson <s...@spacehopper.org> wrote:
> 
> On 2019-02-06, Patrick <jum...@yahoo.de> wrote:
>> My nat rule use the parenthesis and all other devices behind the
>> firewall works fine. I think it’s more a specific issue with the SPA112.
>> I have also set the ruleset optimization to conservative but in this
>> case the generated state has just a longer time to live. This isn’t the
>> problem because the SPA112 sends regular keep alive packets which reset
>> the counter for the state.
> 
> Setting to 'conservative' (i.e. hanging on to states for longer) can't
> help with this.
> 
> Using parentheses won't help either, that means "do a lookup at state
> creation time", but you aren't getting a new state created because the 
> old one hasn't expired.
> 
>> 
>> Here the related rules:
>> pass out quick on egress inet from (vether0:network) nat-to (egress) 
>> modulate state
>> pass in on egress inet proto udp from <sipprovider> to (egress) port 5060
>> 
>> As I’m just reading again my rules. Is the modulate state the problem?
>> Or will pf use keep state for UDP packets as the default?
> 
> PF uses "keep state" by default, and "keep state" is required for NAT.
> 
> I think your main options are:
> 
> - use a *shorter* timeout for this rule (this can be set per-rule
> and overrides the default from "set optimization") and have a port
> forward rule so that incoming packets still work even when the
> state has timed out
> 
> - arrange a way to flush these states when the IP changes
> 
> The first of these is probably easiest if you can do it ..
> 
> 

Thanks for suggestions. I tried to change the timeouts but every time the state 
gets deleted the SIP server refused the new connection. I think because of the 
change of source port. Maybe it would work with static-port option. I choose 
option two and have created a cron job to reconnect my VDSL connection and 
flush the state table at 2am in the night. This moved the force termination 
after 24 hours to the night. I remember that the old firewall had a similar 
option and probably also deleted the state table at the same time. I didn’t 
noticed the disconnection of my SPA112 in the middle of the night. To recover 
quicker from a termination at day I have set the re-register timeout to 30 
minutes and also runs a script every five minutes on the firewall to check the 
current public IPv4 address and the one in the state table for the SPA112 and 
if it not match delete the state.

Best Regards,
Patrick


Reply via email to