FWIW, since my original report, I've noticed some other things: - since it's not yet "deployed," the v2.2.1 (at both ends) site-to-site IPsec VPN has only 1 laptop and 1 wireless access point on the LAN and virtually nothing else happening on the WAN (it's tied to a cable modem)
- the condition, when I did the original report, was that the laptop was sleeping -- it's a Mac with network wake-up configured and, in that mode, they constantly bring the port up 'n down (hundreds of times per day, each, according to switches at this office) - I needed to make some changes to that laptop so I had someone bring it over here ... and that significantly changed the VPN "up-ness" behavior: + now the VPN is _much_ more likely to be up when I attempt to use it (i.e., with no LAN-to-LAN non-pfSense traffic, assuming there is some generated by the VPN mechanisms, themselves), but ... wait for it ... + if I ping the pfSense at the other end and the VPN connection _is_ alive, it'll stay alive as long as I continue the once-a-second pinging (from a non-pfSense system on the LAN) ... + however, if I kill the ping, wait 2 or 3 minutes then ping it again, it'll be down ... i.e., the pinging activity seems to stimulate a connection failure once the pinging stops (this seems to be a consistent behavior) ... + or maybe what I'm seeing is "the norm" -- i.e., that, as soon as there's a lull in Lan-to-Lan traffic for a short time, the connection drops (even though the config includes DPD and ping'd host at each end) e.g.: [surprise, it's up] ______________________________________________________________________ /Users/admin (2015-03-23 @ 15:26:05) root # ping 172.16.22.1 PING 172.16.22.1 (172.16.22.1): 56 data bytes 64 bytes from 172.16.22.1: icmp_seq=0 ttl=63 time=26.280 ms 64 bytes from 172.16.22.1: icmp_seq=1 ttl=63 time=17.740 ms 64 bytes from 172.16.22.1: icmp_seq=2 ttl=63 time=18.134 ms ^C --- 172.16.22.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 17.740/20.718/26.280/3.936 ms [now wait about 2.5 minutes ... and it's down] ______________________________________________________________________ /Users/admin (2015-03-23 @ 15:26:12) root # ping 172.16.22.1 PING 172.16.22.1 (172.16.22.1): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ... <snip'd> Request timeout for icmp_seq 95 Request timeout for icmp_seq 96 Request timeout for icmp_seq 97 64 bytes from 172.16.22.1: icmp_seq=98 ttl=63 time=15.365 ms 64 bytes from 172.16.22.1: icmp_seq=99 ttl=63 time=14.927 ms 64 bytes from 172.16.22.1: icmp_seq=100 ttl=63 time=13.905 ms 64 bytes from 172.16.22.1: icmp_seq=101 ttl=63 time=15.105 ms 64 bytes from 172.16.22.1: icmp_seq=102 ttl=63 time=17.298 ms 64 bytes from 172.16.22.1: icmp_seq=103 ttl=63 time=18.674 ms 64 bytes from 172.16.22.1: icmp_seq=104 ttl=63 time=16.015 ms 64 bytes from 172.16.22.1: icmp_seq=105 ttl=63 time=15.246 ms 64 bytes from 172.16.22.1: icmp_seq=106 ttl=63 time=15.009 ms 64 bytes from 172.16.22.1: icmp_seq=107 ttl=63 time=15.953 ms 64 bytes from 172.16.22.1: icmp_seq=108 ttl=63 time=17.085 ms 64 bytes from 172.16.22.1: icmp_seq=109 ttl=63 time=21.631 ms 64 bytes from 172.16.22.1: icmp_seq=110 ttl=63 time=16.873 ms 64 bytes from 172.16.22.1: icmp_seq=111 ttl=63 time=16.639 ms 64 bytes from 172.16.22.1: icmp_seq=112 ttl=63 time=15.385 ms ^C --- 172.16.22.1 ping statistics --- 113 packets transmitted, 15 packets received, 86.7% packet loss round-trip min/avg/max/stddev = 13.905/16.341/21.631/1.823 ms ______________________________________________________________________ /Users/admin (2015-03-23 @ 15:30:21) root # _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
