On Fri, Sep 21, 2012 at 05:09:35PM +0000, Brian Candler wrote: > Why does PF need three different local IP addresses and subnets, if they are > all routed together by the infrastructure anyway?
I didn't get an answer, so please let me give a little background to what I'm trying to achieve. Last week I was at a large university in Ghana, and one of the tasks was to help them deploy PacketFence. They have a fully-routed network: clusters of buildings are linked to a distribution router, each distribution router has fibre links to two core routers, and they talk OSPF. There are a large number of subnets, and we didn't want to break the design by trunking VLANs all over the place. The external link is 155Mbps (flatlining all through working hours), so we definitely don't want PacketFence inline. We set up a CentOS box on a server network, linked from a core router, configured it up and managed to get it controlling a couple of ports on a 2960 edge switch. As I say, the installation instructions for such a routed network are far from clear. So we gave the PF server a single IP address. We built isolation and registration subnets on each distribution router, using 10.X.254.0/24 and 10.X.255.0/24 respectively, and applied ACLs there so that those networks could only ping the PF box and nothing else. Now, the message from Francois at http://sourceforge.net/mailarchive/message.php?msg_id=29866732 says that the packetfence server needs three different IP addresses; furthermore it says they have to be on three different subnets and in three different VLANs. If that's true then I would like to understand why. This is because (a) I want to document it; (b) it will involve changing what we already built, and (c) it will add extra complexity, which I would prefer to avoid unless it's justified. For example, even if we really do need three IPs on this server, could they not just be three IPs on the same subnet? I cannot see any reason for VLANs here, given that they would all connect into the same core router anyway. In trying to understand whether this is actually necessary, I started looking at the daemon configs. (1) There is only a single instance of namedk. It uses views with match-clients { } to distinguish requests from isolation source IPs and registration source IPs. This all works fine. We get the right DNS responses for queries from those subnets. So I can't see why it would need multiple interfaces/VLANs. (2) There is one instance of httpd. It is bound to 0.0.0.0:80 and 0.0.0.0:443. captive-portal-common.conf has "allow from ... " and the IP blocks of the isolation and registration IPs. Again, this all appears to work fine, so I don't see Apache needing multiple interfaces. (3) dhcpd is listening on 0.0.0.0:67. It has a subnet {} declaration for each isolation/registration network, and doesn't care what local IP address the relayed packets arrive on. However to get it to start, I also had to add an empty subnet {} declaration for its locally-attached subnet. This was my first inkling that maybe something isn't how the designer's intended. (4) Now this is where things get murky for me. pfdhcplistener is running (two instances?!) but I don't understand exactly what traffic it needs to see. Does it need to see DHCP packets from production subnets only? What if it also sees DHCP activity from isolation and registration subnets? I can imagine that VLANs could be used to separate the DHCP traffic, but actually looking in the code for sbin/pfdhcplistener I see $interface_vlan only used in one place: if ($is_inline_vlan) { locationlog_synchronize($interface_ip, $NO_PORT, $interface_vlan, $dhcp->{'chaddr'}, $NO_VOIP, $INLINE); $accessControl->performInlineEnforcement($dhcp->{'chaddr'}); } So it looks like this is only relevant for inline enforcement. Like I say, the functions implemented by pfdhcplistener are unclear to me. Logs do suggest something isn't working quite right: Sep 23 03:29:45 pfdhcplistener(27528) INFO: DHCPREQUEST from 00:22:68:xx:xx:xx (10.21.255.14) (main::parse_dhcp_request) Sep 23 03:29:45 pfdhcplistener(27532) INFO: DHCPREQUEST from 00:22:68:xx:xx:xx (10.21.255.14) (main::parse_dhcp_request) Sep 23 03:29:45 pfdhcplistener(27528) INFO: could not resolve 10.21.255.14 to mac in ARP table (pf::iplog::ip2macinarp) Sep 23 03:29:45 pfdhcplistener(27532) INFO: could not resolve 10.21.255.14 to mac in ARP table (pf::iplog::ip2macinarp) Sep 23 03:29:45 pfdhcplistener(27532) WARN: could not resolve 10.21.255.14 to mac (pf::iplog::ip2mac) Sep 23 03:29:45 pfdhcplistener(27528) WARN: could not resolve 10.21.255.14 to mac (pf::iplog::ip2mac) Sep 23 03:29:45 pfdhcplistener(27532) WARN: unable to resolve 00:22:68:xx:xx:xx to ip (pf::iplog::mac2ip) Sep 23 03:29:45 pfdhcplistener(27528) WARN: unable to resolve 00:22:68:xx:xx:xx to ip (pf::iplog::mac2ip) Apart from the fact that there are two daemons active, I do wonder how it's trying to resolve IPs to MACs. Obviously the local ARP table is no use for a routed network. (5) snmptrapd listens on 0.0.0.0:162, and pfappserver_server.pl on 0.0.0.0:6361. Neither seems to worry about multiple interfaces. (6) There are other daemons pfmon, pfsetvlan, pfdetect which appear to read log files or pipes rather than listen on network interfaces. Now, we got PacketFence running very late in the week, but it *does* seem to be working when given some basic testing. Users get captive portal for registration, access is granted, when snort triggers on P2P then they are put into isolation, they can remove themselves from isolation. Which brings me back to the original question: do we really need to put three IPs, three subnets and three VLANs onto the PF box? What will break if we don't do this? Thanks, Brian. ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
