seems so, i have the same issue. the patch posted above cannot be applied. i have multiple p2 configured lan, wlan, dmz. i can only access lan subnet. and i have no idea why. i don't even know if my problem is related to this topic.

I have done it like below (full testing was not possible) and it seems to work: http://zee.linxsol.com/system-administration/pfsense-2-site-to-site-vpn-with-dell-sonicwall-nsa-3500.html I have put in some additional rules on the WAN Interface, see screenshot. [image: Rules_IPSEC.JPG] [image: Rules_IPSEC.JPG_thumb]

I did think that if it worked it would break all routing. It was a long shot, as i thought each interface would have it's own routing table, so i could have 192.168.1.0 <<ipsec a="" nailed="" to="">> 123.123.123.120 <<lan to="">> 10.0.0.0 <<routing rule="" for="" outbound="" ipsec="" a="">> 192.168.1.0 <<ipsec b="" nailed="" to="">> 123.123.123.121 <<lan to="">> 10.0.1.0 <<routing rule="" for="" outbound="" ipsec="" b="">> 192.168.1.0 <<ipsec c="" nailed="" to="">> 123.123.123.122 <<lan to="">> 10.0.2.0 <<routing rule="" for="" outbound="" ipsec="" c="">> All on one pfsense firewall with each</routing></lan></ipsec></routing></lan></ipsec></routing></lan></ipsec>

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.

Yea working a treat thanks dude. I was missing the static routes and the Framed-Route = "0.0.0.0/0 172.16.0.1 1" I've split my 172.16.9.0/24 into 2 /25s blocks the first /25 has full access everywhere the second /25 internet only.

Nothing special about them, just adding another host or network to the tunnel.  I haven't stopped and started the IPSEC service, just used the icon that shows restart service.  We'll try that. This config has been running around 7 years and this behavior started around 2 years ago.

The issue was down to a bug with the modem from our ISP fragmenting packets. New ISP, problem solved!

So I'm the dummy, as expected. Setting is found in the VPN adapter on the Windows side: VPN Adapter Properties –> Networking --> Select TCP/IPv4 Properties --> Advanced --> Uncheck "Use default gateway on remote network" Hope this helps a few other dummies out there!

I can't fix this mismatch, any help?

Use check box in P1:  Enable this to split connection entries with multiple phase 2 configurations. Required for remote endpoints that support only a single traffic selector per child SA.

This is possible with both DrayTek and pfSense, however I assume by now you have resolved the issue!

push :X