Re: [PacketFence-users] Email Registration Link doesn't work from inline interface

[Gavin P. <gp...@gr...>]

I'm still unsure where the process was breaking down, but I devised a work-around using iptables.  I installed tcpdump and could indeed see the packets hitting my server as coming from inline interface, through the internet, through our main firewall to the management interface of the PacketFence.  I'm not savvy enough with iptables to set up logging that would indicate packets being dropped, or perhaps apache was blocking access somehow?

Anyway the fix for me is as follows...

Edit the iptables.conf for PacketFence /usr/local/pf/conf/iptables.conf
Find the line %%nat_prerouting_inline%% and insert a new line for each inline interface pair (I have 12 total) that redirects traffic from the server's inside inline interface that is destined to the public address of the PacketFence server to hit the server's inside address instead (the default gateway address of the PacketFence server for each inline pair)  The section of the iptables.conf looks like this (addresses changed in example):

*nat
:PREROUTING ACCEPT [0:0]
:prerouting-int-inline-if - [0:0]
:postrouting-inline-routed - [0:0]
:postrouting-int-inline-if - [0:0]
:prerouting-int-vlan-if - [0:0]
%%nat_prerouting_inline%%
-A PREROUTING -d 44.55.66.77/32 -i inside.101 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.101.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.102 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.102.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.103 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.103.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.104 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.104.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.105 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.105.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.106 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.106.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.107 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.107.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.108 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.108.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.109 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.109.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.110 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.110.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.111 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.111.1:443
-A PREROUTING -d 44.55.66.77/32 -i inside.112 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.112.1:443
%%nat_prerouting_vlan%%

restart iptables using:
/usr/local/pf/bin/pfcmd service iptables restart

Hope this helps others that may have the issue, though my config might be somewhat unusual.


--------------------------------------------------
Gavin Pyle
Network Engineer
Green River College
gp...@gr...<mailto:gp...@gr...>
[http://www.greenriver.edu/Images/news/captions/2013-gator-logo-300.jpg]

From: Louis Munro [mailto:lm...@in...]
Sent: Friday, July 10, 2015 11:48 AM
To: pac...@li...
Subject: Re: [PacketFence-users] Email Registration Link doesn't work from inline interface


On Jul 10, 2015, at 12:49 , Gavin Pyle <gp...@gr...<mailto:gp...@gr...>> wrote:


User registers and selects Register by Email.
The node is marked registered with a deregister time of 10 minutes in the future.
The node can now access the internet and check for the email.
The email is received, the user clicks on the link but nothing happens and eventually the connection attempt times out.

tcpdump and the logs are your new best friends:



  *   Does the tcp connection reach the management IP and sucessfully handshakes?
  *   If so, does the httpd.portal process see that connection? What does the access log say about it?

Either the connection is never established to the server in the first place, or it does make it to the packetfence server but is :


  *   never seen by the httpd process because of iptables, routing or such

or

  *   httpd does see it but it either does not reply because it's not configured to or because of an error.


The fact that you are not seeing an http 500 error or something like this shows that the link is not being rejected by PacketFence.


Try to eliminate the above possibilities.
Whatever remains will be the answer.


Regards,
--
Louis Munro
lm...@in...<mailto:lm...@in...>  ::  www.inverse.ca<http://www.inverse.ca>
+1.514.447.4918 x125  :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and PacketFence (www.packetfence.org<http://www.packetfence.org>)