The option to control the behaviour as a responder only will be on 2.2.1

@Derelict: @NinjaActionJeans: Doesn't look like I can add another phase 2 to the remote device. Primary reason I'm replacing Cisco RV042s with pfSense.  That and a lack of OpenVPN.  Good luck. 10.0.0.0/8 worked thx!!

For radius settings you need to restart ipsec service after configuration.

From the looks of that, whatever is doing the NAT is dropping fragmented traffic. Where you see it leaving one end, and not showing up at the other end, something in between is stopping it from passing.

@Clouseau: 10:52:02.472533 00:10:be:0c:85:47 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.139 tell 10.0.0.113, length 46 10:52:03.471592 00:10:be:0c:85:47 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.139 tell 10.0.0.113, length 46 There you go, your subnet mask is wrong on 10.0.0.113. It should never ARP a remote device.

@Thale: Would "Restart Service" work, or does a "full stop/start" refer to an actual stop followed by a start? Stop it, then start it. A restart in some cases apparently doesn't apply all the config file changes that were made in some circumstance(s) I haven't fully quantified yet.

@doktornotor: No, absolutely not without posting relevant logs. This. Post your IPsec logs from both sides. There is no possible way to suggest what to do without having logs of why it's failing.

Can you share the generated config on /var/etc/ipsec/ipsec.conf and the /var/etc/ipsec/racoon.conf from machines?

Yeah that means that something i\might be sending ip ids that are similar. Usually that is problem on client side since that breaks fragmentation and not only.

It clearly states in 1st post what is the problem.

There's still an open ticket to address that, it got pushed to 2.2.1.

To come back to the problem, if the tunnel is up but no traffic is coming through, can you further specify it? Is there only some traffic (like small ping packets) that get through or is it nothing at all. Because I experience a problem where fragmented packets get lost. https://forum.pfsense.org/index.php?topic=87610.0 Maybe you want to perform similar analysis to confirm that your current problem is similar or not.

Just an update:  Today I have the following log entries and SEVERAL entries in the SAD table. Jan 28 08:24:04 racoon: INFO: unsupported PF_KEY message REGISTER Jan 28 08:23:29 racoon: [Roseville2Longview]: [206.x.x.x] ERROR: notification 32768 received in informational exchange. Any thoughts are welcome.  Just a thought; if, on the remote firewall, the key expiration is set to 24 hours AND zero kilobytes, will the key constantly be regenerated?  I have always thought not, but…

In my case all ends are Pfsense 2.2 This was not happening when we had 2.1x

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.