I am having the same issue as well, is there anyway to find out why are these errors are showing up ? I have some difficulty connecting my phone to a SIP registrar server over VPN . sometimes it registers and others it says request time out !

Is there any way to make that service restart on every hour ?

I would suspect firewall rules above anything else. If it were a problem in IPsec, it wouldn't work in either direction.

Or perhaps this?
http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

I have solved the issue, from the log it seems there is some files missing after I have restored the configuration to Pfsense.

In one of the forums i noticed that this issue might be caused if you have installed FreeRadius2 package however I had it installed but I uninstalled it.

Now I re-installed the package and I could normally start the IPSEC/Racoon service Normally.

Here's the failing log:

Aug 29 14:29:07 php: /status_services.php: Forcefully reloading IPsec racoon daemon
Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -FP' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"'
Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -F' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"'
Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/racoon -d -v -f /var/etc/racoon.conf' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"'
Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -f /var/etc/spd.conf' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"'

Here's after I installed Freeradius2

Aug 29 14:40:43 php: /vpn_ipsec_phase2.php: Could not determine VPN endpoint for ''
Aug 29 14:40:43 check_reload_status: Syncing firewall
Aug 29 14:40:53 php: /vpn_ipsec.php: Could not determine VPN endpoint for ''
Aug 29 14:40:53 check_reload_status: Reloading filter

or even a roadwarrior with x509 would be great. Thats a shame.

pfSense doesn't NAT traffic sent over IPsec.

(in fact it couldn't NAT before IPsec even if you wanted to, due to limitations of the underlying FreeBSD/pf software)

No, PPTP isn't capable (yet) in our GUI of acting like a site-to-site VPN.

Aye, I'm getting to used to Windows here..

Anyways, I think we figured it out. We had the two systems on the same network segment. And.. I used the same vhid and carp passwords for both. Once we moved them behind another router on another network, it's been working fine. This also solved our seemingly random flip-flopping of our main pfsense boxes. I guess that's why you shouldn't have multiple vip's in the same carp group on the same network.

I was able to get it setup as a manual fail over and it works awesome.  Pulled 8MB/Second(what windows sees) through the VPN tunnel through the internet, private extended Lan only hit 1MB/Second.

Try setting the "automatically ping host" setting in the pfSense box to a client on the other side of the tunnel.  I was having a similar issue and this kept the tunnel alive.

Only changes were to the GUI to add some additional options for hashes and such, nothing that would have hurt/helped an existing config.

What does your /var/etc/racoon.conf look like on both sides? and also /var/etc/spd.conf

MTU problems maybe?

You can try the "MSS clamping on VPN traffic" option on site A.

Otherwise, do packet capture on the WAN while testing the port forwarding way and a pcap on the IPSec interface when testing iperf through the tunnel. You should see what's happening

resolved, for some reason someone created a routing table to the pfsense side on the watchguard firewall without letting me know, so as soon I removed it, all traffic worked fine both ways :)

Hello,

My probleme is resolved.
I was not with /24 on my RV082.

Alex.

I cleared my log and turned on debuggings this was my output from the service restarting.  Is something not working right?  Im not sure why its using a CIDR of /32 since my network is /24.  This is really confusing me.  Thanks for the help.

Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy already exists. anyway replace it: 172.30.1.0/24[0] 172.30.1.5/32[0] proto=any dir=in Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x80163a610: 172.30.1.0/24[0] 172.30.1.5/32[0] proto=any dir=in Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0x7fffffffe590: 172.30.1.0/24[0] 172.30.1.5/32[0] proto=any dir=in Aug 14 11:50:10 racoon: DEBUG: got pfkey X_SPDADD message Aug 14 11:50:10 racoon: DEBUG: pk_recv: retry[0] recv() Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: ERROR: such policy already exists. anyway replace it: 172.30.1.5/32[0] 172.30.1.0/24[0] proto=any dir=out Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x80163a790: 172.30.1.5/32[0] 172.30.1.0/24[0] proto=any dir=out Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0x7fffffffe590: 172.30.1.5/32[0] 172.30.1.0/24[0] proto=any dir=out Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x80163a610: 172.30.1.0/24[0] 172.30.1.5/32[0] proto=any dir=in Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0x7fffffffe590: 172.30.1.5/32[0] 172.30.1.0/24[0] proto=any dir=out Aug 14 11:50:10 racoon: DEBUG: got pfkey X_SPDADD message Aug 14 11:50:10 racoon: DEBUG: pk_recv: retry[0] recv() Aug 14 11:50:10 racoon: INFO: unsupported PF_KEY message REGISTER Aug 14 11:50:10 racoon: DEBUG: got pfkey REGISTER message Aug 14 11:50:10 racoon: DEBUG: pk_recv: retry[0] recv() Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x80163a610: 172.30.1.0/24[0] 172.30.1.5/32[0] proto=any dir=in Aug 14 11:50:10 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0x7fffffffe590: 172.30.1.5/32[0] 172.30.1.0/24[0] proto=any dir=out Aug 14 11:50:10 racoon: DEBUG: got pfkey X_SPDDUMP message Aug 14 11:50:10 racoon: DEBUG: pk_recv: retry[0] recv() Aug 14 11:50:10 racoon: DEBUG: got pfkey X_SPDDUMP message Aug 14 11:50:10 racoon: DEBUG: pk_recv: retry[0] recv() Aug 14 11:50:10 racoon: [Self]: INFO: 24.255.255.198[500] used as isakmp port (fd=15) Aug 14 11:50:10 racoon: [Self]: INFO: 24.255.255.198[500] used for NAT-T Aug 14 11:50:10 racoon: [Self]: INFO: 24.255.255.198[4500] used as isakmp port (fd=14) Aug 14 11:50:10 racoon: [Self]: INFO: 24.255.255.198[4500] used for NAT-T Aug 14 11:50:10 racoon: DEBUG: open /var/db/racoon/racoon.sock as racoon management. Aug 14 11:50:10 racoon: DEBUG: getsainfo params: loc='ANONYMOUS' rmt='ANONYMOUS' peer='NULL' client='NULL' id=1 Aug 14 11:50:10 racoon: DEBUG: no check of compression algorithm; not supported in sadb message. Aug 14 11:50:10 racoon: DEBUG: hmac(modp1024) Aug 14 11:50:10 racoon: INFO: Resize address pool from 0 to 253 Aug 14 11:50:10 racoon: DEBUG: reading config file /var/etc/racoon.conf Aug 14 11:50:10 racoon: DEBUG: call pfkey_send_register for IPCOMP Aug 14 11:50:10 racoon: DEBUG: call pfkey_send_register for ESP Aug 14 11:50:10 racoon: DEBUG: call pfkey_send_register for AH Aug 14 11:50:10 racoon: INFO: Reading configuration from "/var/etc/racoon.conf" Aug 14 11:50:10 racoon: INFO: @(#)This product linked OpenSSL 0.9.8n 24 Mar 2010 (http://www.openssl.org/) Aug 14 11:50:10 racoon: INFO: @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) Aug 14 11:50:05 racoon: INFO: racoon process 55123 shutdown Aug 14 11:50:05 racoon: INFO: caught signal 15

@jimp:

It would affect all tunnels, and it would not replicate via carp as it's a per-host setting.

Got so far as to figure out it was a system-wide setting, but since I'm not that strong on network I'm trying to figure out whether it will have any negative effect on the other tunnels or if alle other VPN endpoints should adjust their MTU size when communicating with the pfSense boxes…

It should match on both sides.