This exercise demonstrates VLAN enforcement: where PacketFence controls switch ports but traffic does not pass through the PacketFence server.
To configure this, each group's VM will manage the ports on an edge switch.
In a real campus you would only need one PacketFence server to control all the edge switches.
+---+ +--------+ +--------+
| |eth0 -------------------| |vlan X2 --------| |
| |10.10.0.X 10.10.0.254| |10.X.2.254 | |
|vmX|eth0.X5 ----------------| CORE |vlan X3 --------| EDGE |--PC
| |10.X.5.1 10.X.5.254| ROUTER |10.X.3.254 | SWITCH |
| |eth0.X6 ----------------| |vlan X4 --------|(*) |
| |10.X.6.1 10.X.6.254| |10.X.4.254 | |
+---+ +--------+ +--------+
(*)mgmt 10.X.4.253Each edge switch has a trunk uplink into the central switch/routing infrastructure. For edge switch X, the VLANs provided on this trunk will be:
Core routing has already been configured for those VLANs, and an ACL to block traffic from X2 to X3 to everything except DHCP broadcasts and traffic to your PacketFence VM.
Also, DHCP forwarding has been enabled from X2 and X3 to your PacketFence VM. The DHCP service for X4 is the class central DHCP service.
To save class time, this will have been pre-configured by the instructor.
But you should verify the switch's configuration. Check you can reach the switch on its routed management address 10.X.4.253.
In the case of a Netgear GS108Tv2 or GS110TP, you need to go to the web interface http://10.X.4.253/ and check:
System > Management > IP Configuration
System > SNMP > SNMP V1/V2
Trap Configuration will show trap destination(s) and communitiesTrap Flags will show which traps are enabled (unless you have a switch which supports security traps, you should enable Link Up/Down and MAC Learning traps)Switching > VLAN > Advanced
VLAN Configuration will show the available VLANsVLAN Membership can be used to show for each VLAN which port(s) it is enabled on. Click on the word "PORT" (not on the checkbox beside it) to expand into a port list. T = Tagged, U = Untagged.Port PVID Configuration shows for incoming untagged frames on a given port, which VLAN they are put intoCheck which interfaces dhcpd and pfdns are listening on:
# ps auxwww | grep dhcpd
dhcpd 2135 0.0 0.1 5040 2096 ? Ss 13:15 0:00 /usr/sbin/dhcpd -lf /usr/local/pf/var/dhcpd/dhcpd.leases
-cf /usr/local/pf/var/conf/dhcpd.conf -pf /usr/local/pf/var/run/dhcpd.pid eth0.X5 eth0.X6
# netstat -naup | grep :53
udp 0 0 10.X.5.1:53 0.0.0.0:* 1896/pfdns
udp 0 0 10.X.6.1:53 0.0.0.0:* 1896/pfdnsThe dhcpd interfaces are on the end of the command line; you can see here the daemon is only listening on eth0.X5 and eth0.X6.
Similarly, pfdns is listening on the IP addresses of those interfaces (10.X.5.1 and 10.X.6.1).
Neither daemon is listening on your main interface (eth0, 10.10.0.X), so any DHCP or DNS packets sent to 10.10.0.X will not be answered.
In our campus environment, our clients are going to be on registration and isolation networks which are across the campus core router, and not connected directly to the PacketFence box. For this exercise they are 10.X.2.0/24 and 10.X.3.0/24, but in general there could be many (one for each building).
This implies several things.
From your PF VM you should be able to ping 10.X.5.254 and 10.X.6.254 (the core router)
interface <ifname>.X2
ip helper-address 10.X.5.1Similarly, the isolation networks will relay DHCP requests to 10.X.6.1.
When clients connect, they will get this fake DNS server, which regardless of what page they request, will redirect them to the portal
Your PacketFence VM will act as the DHCP server for the Registration and Isolation subnets, 10.X.2.0/24 and 10.X.3.0/24. However it is not directly connected to those subnets, and you need to tell it about them so it can create a DHCP pool for each network.
This can be done via the web interface:
Configuration, then underneath NETWORK click InterfacesAdd routed network
However when doing bulk additions it's easier to edit conf/networks.conf directly.
Check the contents of this file:
# cd /usr/local/pf
# cat conf/networks.confIt should look like this:
[10.X.5.0]
dns=10.X.5.1
dhcp_start=10.X.5.10
gateway=10.X.5.254
domain-name=vlan-registration.ws.nsrc.org
named=enabled
dhcp_max_lease_time=30
dhcpd=enabled
type=vlan-registration
netmask=255.255.255.0
dhcp_end=10.X.5.246
dhcp_default_lease_time=30
[10.X.6.0]
dns=10.X.6.1
dhcp_start=10.X.6.10
gateway=10.X.6.254
domain-name=vlan-isolation.ws.nsrc.org
named=enabled
dhcp_max_lease_time=30
dhcpd=enabled
type=vlan-isolation
netmask=255.255.255.0
dhcp_end=10.X.6.246
dhcp_default_lease_time=30
[10.X.2.0]
dns=10.X.5.1
next_hop=10.X.5.254
gateway=10.X.2.254
dhcp_start=10.X.2.10
domain-name=vlan-registration.ws.nsrc.org
named=enabled
dhcp_max_lease_time=30
dhcpd=enabled
netmask=255.255.255.0
type=vlan-registration
dhcp_end=10.X.2.246
dhcp_default_lease_time=30
[10.X.3.0]
dns=10.X.6.1
next_hop=10.X.6.254
gateway=10.X.3.254
dhcp_start=10.X.3.10
domain-name=vlan-isolation.ws.nsrc.org
named=enabled
dhcp_max_lease_time=30
dhcpd=enabled
netmask=255.255.255.0
type=vlan-isolation
dhcp_end=10.X.3.246
dhcp_default_lease_time=30Restart the dhcpd service, either via the web interface (Status > Services) or the command line:
# cd /usr/local/pf
# bin/pfcmd service dhcpd restartAlso check the auto-generated config for the DHCP server:
# cd /usr/local/pf
# cat var/conf/dhcpd.confYou should see that there is a subnet declaration for the locally-attached registration and isolation VLANs, and a subnet declaration for each remote network.
Configuration and under the subheading "NETWORK" Click SwitchesAdd switch
Again, once you have one suitable switch, this can be replicated in conf/switches.conf
Check the contents of this file:
# cd /usr/local/pf
# less conf/switches.confIt should start with some defaults inherited by all switches, then have a sample switch 192.168.0.1 (you can remove this in a production network), then have the settings for the switch you added:
[10.X.4.253]
SNMPCommunityRead=<community>
SNMPCommunityWrite=<community>
defaultVlan=X4
deauthMethod=SNMP
description=edge switch X
SNMPVersionTrap=2c
type=Netgear::GS110
macDetectionVlan=4000
VoIPEnabled=N
isolationVlan=X3
SNMPVersion=2c
uplink=1
SNMPCommunityTrap=<community>
registrationVlan=X2
mode=production
#plus some commented-out SNMP version 3 settingsOn your VM, run tcpdump:
# tcpdump -i eth0 -nnev -s0 udp port 162Plug a laptop into one of the managed switch ports. Check that you receive an SNMP trap, it should look something like this:
11:59:00.425875 1e:23:72:2f:5c:ed > 52:54:1d:97:4d:6e, ethertype IPv4 (0x0800), length 164: (tos 0x0, ttl 63, id 412, offset 0, flags [none], proto UDP (17), length 150)
10.X.4.253.1025 > 10.10.0.X.162: { SNMPv2c C=NetManage { V2Trap(104) R=9
.1.3.6.1.2.1.1.3.0=144900 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.6.3.1.1.5.4
.1.3.6.1.2.1.2.2.1.1.2=2 .1.3.6.1.2.1.2.2.1.7.2=1 .1.3.6.1.2.1.2.2.1.8.2=1 } }Look in your packetfence log, e.g. to check the last 25 lines:
# cd /usr/local/pf
# tail -25 logs/packetfence.logMixed in with the logs you should see something like this:
Mar 26 11:59:02 pfsetvlan(1) INFO: up trap received on 10.X.4.253 ifIndex 2 (main::handleTrap)
Mar 26 11:59:02 pfsetvlan(1) INFO: setting 10.X.4.253 port 2 to MAC detection VLAN (main::handleTrap)
Mar 26 11:59:02 pfsetvlan(1) WARN: Should set ifIndex 2 to VLAN 4000 but the switch is not in production -> Do nothing (pf::SNMP::setVlan)This is good. Remove the laptop, go back into the web interface and change the switch from "Testing" to "Production". Restart packetfence and start a continuous tail running on the logfile:
# bin/pfcmd service pf restart
(this may take a minute or so)
# tail -f logs/packetfence.logNow reconnect the laptop and watch for activity again.
Mar 26 12:04:30 pfsetvlan(3) INFO: up trap received on 10.X.4.253 ifIndex 2 (main::handleTrap)
Mar 26 12:04:30 pfsetvlan(3) INFO: setting 10.X.4.253 port 2 to MAC detection VLAN (main::handleTrap)
Mar 26 12:04:30 pfsetvlan(3) INFO: MAC: xx:xx:xx:xx:xx:xx is of status unreg; belongs into registration VLAN (pf::vlan::getRegistrationVlan)Check in the switch's web interface that it has changed the port. (For Netgear: Switching > VLAN > Advanced > Port PVID Configuration)
It should now be in the registration VLAN (X2)
At this point, the laptop will be sending DHCP requests. They should be forwarded to your VM. You will be able to see them if you start tcpdump before plugging in the laptop:
# tcpdump -i eth0 -nnev -s0 udp port 67 or udp port 68If they are not arriving, check that:
Now the client device should have picked up an IP address on the 10.X.2 subnet (registration). Open a web browser and try to go to any web page, e.g. http://nsrc.org/. You should be redirected to your VM's portal and asked to login.
PacketFence has a local SQL database where you can create temporary user accounts, e.g. for guests, without having to add them into your main authentication server (Active Directory or whatever).
In the PacketFence admin web interface:
Users > CreateSet Role / Default alone, but click the Plus sign to the right of this.Set access duration / 1 hourCreate UsersNow back on the laptop, you should be able to login using this username and password. Remember to tick the box to accept the terms and conditions.
If everything is working you should be switched into the default (data) VLAN and be redirected to the page you originally requested.
In the web interface, navigate to Nodes to see the list of detected devices. Note how the OS (DHCP) type is blank.
Now select Configuration > Identification > Fingerprints then Update Fingerprints.
This downloads a database allows PF to identify the host OS from its DHCP query.
Return to Nodes to see the updated list of detected devices.
If you want to see the captive portal again, you can forcibly de-register a node. You can do this in the web interface in one of two ways:
Nodes, click the checkbox next to the registered nodes, click the Action menu and select 'Deregister'Users, click on the user of interest, go to the Devices tab, click on the MAC address, then change the status to unregisteredIn either case, the user should be immediately kicked off (watch the port light - it should go off for 4 or 5 seconds) and forced to re-register when they next open a web page.