Same here, after i followed instructions in https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes all is back to normal.

Did you change the Sonicwall too or is its config still the same?

Logs from both ends would be good to see.

And also add a firewall rule that allows traffic through that VPN interface.  So 3 things that need to be done on a Fortigate:

VPN
Routes
FW rules

Just want to add that this can also mean the shared secret does not match.  I just ran into this error recently.  The remote end (Checkpoint) revealed in the logs that it could be a shared secret mismatch.  Sure enough it was off on one character.  The pfsense side was initiating the connection.

@cmb:

Depends on what services you're using as to whether that route is required. For DNS, the DNS forwarder's domain overrides allow specifying a source IP, which negates the need for that route. Any service that lets you choose a source IP will work if you bind it to LAN.

That really shouldn't break SLES, that should probably be reported there as a bug. Should be able to disable acceptance of ICMP redirects on the SLES host to work around it.

Thanks for your reply.

As I said, the services I absolutely need to work from pfsense through the tunnel are DNS resolution (not a forwarder, but pfsense itself needs to be able to resolve names, and the name server it needs to talk to is behind the tunnel), and NTP (the NTP server pfSense needs to use to sync it's won time is also behind the tunnel.

As for reportign the SLES behaviour as a bug: No chance in hell this would ever be accepted as such. And I highly doubt it's a SLES specific issue at all. They don't touch the tcp/ip stack. Disabling redirect acceptance unforunately isn't possible here either, it's needed.

Thanks again.

There is also a tutorial here
https://doc.pfsense.org/index.php/L2TP/IPsec

and on of the ongoing discussions is here

The blog posts are the official announcements and included a note about that issue.

It was not listed in the upgrade guide, so I corrected that:
https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes

@MrMoo:

As a quirk you can provide a hostname which resolves to IPv6 and configure for IPv4 tunneling without the complaints.

Worse yet, I've had a v4 tunnel try (and fail, of course) to use a v6 address for a hostname that resolves for both.

I was able to fix this by enclosing the ASN.1 DN values with double quotes (").

I have added Bug #4275

After reading up more on the subject, I discovered that apparently the combination of PSK and main mode is not possible with dynamic IP's.
I have switched to certificate-based authentication now, and the tunnel did come up fine!
(And I'm even more secure now :) )

Thanks
Michel

https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29

I have two PfSense box connected to fortigate in IPSec without problem.
(Different proposal used)

Do you need help ?

Regards,
Secf'

O o o…. Would this work ?

Using just one site as an example
If I extend the local subnet range of IPSEC5/Phase2NAT to include the NAT'd range of IPSEC2/Phase2NAT whilst making an additional tunnel for the remote site.

Something like...

RemoteOffice1 <=IPSEC1=> HQ <=IPSEC5/Phase2NAT=> ExternalService
RemoteOffice1 <=IPSEC2/Phase2NAT=> HQ <=IPSEC5/Phase2NAT=> ExternalService

Thanks

It will be on the next versions for sure on 2.3

Thanks a lot,
It works fine

Hakim