I tried it exactly as I guessed (and derelict too) and it worked.

Thank you for your help!

With L2TP, it's completely up to the client to decide what traffic to send across. You need to configure the routes you want in the client itself.

@konstanti

So... I replaced the SG-3100 with an XG-7100 today, setting up that side (site2) from scratch, and it now works as expected. IPsec tunnel speed is decent and no more packet loss. I can't see that I did anything differently, but I don't really have the time to look into it right now, if ever.

Anyhow, thanks, again, for your time and input.

Many thanks

I figured out why my setup wasn't working. I had created Firewall rules under IPSec that allowed specific networks to connect to other specific networks. Once I created wildcard rules (anyone can talk to anyone on this interface), the IPSec tunnels started talking to each other and I was able to get FRR configured. Quagga OSPF wasn't working for me so I tried FRR and it worked fine.

OK, the solution is that in the failover security group, in the "Interface Address" field, I had to specify the VIP address. When I did this, then the right IP was showed in the config file.

Hi,
the problem was solved by modifying, in phase 2, the protocol and Auth Methods as the one configured on pfsense were not compatible with those used on the fortigate.
Thanks.

IPsec requires:

UDP 500
UDP 4500
Protocol ESP

You might or might not need protocol ESP based on NAT Traversal.

Probably just want to post your NAT settings and WAN rules.

Hi guys,

Thank you for the provided information. As I have had a very busy week with training and courses I was not able to do some in depth tests yet.

I did some quick and dirty testing with the information in these last 2 posts provided by you. I've tried various settings and combinations but all seem to fail.

I think the problem is somewhere in the Apple Configurator profile, as everything is working very well on my W10 machine. I have also tried on a Macbook but was also unable to connect. I will provide a more detailed log later when I have some more time at home.

Only thing what seems to be different in my setup is that I'm not using a self-signed certificate from a pfSense CA. There I was thinking it was not necesarry to add this certificate into the Apple Configurator profile. I'm using a Let's Encrypt wildcard certificate on my setup -> ACME installation in pfSense with auto-renewal, etc.. So I was thinking, like on my W10 it should work out of the box. However I did some quick tests with the settings provided by you guys (Machine Authentication, Server Certificate Issues Common Name, Server Certificate Common Name, etc..) but all with the same result.

Anyway I justed wanted to let you know I'm not inactive but currently have no time to perform further troubleshooting. I will update this topic further this weekend with more screenshots and error logs.

Thanks!

If both sides support VTI I would suggest that over GRE.

https://www.youtube.com/watch?v=AKMZ9rNQx7Y

@harow Thanks for your suggestions on this. The problem hasn't occurred in the past two weeks, after I changed the P1 configuration from Initiator or Responder to Respnder Only.

As far as I know MSS Clamping is a workaround to avoid MTU discovery problems. I assumed that you have some filtering in the source-destination path (ICMP was my first thought) that prevent MTU discovery.

Since throughtput was assymetric, I expected it to be fairly easy to find what was different and causing the issue at one end.

thanks for the update and great looking script! :)

I had disabled PFS on both sides and had the VPN running ok but it appeared to stop passing traffic when the P2 timeout expired after 3600 seconds.

By adding the rekey @ 540 seconds before expiry I 'think' its now stable.

I run approx 25 VPN tunnels from two sites to remote sites and Ive replaced a remote pfsense box with a USG device at one remote site.

From one main site ive had 100% uptime 19 hours to the USG
Strangely the other main has had drops during the same period - 5,56,45 minutes breaks

same IPSEC configuration
(all other IPSECs from that site were ok)

Both main sites pfsense 2.4.3

@derelict from the firewall fortigate in the capture I see the traffic coming out, but this does not reach the pfsense making the capture by ipsec

Origin -> fortigate
192.168.0.0/24
destination -> pfsense
172.16.100.0/27

Something additional currently from that fortigate I have another vpn with another pfsense and it is established without problems these two vpn have the same configuration parameters.

0_1550595464289_f8e30d6a-fb99-42f3-a31e-466357195f26-image.png

As long as it's IKEv2 it should be able to carry mixed traffic in the phase 2 / child SA.

I think the way to go is :

Created routed IPSec with VTI Implemented some kind of dynamic routing, with BGP or OSPF, assigning different metrics to your path.

Videos on theses subjects
https://www.youtube.com/watch?v=AKMZ9rNQx7Y
https://www.youtube.com/watch?v=4IlKcB17rWk

So for people who are facing the same issues.

You need both a route on the pfsense (you must be able to see it with netstat -rn)
And then, according to your firewall policy rules :

if you use the default gateway (*) in your rules : OK if you use a specific gateway or a gateway group : assign a new rule throught the ipsec gateway

I think the documentation should mentionned it. I'm not a native english speaker and after reading the doc, I thought, either static routes OR policy rules should work. But it's not an OR, it's an AND :)

Regards