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
[email protected]<mailto:[email protected]>
[http://www.greenriver.edu/Images/news/captions/2013-gator-logo-300.jpg]
From: Louis Munro [mailto:[email protected]]
Sent: Friday, July 10, 2015 11:48 AM
To: [email protected]
Subject: Re: [PacketFence-users] Email Registration Link doesn't work from
inline interface
On Jul 10, 2015, at 12:49 , Gavin Pyle
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]> ::
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>)
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
