So what do you think about the solution. Will it be taken into the packetfence
code or will there be another solution to this problem?
The solution again here:
Put a "sleep $pf::config::Config{'trapping'}{'wait_for_redirect’};” somewhere
before updating the ipset rules (e.g. in the performInlineEnforcement or
update_mark method).
Kind regards
Christian Hanster
> On 05 Dec 2015, at 21:27, Christian Hanster <[email protected]> wrote:
>
> So I found a solution, which perhaps can be taken into the packetfence code.
>
> In the configuration of packetfence you can configure the time before the
> VLAN is changed (wait_for_redirect). This time is not used for the inline
> mode though and it seems that this is the problem. If you use this time (1s
> is enough) in the performInlineEnforcement (inline.pf) method before doing
> “update_mark” or in the update_mark (iptables.pm) method, the problem is
> solved. Perhaps this solution can be taken into the packetfence code.
>
> Kind regards
> Christian Hanster
>> On 02 Dec 2015, at 23:10, Christian Hanster <[email protected]> wrote:
>>
>> Hello everybody,
>>
>> I’m facing another strange issue. After registration of an user, the portal
>> should forward to the /access page to then forward to the URL entered before
>> the portal came up. However this is not working everytime in the setup (only
>> in around 20% of the cases). Otherwise the client is registrated and can
>> access the internet but he is not forwarded properly and the session times
>> out and then cannot be access the webpage because it has no registration DNS
>> anymore.
>>
>> My setup is as follows. Client —VPN-Router -Internet- VPN-Server — PF. For
>> those clients Packetfence is configured in inline mode Layer 3. The server
>> is running in an active_active cluster configuration because it is also
>> serving some VLAN stuff.
>>
>> I did some research on my own and I find a strange thing when I was doing
>> sniffing with wireshark. In those sessions where it was not working, the
>> apache-portal was not replying with the cluster IP but local IP
>> (192.168.2.250). In those cases it was working the apache replied with its
>> cluster IP (192.168.2.254). For better understanding I have attached the
>> sniffed file with both cases (Packet 1-14 not working and Packet 15-22
>> working). I have really no idea why the server is acting like that. I also
>> could not find any hint in the portal.error.
>>
>> I hope you can give me a suggestion what it could be…
>> <Capture PF redirect.pcapng>
>>
>>
>> Kind regards
>> Christian
>> Hanster------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140_______________________________________________
>> PacketFence-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
