I got it working.

Not sure what was wrong. Went through everything in the guide again and all seems good :)

Great work, thank you 100x…

After enabling DPD it appears system is stable.

Lex

I have fixed the problem, but still I think it's strange why it didn't work.
What I did is I changed te subnets on pf2, I changed 192.168.41.0/24 to 192.168.140.0/24
and 192.168.71.0/24 to 192.168.170.0/24.
After that I did setup 2 tunnels on pf1 192.168.0.0/17 -> 192.168.128.0/17 and on pf2 192.168.128.0/17 -> 192.168.0.0/17
This works perfect, no outbound nat adjustment needed, every subnet is reachable without changing any thing else on the ipsec settings and firewall rules.(they were allready setup right)
In the old situation I had high pings and package loss (both pf's where connected with a cable of about 300meter) after the change ping was <1ms and no package loss anymore.

What could this be? Some bad routing?

No, I'm not confused. When the scheme DLink-ISP-pfSense ping time and on pfSense to DLink was 3-5ms, After replacing the DLink to ping pfSense vrmya risen. If you run the command ping 192.168.0.1-t (remote pfSense) then begins to 90ms, and then gradually (after 30 packets) is reduced to 3-5ms then abruptly jumps up to ~ 100ms. And so it is cyclic.

@root2020:

Do I need to setup an IPsec VPN for each iPad. What is the best way to set these up?

I don't think so. The tunnel should work with all your devices, Did you create a user for each of your devices? Maybe that's the problem since you have concurrent connections from the same user at the same time.

Hope it helps

Cheers!

hi, the tunnel is down few days ago. now i am back at our main site. no matter what i do, i could not bring the tunnel up. the error message is
racoon: [Abdn-Leeds]: INFO: IPsec-SA request for xx.xx.xx.xx queued due to no phase1 found.
Mar 26 14:49:53 racoon: ERROR: phase1 negotiation failed due to time up. 88b57bff254ae040:0000000000000000
Mar 26 14:49:36 racoon: INFO: delete phase 2 handler.
Mar 26 14:49:36 racoon: [Abdn-Leeds]: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP xx.xx.xx.xx[0]->yy.yy.yy.yy[0]
Mar 26 14:49:02 racoon: INFO: begin Aggressive mode.
Mar 26 14:49:02 racoon: [Abdn-Leeds]: INFO: initiate new phase 1 negotiation: yy.yy.yy.yy[500]<=>xx.xx.xx.xx[500]
where xx is branch IP and yy is main site IP. any help would be appreciated. thanks

did you sort this?
I was having the same issue as well.  I changed from sha-1 to MD5 and then everything worked.

Was just wondering whether you guys had it working with sha-1.

What is your tunnel config settings?

I did wonder whether it's to do with the crypto card in the pfsense(watchguard) not working as expected…  ???

Thank you for your reply!

So is there a possibility at all to have an IPSec Tunnel handle a failover from DSL to UMTS in pfSense?
At the moment it seems to me that you need two tunnels anyways, one for the DSL connection and one for the UMTS connection, but they would both need to terminate on the datacenter pfSense.
But then, as soon as two tunnels are supposed to terminate on the same remote wan IP, it won't work, no?
So it would be necessary to have at least two WAN ips on the datacenter pfSense?  ???

Isn't there a more elegant solution to handle a WAN failover in the office site - including the IPSec VPN that also can follow the failover?

Thanks!

Ok - thanks for the information.  I'm newish to L2TP/IPSec, but I think I understand what pfSense supports now and what it doesn't.

Awesome.

Thanks!

Probably because you're not really using L2TP, but L2TP+IPsec, and IPsec does static port outbound for udp/500, so the second client to try will probably fail.

If the server doesn't mind a random source port, switch to manual outbound NAT and remove the static port rules for isakmp.

You'll hit some kernel memory limits at some point but not sure what that point is (no one has ever gotten that high), into thousands for sure and maybe much higher.

Yep. It may be worth a feature request in redmine to look into adding support for those to the GUI at some point though. Now that they are actually RFC compliant it may be useful to some people.