VPN passtrought for multiple Ipsec / L2TP clients to same host
-
Hello everybody,
I have a problem here on a pfsense 2.4 router : we are 3 road wariors here using laptops in a distant office from the mother company, and we are often on the move, so we have L2TP VPN access configured on each laptop in order to access the remote Zywall router in the main office.
Outside of the distant office, there is no problem, the zywall does manage multiple simultaneous L2TP client access. But as soon as we are into our distant office running a pfsense router, only the first of us that sets up his VPN link to the main office can connect. Subsequent connexions fail untill the first connexion states expire naturally, or by manually killing them through the pfsense UI.
So the VPNs are only passing through the pfsense, they are not initiated nor received in anyway by the pfsense. They should be properly routed like any kind of traffic. Prior to moving to the actual distant offices, we were using our ISP supplied box (a DSL + router combo), and the concurrent connexions were working flawlessly.
Apart setting up a site to site VPN, does anyone know a workaround for this situation, I mean making multiple concurrent L2TP ipsec links to the same host passing through concurrently ?
Or should I fill a bug report ?
Thanks for your feedback
-
While I have been stalling for days, I have made some progress on the issue tonight.
It seems the problem is related to the UDP sessions timeouts. Because I have some VOIP phones and their sessions were expiring, I had to set the firewall optimization options to "conservative", thus my UDP states were taking someting between 300 to 900 seconds to expire. And L2TP/Ipsec is UDP traffic as well, making me beleive that was a concurrent session problem.
Now that I have set the firewall optimization options back to "normal", and adjusted the specific timeout of udp states to a much shorter delay than "conservative", but longer delay than "normal", I am able to connect l2tp sessions much more frequently and sometimes concurrently. The wait penalty is still painfull though. And my phones seem to remain online so far.
I know the best option would be to shorten the SIP phones polling interval and let the UDP state delay to normal, but my VOIP provider has locked this control on the phones, so it is complicate.
An ideal solution would be to be able to tune the following properties inside firewall rules if there is a match : UDP First, UDP Single, UDP Multiple.
This way, it would be possible to increase the UDP state timeout only for the VOIP traffic, but I don't know if it is doable at low level.
There exists a state timeout setting in the advanced firewall rules GUI, but unfortunately it is for TCP only.