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.

When you go to Status / IPSec are the Local and Remote IPs in the right sub-nets ?  Also, check SPD – Then see if it agrees with the routing / rules / LAN nets in use. ==========

@jimp: It depends on the tunnel. If it's a "mobile" tunnel setup, then pfSense can't really accurately see the status. If it's a normal style, it reads the SAD and SPD info from the IPsec daemon to determine if it has fully established both Phase 1 and Phase 2. I'm using IPsec in Transport mode ( GRE tunnel passing through ). Thank you.

@jimp: dhatz is correct, ipsec-tools, which is what we use for IPsec, does not support lifetimes by data size, only by time. A little extra research on this topic reveals that it seems to be deprecated in racoon, ie. removed and I will therefore assume that it is not a feature that is coming (back)…

Could you try testing this with pfsense 2.1-BETA? There have been a number of patches applied to ipsec-tools 0.8.0 (although several more patches have been commited to the ipsec-tools tree http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/crypto/dist/ipsec-tools/src/ that haven't made it into pfsense yet) PS: You could also run racoon in high verbosity mode and check the discussions in http://sourceforge.net/mailarchive/forum.php?forum_name=ipsec-tools-commits