It might be the timeout value as well.

Saturate your link and then from a shell try this:

ping -t1 $monitor_ip

Then slowly crank -t1 up by 1 and attempt again:

ping -t2 $monitor_ip

Keep cranking up the timeout until you find a decent sweet spot and if it is not too invasive we might be able to change this easily.  Modifying SLBD to keep track of all previous ping counts is a fair amount of work since this is written in C.

You mention problems between 2 endpoints explicitly? Maybe investigate if there are line issues or if something is special about these endpoints (like running another firmware at their end or whatever).

the only reason I'm aware of that people were wanting to use gif devices is for filtering, now filtering is possible by default with enc(4) in current snapshots.

Hi,

I've the same problem, but using the 03-15-2007 Snapshot.
It seems like it works well only the first time (or after a reboot) when there is no SA…
I'll do some more test...
bye
Z

ok… looks like "vpn goes down" problem was fixed. the server has been up for more then 24 hours now. but i still can't ftp to remote sites over vpn. pcanywhere (and file transfer) works fine, i can ssh and scp to remote pc's and they can ftp to my office, but i cant ftp to them. does anybody know how to fix this? tnx

p.s. this _If you want to connect to a FTP server you need to add this workaround to your LAN tab.

Proto Source Port Destination Port Gateway TCP LAN net * 127.0.0.1 1 - 65535 *

Now the packets are forwarded correctly and you can connect to an FTP server._ is not helping.

ok… ftp problem was fixed too  8) as they say "if nothing works read the manual"  ;D ::)

Something like this could be done between sites that only run pfSense systems if some code was written for this kind of dead peer detection. Multiwan IPSEC is working with the latest changes in the snapshots, it just doesn'T detect failure or does failover.

Well there seems to be some intermittent issue with phase two on this tunnel.  Logs are below.  The only thing I can think of is that the lifetime doesn't match correctly because I see a new phase 2 negotiation from them every two minutes when they are connected.  It sounded like they specify their lifetimes in hours instead of seconds and their lifetime is set to 2 hours, I've got my end configured at 7200s.  Not sure how pf is seeing that during the negotiation, are there any more detailed logs I can look to see any additional details?

racoon: INFO: purged ISAKMP-SA spi=9564dbd685564852:333386a2d2c623da.
Mar 23 10:18:44 racoon: INFO: purging ISAKMP-SA spi=9564dbd685564852:333386a2d2c623da.
Mar 23 10:18:44 racoon: INFO: respond new phase 2 negotiation: me.me.me.me[500]<=>them.them.them.them[500]
Mar 23 10:18:44 racoon: INFO: ISAKMP-SA established me.me.me.me[500]-them.them.them.them[500] spi:9564dbd685564852:333386a2d2c623da
Mar 23 10:18:44 racoon: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
Mar 23 10:18:43 racoon: INFO: begin Identity Protection mode.
Mar 23 10:18:43 racoon: INFO: respond new phase 1 negotiation: me.me.me.me[500]<=>them.them.them.them[500]
Mar 23 10:18:29 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument

Yes, perfect.
Thanks.

May i ask you if this is correct?
Client (MTU 1500) -> LAN (MTU 1500) -> IPSEC -> WAN (MTU 1300) -> INET <- WAN (MTU 1300) <- IPSEC <- LAN (MTU 1500) <- Client (MTU 1500)

Ok this is what I have now

WAN->LAN
ESP  *  *  qOthersDownH/qOthersUpH  m_Other IPSEC inbound     
   
  WAN->LAN
UDP  *  *
Port: 500  qOthersDownH/qOthersUpH  m_Other IPSEC inbound     
   
  LAN->WAN
UDP  *  *
Port: 500  qOthersUpH/qOthersDownH  m_Other IPSEC outbound     
   
  LAN->WAN
AH  *  *  qOthersUpH/qOthersDownH  m_Other IPSEC outbound     
   
  LAN->WAN
ESP  *  *  qOthersUpH/qOthersDownH  m_Other IPSEC outbound     
   
  WAN->LAN
AH  *  *  qOthersDownH/qOthersUpH  m_Other IPSEC inbound

Ony CARP can be used by the firewallitself to run services on. ProxyARP and Other ony can be forwarded. Change this IP to CARP and use the CARP IP as ipsec failover IP. Then it should work.

Sounds like lifetime mismatches.

Either way, check Prefer old IPsec SAs in System -> Advanced

Ok, thanks  ;D

No, one of the sites has to be static at least.

Does it use mainmode? If yes try using agressive. Maybe you get more options then.

I downloaded one from earlier today.  It's fixed.

Feb 28 14:23:21 racoon: ERROR: malformed cookie received.

The checkpoint seems to send something strange. Revisit all parameters and check if they are abolutely identical. Maybe try using mainmode instead of aggressive.