Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-09-05 Thread Bryan D. 
On 2015-Sep-04, at 1:18 PM, David Hatch  wrote:

> We are having all the same symptoms above. All of our firewalls are 
> running 2.2.4. Everything that has 2 phase 2 entries is on IKE v2. ...
> 
> Has anyone figured this out? ... nothing I can do will fix it short of pining 
> from 
> a non-pfsense box inside the LAN to a remote location. Doing this 
> constantly will keep the connection solid, but that's about it. Any help 
> would be appreciated. Thanks.

If you search the archives for the subject
2.2.1 Site-to-Site IPsec VPN Connection Instability
you'll find this is an issue that's been experienced by others.

Your "ping via an external system" workaround is what works (code in one of the 
posted emails).

On 2015-04-04 I provided Chris Buechler some logs he requested and on 
2015-04-07 he responded with
---
thanks, that should help narrow things down. I don't see anything
obvious at a glance, will more closely correlate timestamps and across
logs when I have time at some point this week.
---
That was the last I heard.

I'm still on v2.2.2 and the issue still exists.  From what you're saying, 
sounds like it's still in 2.2.4.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-09-04 Thread David Hatch 
We are having all the same symptoms above. All of our firewalls are 
running 2.2.4. Everything that has 2 phase 2 entries is on IKE v2. We are 
planning on changing the rest but we have 45 sites...it take a long 
time...


Has anyone figured this out? It's driving me crazy and causing everything 
to be so unreliable I've considered going back to 2.1.5 on all of my boxes 
even if it takes me a month to do it. It's that bad. I'm experiencing all 
of the OP's symptoms and nothing I can do will fix it short of pining from 
a non-pfsense box inside the LAN to a remote location. Doing this 
constantly will keep the connection solid, but that's about it. Any help 
would be appreciated. Thanks.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-26 Thread Chris Buechler 
On Mon, Mar 23, 2015 at 9:34 AM, Christopher CUSE cc...@ccuse.com wrote:

 On 03/23/2015 03:03 PM, mayak wrote:

 On 03/22/2015 12:38 AM, Bryan D. wrote:

 We've had a pfSense-to-pfSense always on IPsec VPN connecting 2 offices
 since 2008 (pfSense 1.2 IIRC) and it's:
 - been ultra reliable (if VPN is down, suspect ISP issue or pfSense box
 failure)
 - it's been quick to connect (about 1 second, almost unnoticeable)
 - it's worked across numerous upgrades without issue (nice!)

 Beginning with pfSense v2, we added multiple P2s at each end (still same
 reliability, etc.).

 One of the offices has had its hardware updated and its pfSense updated
 to 2.2 then 2.2.1 (after testing to see whether we seemed to be affected by
 the multiple P2 issue noted in the upgrade page -- we're OK on that one).
 This connection has continued to work with the same characteristics as
 before.  The 2.2.1 system is 64-bit and the other end is v2.1.5 32-bit

 We recently added a second site-to-site IPsec VPN, essentially the same
 as the existing one except both sides are pfSense v2.2.1 (but other end is
 32-bit) and stronger algorithms are being used and P1 is set to v2
 (supposedly avoiding any multiple P2 issues).

 snip

 i have to say that i am also experiencing this. i'm in the process of
 installing smokeping to prove connectivity is good between the public ip
 endpoints between various vpns.

 will report back with those results.

 thanks

 m


 just got dropped again -- fourth time in last few hours -- something is
 definitely wrong.

 upgraded all my pfsenses to 2.2.1 over the weekend.


Go to SystemAdvanced, System Tunables, and add a new tunable there.
Name net.key.preferred_oldsa, value 0, then save and apply changes.
That have any impact on things?
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-25 Thread Christopher CUSE 


On 03/23/2015 03:03 PM, mayak wrote:

On 03/22/2015 12:38 AM, Bryan D. wrote:

We've had a pfSense-to-pfSense always on IPsec VPN connecting 2 offices since 
2008 (pfSense 1.2 IIRC) and it's:
- been ultra reliable (if VPN is down, suspect ISP issue or pfSense box failure)
- it's been quick to connect (about 1 second, almost unnoticeable)
- it's worked across numerous upgrades without issue (nice!)

Beginning with pfSense v2, we added multiple P2s at each end (still same 
reliability, etc.).

One of the offices has had its hardware updated and its pfSense updated to 2.2 then 2.2.1 
(after testing to see whether we seemed to be affected by the multiple P2 
issue noted in the upgrade page -- we're OK on that one).  This connection has 
continued to work with the same characteristics as before.  The 2.2.1 system is 64-bit 
and the other end is v2.1.5 32-bit

We recently added a second site-to-site IPsec VPN, essentially the same as the existing 
one except both sides are pfSense v2.2.1 (but other end is 32-bit) and stronger 
algorithms are being used and P1 is set to v2 (supposedly avoiding any multiple 
P2 issues).

snip

i have to say that i am also experiencing this. i'm in the process of 
installing smokeping to prove connectivity is good between the public ip 
endpoints between various vpns.

will report back with those results.

thanks

m


just got dropped again -- fourth time in last few hours -- something is 
definitely wrong.

upgraded all my pfsenses to 2.2.1 over the weekend.

m
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-25 Thread Vincent Hoffman-Kazlauskas 


On 23/03/2015 14:34, Christopher CUSE wrote:
 
 On 03/23/2015 03:03 PM, mayak wrote:
 On 03/22/2015 12:38 AM, Bryan D. wrote:
 We've had a pfSense-to-pfSense always on IPsec VPN connecting 2
 offices since 2008 (pfSense 1.2 IIRC) and it's:
 - been ultra reliable (if VPN is down, suspect ISP issue or pfSense
 box failure)
 - it's been quick to connect (about 1 second, almost unnoticeable)
 - it's worked across numerous upgrades without issue (nice!)

 Beginning with pfSense v2, we added multiple P2s at each end (still
 same reliability, etc.).

 One of the offices has had its hardware updated and its pfSense
 updated to 2.2 then 2.2.1 (after testing to see whether we seemed to
 be affected by the multiple P2 issue noted in the upgrade page --
 we're OK on that one).  This connection has continued to work with
 the same characteristics as before.  The 2.2.1 system is 64-bit and
 the other end is v2.1.5 32-bit

 We recently added a second site-to-site IPsec VPN, essentially the
 same as the existing one except both sides are pfSense v2.2.1 (but
 other end is 32-bit) and stronger algorithms are being used and P1 is
 set to v2 (supposedly avoiding any multiple P2 issues).
 snip

 i have to say that i am also experiencing this. i'm in the process of
 installing smokeping to prove connectivity is good between the public
 ip endpoints between various vpns.

 will report back with those results.

 thanks

 m
 
 just got dropped again -- fourth time in last few hours -- something is
 definitely wrong.
 
 upgraded all my pfsenses to 2.2.1 over the weekend.
 
We also seem to be having stability issues on our site to site vpn
(2.2.1 one end, 2.0.1 the other, plan was to upgrade soon) its only
stopping once every day or so afaik but it was prety rock solid before I
upgraded the end thats now 2.2.1, looking at adding some monitoring also
just to make sure of end to end connectivity before I investigate further.

Happy to supply more info if it'll help.

Vince

 m
 ___
 pfSense mailing list
 https://lists.pfsense.org/mailman/listinfo/list
 Support the project with Gold! https://pfsense.org/gold
 
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-25 Thread Bryan D. 
On 2015-Mar-23, at 7:34 AM, Christopher CUSE cc...@ccuse.com wrote:
 just got dropped again -- fourth time in last few hours -- something is 
 definitely wrong.
 
 upgraded all my pfsenses to 2.2.1 over the weekend.

For me, the VPN drops in the absence of end-to-end traffic ... within 
minutes.  The fact that both ends are config'd to ping and do DPD seems to be 
of no consequence.  Our site-to-site VPNs have multiple P2s.  As long as a 
connection exists, (in my limited testing) activating a new P2 seems to be 
v2.1.5-reliable.

I set up a script (running on one of our severs) that pings and the connection 
has been up (with virtually no other traffic, because it's pre-production) for 
about 1.5 days.  It dies within minutes without the pinging.  The script did 
not work when run on the pfSense box, itself (though I really haven't thought 
it through and there could be a perfectly good reason why it wouldn't).


For anyone who's interested, here's the (simple) script:
---
#!/bin/sh
#set -x  ## Uncomment to get a trace

# keep IPsec VPN tunnel(s) connected

#---
# Run this script every minute via the following /etc/crontab entry
# (minus the first comment character):
#*/1  *  *  *  *  admin /usr/local/bin/keepAliveIPsec.sh   ## keep IPsec VPNs 
connected

# The space-separated list of hosts (IP or FQDN) that will be ping'd
HOSTS_TO_PING='172.24.24.1 172.24.28.1'

# Set the maximum number of seconds that a ping will wait for a response
PING_TIMEOUT='1'

# Set the interval, in seconds, between ping attempts to each group of hosts
PING_INTERVAL='3'

# NOTE that the total interval between pings for each host will be the
# PING_INTERVAL plus the sum of the response times for each host being ping'd --
# i.e., where the maximum response time is the PING_TIMEOUT and the minimum is
# the successful ping-response time (for each host being ping'd)
#---

# Don't run if a keepAliveIPsec.sh process is already running
PROCS=`/bin/ps -ax -o pid,command`
OTHER_KEEPALIVE_PROCS=`\
   echo $PROCS | /usr/bin/sed -e '/[ \t\/]keepAliveIPsec.sh/!d' \
-e '/^[ \t]*'$$'[ \t]/d'`
if test $OTHER_KEEPALIVE_PROCS != 
then
   #echo 'keepAliveIPsec.sh already running'  # uncomment for testing
   exit 1
fi

# Ping the required hosts, forever
while true
do
   for HOST in $HOSTS_TO_PING
   do
  #/sbin/ping -c 1 -t $PING_TIMEOUT  $HOST  # uncomment for testing
  /sbin/ping -c 1 -t $PING_TIMEOUT  $HOST \
 21 /dev/null  # comment out for testing
   done

   #echo 'sleeping'  # uncomment for testing
   sleep $PING_INTERVAL
done

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-23 Thread mayak 

On 03/22/2015 12:38 AM, Bryan D. wrote:

We've had a pfSense-to-pfSense always on IPsec VPN connecting 2 offices since 
2008 (pfSense 1.2 IIRC) and it's:
- been ultra reliable (if VPN is down, suspect ISP issue or pfSense box failure)
- it's been quick to connect (about 1 second, almost unnoticeable)
- it's worked across numerous upgrades without issue (nice!)

Beginning with pfSense v2, we added multiple P2s at each end (still same 
reliability, etc.).

One of the offices has had its hardware updated and its pfSense updated to 2.2 then 2.2.1 
(after testing to see whether we seemed to be affected by the multiple P2 
issue noted in the upgrade page -- we're OK on that one).  This connection has 
continued to work with the same characteristics as before.  The 2.2.1 system is 64-bit 
and the other end is v2.1.5 32-bit

We recently added a second site-to-site IPsec VPN, essentially the same as the existing 
one except both sides are pfSense v2.2.1 (but other end is 32-bit) and stronger 
algorithms are being used and P1 is set to v2 (supposedly avoiding any multiple 
P2 issues).

snip

i have to say that i am also experiencing this. i'm in the process of 
installing smokeping to prove connectivity is good between the public ip 
endpoints between various vpns.

will report back with those results.

thanks

m
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-23 Thread Justin Edmands 
I am having issues as well. 2.0.0 -- 2.0.3 works fine. Upgraded to 2.2.1
and the connection always fails within 24 hours.

Please let me know how the 2.2.1 x 5 setup works.

On Mon, Mar 23, 2015 at 1:40 PM, Jeremy Bennett jbenn...@hikitechnology.com
 wrote:

 Yes. I have 5 sites (of various 2.0+ pfsense) connected via IPSec.
 Historically, this setup was the definition of stable. Since adding a 2.2
 box it has been flaky as all get out.

 I'm in the process of upgrading each location to 2.2.1. Hoping that will
 be the easy fix, if not, will have to start chasing it.


 On Monday, March 23, 2015, mayak ma...@australsat.com wrote:


 On 03/23/2015 03:03 PM, mayak wrote:

 On 03/22/2015 12:38 AM, Bryan D. wrote:

 We've had a pfSense-to-pfSense always on IPsec VPN connecting 2
 offices since 2008 (pfSense 1.2 IIRC) and it's:
 - been ultra reliable (if VPN is down, suspect ISP issue or pfSense box
 failure)
 - it's been quick to connect (about 1 second, almost unnoticeable)
 - it's worked across numerous upgrades without issue (nice!)

 Beginning with pfSense v2, we added multiple P2s at each end (still
 same reliability, etc.).

 One of the offices has had its hardware updated and its pfSense updated
 to 2.2 then 2.2.1 (after testing to see whether we seemed to be affected by
 the multiple P2 issue noted in the upgrade page -- we're OK on that
 one).  This connection has continued to work with the same characteristics
 as before.  The 2.2.1 system is 64-bit and the other end is v2.1.5 32-bit

 We recently added a second site-to-site IPsec VPN, essentially the same
 as the existing one except both sides are pfSense v2.2.1 (but other end is
 32-bit) and stronger algorithms are being used and P1 is set to v2
 (supposedly avoiding any multiple P2 issues).

 snip

 i have to say that i am also experiencing this. i'm in the process of
 installing smokeping to prove connectivity is good between the public ip
 endpoints between various vpns.

 will report back with those results.

 thanks

 m
 __

 it is happening -- three times since last post ... anyone else noticing
 vpn outages?

 thanks

 m

 ___
 pfSense mailing list
 https://lists.pfsense.org/mailman/listinfo/list
 Support the project with Gold! https://pfsense.org/gold


 ___
 pfSense mailing list
 https://lists.pfsense.org/mailman/listinfo/list
 Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-23 Thread Bryan D. 
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

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-23 Thread Chris Buechler 
There's nothing to go on to offer any worthwhile suggestions. IPsec
logs best place to start.

On Mon, Mar 23, 2015 at 6:02 PM, Bryan D. pfse...@derman.com wrote:
 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
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-23 Thread Bryan D. 
On 2015-Mar-23, at 5:24 PM, Chris Buechler c...@pfsense.com wrote:

 There's nothing to go on to offer any worthwhile suggestions. IPsec
 logs best place to start.


If you can be more specific, I'll try to help.  Sorry, but I don't have enough 
background with IPsec to ferret things out on my own.  I did try setting both 
Networking and IPsec Traffic (in Advanced Settings) to Diag then to Raw, 
but saw no additional IPsec logging after pressing the Restart IPsec service 
button on that page.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] 2.2.1 Site-to-Site IPsec VPN Connection Instability

2015-03-21 Thread Bryan D. 
We've had a pfSense-to-pfSense always on IPsec VPN connecting 2 offices since 
2008 (pfSense 1.2 IIRC) and it's:
- been ultra reliable (if VPN is down, suspect ISP issue or pfSense box failure)
- it's been quick to connect (about 1 second, almost unnoticeable)
- it's worked across numerous upgrades without issue (nice!)

Beginning with pfSense v2, we added multiple P2s at each end (still same 
reliability, etc.).

One of the offices has had its hardware updated and its pfSense updated to 2.2 
then 2.2.1 (after testing to see whether we seemed to be affected by the 
multiple P2 issue noted in the upgrade page -- we're OK on that one).  This 
connection has continued to work with the same characteristics as before.  The 
2.2.1 system is 64-bit and the other end is v2.1.5 32-bit

We recently added a second site-to-site IPsec VPN, essentially the same as the 
existing one except both sides are pfSense v2.2.1 (but other end is 32-bit) and 
stronger algorithms are being used and P1 is set to v2 (supposedly avoiding any 
multiple P2 issues).

The new pfSense (v2.2.1 at both ends) always on (not!) IPsec VPN is:
- v-e-r-y  s-l-o-w  to connect: e.g. pinging when connection is down yields: 
once a connection after 12 seconds, once a connection after 22 seconds and 
dozens of connections after  2.25 minutes
- completely unable to stay connected: both sides have DPD enabled (5 sec./3 
retries) and both sides can be initiators and both sides have 1 P2 set to ping 
the pfSense at the other end
- pressing the connect button on pfSense's IPsec status page yields an 
instant connection but there won't be any P2 traffic coming back for a while, 
which seems to consistently be the connection-delay issue

If one of the ends has regular (almost constant) traffic, the VPN stays 
connected.  In testing, I've had one non-pfSense system pinging the pfSense at 
the other end and the VPN stays connected.

If VPN traffic pauses for a short time (ten minutes?), the connection is 
dropped.  While that is not what's expected, given the config, it wouldn't be 
bad _if_ the connection was quickly re-established with traffic, but it's not.

I'm providing this information because of the discussions about issues with 
multiple P2s and the idea that they're solved by using v2 P1 at both ends.  
It's quite possible that:
- there are issues with multiple P2s even with v2 P1
- the DPD stuff isn't working
- the P2 automatically ping host stuff isn't working ... but pinging a host 
via a non-pfSense system does keep the connection alive

I'm willing to run some tests if someone wants to tell me what they want done.  
For about a week, the new v2.2.1 site-to-site VPN won't really be used, I can 
do almost anything that doesn't cause the other side to go dead (or I'd need to 
make a trip to the other site and that may not happen very quickly).

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold