Ok Ermal, I would try to do it in next weeks. Should I port the relevant modifications to the mainstream (2.1) or can I patch the release I am currently using (a slightly customized 2.0.1)?
Stefano On Fri, Nov 23, 2012 at 10:19 PM, Ermal Luçi <[email protected]> wrote: > > > > On Fri, Nov 23, 2012 at 5:12 PM, Stefano Busanelli <[email protected]>wrote: > >> Thank you Ermal, >> >> I moved my attention of the pfsync setup and I find a configuration >> error. Now I have fixed it and the system is working as expected (seamless >> failover). >> >> > The best is to share code so you do not have to maintain it youself if it > gets merged :). > > >> Stefano >> >> On Thu, Nov 22, 2012 at 2:33 PM, Ermal Luçi <[email protected]> wrote: >> >>> >>> >>> >>> On Thu, Nov 22, 2012 at 12:52 PM, Stefano Busanelli <[email protected]>wrote: >>> >>>> Dear all, >>>> >>>> at best of my knowledge CARP/pfsync can be used in a truly seamless >>>> manner (for a client perspective) only when pfSense acts as a mere >>>> firewall, but it does not work seamlessly when pfSense acts as a captive >>>> portal, for two reasons: >>>> 1) the database of the authenticated users is not synced across the >>>> gateways of a CARP cluster and for this reason a used should >>>> re-authenticate after a failover; >>>> 2) the ipfw firewall is not supported by pfsync. >>>> >>>> In order to find a workaround to this situation I have written some PHP >>>> code that leveraging on XMLRPC allow to synchronize the authenticated user >>>> database and the ipfw rules across the two gateways (by using a direct link >>>> between them, used also by pfsync). However, I am still not able to achieve >>>> a really seamless failover between the master and the backup node. In other >>>> words, an authenticated user that is watching a Youtube video before the >>>> failover, after the failover he still remains authenticated, but he has to >>>> reload the Youtube video. >>>> >>>> In my opinion, the real bottleneck is ipfw, but maybe I am missing some >>>> points. Do you have some ideas? >>>> >>>> No its not ipfw. >>> You should check if you load tables as well during the sync in ipfw. >>> ipfw as used by CP is stateless so it does not care at what state a >>> connection is. >>> >>> Either the table information is not there or pfsync state is not correct >>> in pf(4). >>> >>> >>>> -- >>>> Stefano* >>>> * >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> List mailing list >>>> [email protected] >>>> http://lists.pfsense.org/mailman/listinfo/list >>>> >>>> >>> >>> _______________________________________________ >>> List mailing list >>> [email protected] >>> http://lists.pfsense.org/mailman/listinfo/list >>> >>> >> >> >> -- >> Stefano* >> * >> >> >> >> >> _______________________________________________ >> List mailing list >> [email protected] >> http://lists.pfsense.org/mailman/listinfo/list >> > > _______________________________________________ > List mailing list > [email protected] > http://lists.pfsense.org/mailman/listinfo/list > > -- Stefano* *
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
