Sip invite packets dropped after random time(fixed by reboot of pfsense)
-
Can you post output of the next when you do not have problem and when you do```
pfctl -ss | grep 5060 -
I had the same filters exactly when it did work and when it did not work. I have a quick rule that I add and delete to bounce the firewall to fix the issue.
-
The reason I asked about filter: when troubleshoot things like this capture everything (even if it is quite a traffic) then when you open the file apply necessary filter rules if needed - this way you can see events that might indirectly affect SIP traffic, for example packets go through but nat does not happen properly or carp switches or … Even if examples look silly to you trust me very often capturing all traffic helps understand what is really going on.
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 -ssit's up to you whether you take this way or not -)
Cheers! -
Forgot to ask - is there a reason you use CARP IP to terminate SIP traffic? I do not see many interfaces…
-
There is no particular reason I am using carp ip.
I will make the captures you asked for the next time I see the issue.
-
Is there a way to capture from both lan and wan from the command line on the pfsense router itself?
-
You can capture on both by having two open ssh sessions and doing one capture on each interface in each session.
-
You can capture on both by having two open ssh sessions and doing one capture on each interface in each session.
… or running something like
tcpdump -ni <lan> -s0 -w lan.cap & tcpdump -ni <wan> -s0 -w wan.cap</wan></lan>After you are done don't forget to kill the first session.
-
That works too, but I've found that separate windows makes it a bit easier logically to follow what's being done.
Also, you could use "fg" to get back to the backgrounded tcpdump in your example and then ^C it, rather than finding and killing the process.
-
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 -ssYou 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.
