Sip invite packets dropped after random time(fixed by reboot of pfsense)
-
Alright, I have been able to capture the issue. I am working on getting the info ready.
-
Alright, I have been able to capture the issue. I am working on getting the info ready.
I am sorry, this is what I asked some time ago:
@Evgeny:So, to troubleshoot further I'd like to have two things
1. all packets captures from LAN and WAN for 2 minutes when it is not working + output of```
pfctl -sr
pfctl -sn
pfpfctl -ss2\. Add/delete a rule to fix the problem and again: all packets captures from LAN and WAN for 2 minutes when it is working + output of``` pfctl -sr pfctl -sn pfpfctl -ss
You gave me just two captures from WAN interface (no captures from LAN) 15 minutes apart from each other. It is impossible to say anything here except that you are using CARP and probably at that moment there was a problem with Active node (switchover did not occur or whatever) -(
Can you provide full details (see above) and plusifconfig
-
After much digging it seems that the problem exists because pfsense now overwrites the outgoing source port for sip traffic. The problem exists when pfsense assigns a new outgoing source port to an existing connection, but before the sip device has reregistered with the remote server. This causes all sip traffic to be sent not to the new udp port, but to the old one. This is only the case when using 'rport' so that the remote sip server sends the traffic to the sip source port rather than to the sip port specified in the registration packet. Using rport only checks for the port at registration time, so any changes between registrations will cause new calls to fail.
Where is some information about how long the sip source port is assigned to a udp session?
-
Do not rely on state timeout. As I advised in e-mail use Static port in NAT->outbound, this way you will be sure SIP packets that leave your WAN interface always have source port 5060 and even if the state expires remote end 'knows' that it has to communicate with you using port 506 and you have inbound NAT->port forward + rules for this port. So, should work.