[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT state not deleted after IP change (DHCP)

On Tue, Feb 08, 2005 at 08:20:26AM +0100, Cyrill Rüttimann wrote:
> The SIP-Phone sends every 25s (default) a keep alive message to the SIP-Proxy 
> to remain the state on the NAT'ed Firewall. So I have to lower the 
> udp.timeout to be less than 25s to get rid of the state, which results that 
> the SIP-Phone has to register against the SIP-Proxy every 25 seconds?!
It depends. If you timeout UDP states after <25s idle, the next
subsequent outgoing keep-alive message from your phone will create a new
state entry. Unless you force a fixed source port (either with
'static-port' or using a proxy port selection in the nat rule), the new
state will use a random proxy port different from the previous one, and
it's likely that the peer will not associate this packet with the previous
flow of packets, and require another protocol-level registration.
If you force a constant proxy port to be used for all such connections,
neither peer will not notice that you removed and re-created state entries.
With one little catch: during the time when there is no state entry
(after the previous state has been removed and before the next one is
created), the external peer will not be able to send your phone any UDP
packets (assuming you create state on outgoing packets from the phone
only). I don't know the SIP protocol, but it's possible that the peer
might want to send the phone a packet without being actively queried by
the phone first (like, when there's a call to pick up or such).
> So in my opinion, PF has to empty the state table if the public IP changes! 
> Not true?
That might be fine in your simple case where all states depend on the
changing address. But imagine only some of your state entries do. For
instance, you might have a state entry for an SSH connection from a
local workstation to the firewall on the internal interface. Surely, you
wouldn't want to reset that connection just because the external
interface changes addresses, which is completely irrelevant to your
local SSH connection?
In general, you might have multiple interfaces you create state on,
using multiple rules of which some do and some don't use dynamic
interface address translation.
Also, not all address changes need to purge all states that dynamically
translated to the old address. For instance, you might have
  nat on $ext_if from 10/8 to any -> ($ext_if:network)
and a state picked one particular address from that block. Now $ext_if
changes address, but the old and new address block overlap and the
particular address of the state is part of both the old and new block.
No need to purge that state.
This might seem like a rare special case to you, but there are many
people using address pools in a more complex fashion than just 'a single
external interface, a single nat rule, with a single replacement
I guess the proper definition of what states to purge on address changes
is this: "purge all existing states that were created based on
nat and filter rules using dynamic interface address translation, and
which couldn't be created by those rules after the address change".
I agree that makes sense, but it's nowhere near as simple as "empty the
state table if the public IP changes". If it's as simple in your
specific case, it would be possible to run pfctl -Fs from a cronjob that
detects address changes through ifconfig output comparison.