Re: [pfSense] pfsens 2.1-beta1 Higly unstable

2013-04-05 Thread jerome alet
Hi,

Christophe Ségui christophe.se...@math.univ-toulouse.fr wrote:I'tried 
pfsense 2.1-BE5A1 as router/firewall (ospf is used for wan) and /22 network as 
internal network. With PF activated, the node crash after 2 hours up …  since 
pf is deactivated, node stays up (routing functionnalities are OK). Does 
someone experienced the same issue ?Here we are using 2.1BETA1 for a long time 
in production.

What we've learnt is that from one day to the other, fixes are incorporated, 
but sometimes fixes break something else, so while we used to upgrade everyday 
to benefit from the latest fixes, we now stay with a version which mostly 
works for us : 2.1-BETA1   (amd64) 

built on Thu Feb 28 04:29:38 EST 2013

Since we're running a two nodes cluster, testing a new release is easy but 
takes time : upgrade the slave, shutdown the master, see if all works as 
expected. If not, restore the full backup, else upgrade the master as well. But 
this can be very very time consuming especially due to pfSense's full backup 
(when upgrading from the GUI) which saves, slowly, almost everything including 
Squid's cache content.

We're still stuck with some minor problems but this version doesn't crash at 
least... We've got planned downtime tomorrow, and planned to try an upgrade, 
but reading your message I think we'll wait a bit more :-)

So my advice to you would be to try daily upgrades until you'll find one that 
works, and stay with it until a BETA2 or an RC is published.

bye

-- 
Jerome Alet___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] pfsens 2.1-beta1 Higly unstable

2013-04-05 Thread Christophe Ségui

Le 5 avr. 2013 à 12:02, Chris Buechler c...@pfsense.org a écrit :

 On Fri, Apr 5, 2013 at 4:59 AM, Christophe Ségui
 christophe.se...@math.univ-toulouse.fr wrote:
 
 Hi,
 
 I'tried pfsense 2.1-BE5A1 as router/firewall (ospf is used for wan) and
 /22 network as internal network. With PF activated, the node crash after 2
 hours up …  since pf is deactivated, node stays up (routing functionnalities
 are OK).
 Does someone experienced the same issue ?
 
 
 There are thousands of people running it in production with no issue,
 not a general problem. Define crash, does it actually kernel panic
 and reboot? Or just stop accepting new connections? The latter, you're
 likely running out of states.

kernel panic. hard reboot needed.(


 ___
 List mailing list
 List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list

-- 
   Christophe Ségui
   Responsable
   informatique
Institut de Mathématiques de Toulouse
Université de Toulouse - CNRS
118 Route de Narbonne
31062 Toulouse Cedex 09

Tel : (+33) 5 61 55 63 78
christophe.se...@math.univ-toulouse.fr
http://www.math.univ-toulouse.fr



smime.p7s
Description: S/MIME cryptographic signature
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] pfsens 2.1-beta1 Higly unstable

2013-04-05 Thread Chris Buechler
On Fri, Apr 5, 2013 at 7:19 AM, Christophe Ségui
christophe.se...@math.univ-toulouse.fr wrote:

 kernel panic. hard reboot needed.(


You submit a crash report?
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] pfsens 2.1-beta1 Higly unstable

2013-04-05 Thread Christophe Ségui
Hi,

Yes, sounds like a good way to test new relaese in production. Unfortunately, 
we use a single node here :/ 

thanks anyway

Christophe
Le 5 avr. 2013 à 12:12, jerome alet jerome.a...@univ-nc.nc a écrit :

 Hi,
 
 Christophe Ségui christophe.se...@math.univ-toulouse.fr wrote:
 
 I'tried pfsense 2.1-BE5A1 as router/firewall (ospf is used for wan) and /22 
 network as internal network. With PF activated, the node crash after 2 hours 
 up …  since pf is deactivated, node stays up (routing functionnalities are 
 OK). 
 Does someone experienced the same issue ?
 Here we are using 2.1BETA1 for a long time in production.
 
 What we've learnt is that from one day to the other, fixes are incorporated, 
 but sometimes fixes break something else, so while we used to upgrade 
 everyday to benefit from the latest fixes, we now stay with a version which 
 mostly works for us : 2.1-BETA1 (amd64) 
 built on Thu Feb 28 04:29:38 EST 2013
 
 Since we're running a two nodes cluster, testing a new release is easy but 
 takes time : upgrade the slave, shutdown the master, see if all works as 
 expected. If not, restore the full backup, else upgrade the master as well. 
 But this can be very very time consuming especially due to pfSense's full 
 backup (when upgrading from the GUI) which saves, slowly, almost everything 
 including Squid's cache content.
 
 We're still stuck with some minor problems but this version doesn't crash at 
 least... We've got planned downtime tomorrow, and planned to try an upgrade, 
 but reading your message I think we'll wait a bit more :-)
 
 So my advice to you would be to try daily upgrades until you'll find one that 
 works, and stay with it until a BETA2 or an RC is published.
 
 bye
 
 -- 
 Jerome Alet
 ___
 List mailing list
 List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list

-- 
   Christophe Ségui
   Responsable
   informatique
Institut de Mathématiques de Toulouse
Université de Toulouse - CNRS
118 Route de Narbonne
31062 Toulouse Cedex 09

Tel : (+33) 5 61 55 63 78
christophe.se...@math.univ-toulouse.fr
http://www.math.univ-toulouse.fr




smime.p7s
Description: S/MIME cryptographic signature
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


[pfSense] Firewall Rules Ordering and Execution

2013-04-05 Thread Ron Lemon
Hello,


I am having difficulty getting a pair of rules to work together.  I have 2 RDP 
pools that I need to be able to direct people to.  I have created 2 rules for 
this purpose:

NAT Rule 1 - if the IP address matches the alias called Special_People and they 
are trying to attach to port 3389 then direct to Special_RDP on 3389

NAT Rule 2 - if the anyone is trying to attach to port 3389 then direct to 
General_RDP on 3389


I also have the matching Rules to allow 3389 to the IP address for RDP_Special 
and RDP_General


From a testing machine I verify that my General_RDP rule works and it does.  
Then I add my testing IP to the Special_People alias, clear all entries in the 
state table for this IP and connect again and I still go to the General_RDP 
pool.  I have the Special_People rule first in the list so I assume it should 
get tested first and pass and then at that point the rule processing finishes.

What am I missing???

Thanks,

Ron
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list