I am currently travelling and cannot really simulate a test scenario. For that reason I would like to contact the author of the SIP conntrack module and see if we can work out something together. This is not really an issue with IPFire, but rather a problem in the Linux kernel.
Conntrack unreplied registration#
However I agree that SIP registration is still an issue with IPFire. In the end there would be no point in having SIP connection tracking any more. Hence I not think that we should flush the connection tracking table when a VPN goes up or down. It is not that there is a public IP address that changes. I guess that the solution is probably not a good one because this must be a different problem: The addresses remain the same. I have been thinking about whether this is a good idea or not. I was hoping that a solution similar to the one implemented in Core 82 for SIP could be implemented for IPSec as well. Forcing the phone to stop registering until the connection tracking entry expires will also work, but so long as the phone continues to attempt to register, the invalid entry seems to remain and the phone will continue to be unable to register. After the fix for SIP clients introduced in Core 82, I was able to narrow this problem down to a connection tracking issue, whereby an invalid entry is established while the tunnel is down and is retained even after the tunnel is back up.įorcing the phone to a new IP Address of deleting the offendingĬonnection tracking entry will immediately allow the phone to re-register. Basically, since we began using Endian, and then IPFire, we have had issues with SIP clients refusing to register across an IPSec tunnel after that tunnel drops.
0 kommentar(er)
