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

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



Hi Daniel,

Thanks for the answer and insights to the lower levels of the networked world. I have now hopefully solved my problem. I can see in the state table, that the state expires and after a few seconds, the state is recreated again (heartbeat 25s, timeout 20s):

# voip
nat on $ext_if from <sipphones> to any -> ($ext_if) static-port
pass out quick on $ext_if inet proto {udp} from ($ext_if) to any port sip keep state (udp.first 20, udp.single 20, udp.multiple 20)




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).

- after sucessfully registering, the client (phone) sends a keep alive heartbeat to the sip-proxy. No packet is sent back from the sip-proxy.


- there is a reregistration every x seconds

- if someone calls me, packets are sent (only udp) from the sip-proxy to my phone (that is why the sip-protocol is not well suite to handle firewalls (specially NAT). They have to handle out the port to send RTP packages.

That problem keeped me busy for a too long time.

For those who are interested, we will roll out (now in production test) soon a Firewall based on OpenBSD/AMD64 and pf to load balance traffic to our SIP-Proxies. We started with the Soekris Net4801. But load tests pointed out, that the 3 network interfaces are sitting on the same IRQ. The CPU was nearly only handling interrupts and the solution was capable to filter about 20-25 phone calls at the same time (not the promises 20Mbit/s). A phone call produces a lot of traffic (depending on the interval sending RTP-Packages). We now have switched to a cluster (CARP) of HP DL145's with AMD's Opteron CPU :-)

Regards,

Cyrill