Re: [pfSense] CARP sync of skew results in blank Status on backup router, breaking failover
On Mar 24, 2015, at 9:47 AM, Steve Yates st...@teamits.com wrote: I'm going to start a new thread since I think this is a different issue. I have a rule to allow all IPv4 from PFSYNC net to PFSYNC net. That network is on a VLAN with only those two interfaces on it. The failover and fail back works fine on all five CARP interfaces/aliases if router1 is shut down, it enters CARP maintenance mode, etc. I think this is a bug that if the CARP skew setting syncs, something happens to the backup so it has a blank Status and no longer considers itself the Backup for that interface, and therefore failover does not happen. (enabling CARP maintenance mode on router1 sets only the other four interfaces to Backup status and the broken one remains Master). Interesting to note, the breakage happens immediately upon editing the router1 skew, before Apply Changes are clicked on router1. And, when router2's CARP alias is in that state, setting the skew on router1 back to 0 does not sync over to router2; its skew stays at 101. It's as if the link is broken. Since nobody else has chimed in are you sure CARP setting changes are supposed to be synced? It makes sense that when a primary syncs to a new secondary, or a new VIP is created on the Master, defaults are chosen on the secondary to ensure it comes up as Backup. After that happens, I don’t think I want changes to CARP settings to be synced. What are you doing messing around with base and skew anyway? ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] FW: Virus Detected
To follow up, True that, just a heads up for the people who do not have any virus scanners in their network. ☺ Mikey Van: List [mailto:list-boun...@lists.pfsense.org] Namens Moshe Katz Verzonden: dinsdag 24 maart 2015 16:57 Aan: pfSense Support and Discussion Mailing List Onderwerp: Re: [pfSense] FW: Virus Detected It looks like someone spoofed a message that it claims came from the server itself (though it actually came from another server in Denmark (87.104.0.8)). Someone who has access to the mailing list server could likely pull out the original message's full headers and file an abuse report with the ISP, but I doubt that it'll make any difference. Just ignore the message. Your virus scanner did catch it, after all. Moshe -- Moshe Katz -- mo...@ymkatz.netmailto:mo...@ymkatz.net -- +1(301)867-3732 On Tue, Mar 24, 2015 at 6:09 AM, Mikey van der Worp mvdw...@utelisys.commailto:mvdw...@utelisys.com wrote: Em? Why is this list sending me viruses? Please be advised for e-mail with the following headers below... Mikey -Oorspronkelijk bericht- Van: MailScanner [mailto:postmas...@mail.utelisys.nlmailto:postmas...@mail.utelisys.nl] Verzonden: dinsdag 24 maart 2015 11:08 Aan: postmas...@mail.utelisys.nlmailto:postmas...@mail.utelisys.nl Onderwerp: Virus Detected The following e-mails were found to have: Virus Detected Sender: list-boun...@lists.pfsense.orgmailto:list-boun...@lists.pfsense.org IP Address: 208.123.73.78 Recipient: mvdw...@utelisys.commailto:mvdw...@utelisys.com Subject: [pfSense] Message could not be delivered MessageID: 17C4E62EF0.ACDCC Quarantine: Report: Clamd: message was infected: Worm.Mydoom.M-unp Report: Clamd: message.comhttp://message.com was infected: Worm.Mydoom.M-unp Full headers are: Received: from lists.pfsense.orghttp://lists.pfsense.org (lists.pfsense.orghttp://lists.pfsense.org [208.123.73.78]) by mail.utelisys.nlhttp://mail.utelisys.nl (Postfix) with ESMTP id 17C4E62EF0 for mvdw...@utelisys.commailto:mvdw...@utelisys.com; Tue, 24 Mar 2015 11:08:28 +0100 (CET) Received: from localhost.my.domain (localhost [127.0.0.1]) by lists.pfsense.orghttp://lists.pfsense.org (Postfix) with ESMTP id BF73AEB2E7; Tue, 24 Mar 2015 05:11:22 -0500 (CDT) Received: from lists.pfsense.orghttp://lists.pfsense.org (exchange.kajmadsen.dkhttp://exchange.kajmadsen.dk [87.104.0.8]) by lists.pfsense.orghttp://lists.pfsense.org (Postfix) with ESMTP id 93503EB2E2 for list@lists.pfsense.orgmailto:list@lists.pfsense.org; Tue, 24 Mar 2015 05:11:17 -0500 (CDT) From: MAILER-DAEMON mailer-dae...@lists.pfsense.orgmailto:mailer-dae...@lists.pfsense.org To: list@lists.pfsense.orgmailto:list@lists.pfsense.org Date: Tue, 24 Mar 2015 11:08:15 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0003_E64740E7.04F4C9BF X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Subject: [pfSense] Message could not be delivered X-BeenThere: list@lists.pfsense.orgmailto:list@lists.pfsense.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: pfSense Support and Discussion Mailing List list@lists.pfsense.orgmailto:list@lists.pfsense.org List-Id: pfSense Support and Discussion Mailing List list.lists.pfsense.orghttp://list.lists.pfsense.org List-Unsubscribe: https://lists.pfsense.org/mailman/options/list, mailto:list-requ...@lists.pfsense.orgmailto:list-requ...@lists.pfsense.org?subject=unsubscribe List-Archive: http://lists.pfsense.org/pipermail/list/ List-Post: mailto:list@lists.pfsense.orgmailto:list@lists.pfsense.org List-Help: mailto:list-requ...@lists.pfsense.orgmailto:list-requ...@lists.pfsense.org?subject=help List-Subscribe: https://lists.pfsense.org/mailman/listinfo/list, mailto:list-requ...@lists.pfsense.orgmailto:list-requ...@lists.pfsense.org?subject=subscribe Errors-To: list-boun...@lists.pfsense.orgmailto:list-boun...@lists.pfsense.org Sender: List list-boun...@lists.pfsense.orgmailto:list-boun...@lists.pfsense.org Message-Id: 20150324101122.bf73aeb...@lists.pfsense.orgmailto:20150324101122.bf73aeb...@lists.pfsense.org -- MailScanner Email Virus Scanner www.mailscanner.infohttp://www.mailscanner.info ___ 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
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
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
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] CARP sync of skew results in blank Status on backup router, breaking failover
Steve Yates wrote on Wed, Mar 25 2015 at 1:22 pm: In my other thread, diagnosing why failback only moved back the WAN IPs, if the physical host had its network restarted underneath my router VM. Sorry, had that backwards FWIW; it only moved back the LAN. Again, not a normal situation but I had added IPv6 settings and shortcutted a full restart, then chased this issue when I lost access to my testbed despite having two routers running. -- Steve Yates ITS, Inc. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
