Regarding FAQ entry "Active Directory login while in the registration VLAN":
Make sure you do *not* have a wildcard A record for Active Directory's DNS subdomain. This would break _sites.DomainDnsZones and the like. To support Mac/Linux krb5 clients and to avoid timeouts, allow ports 88,389,636 for both UDP and TCP. The FORWARD chain defaults to DROP. So you need to duplicate the custom -A input-internal-vlan-if rules, or maybe define a new named chain that gets appended to both input-internal-vlan-if and FORWARD. I don't think we want all of input-internal-vlan-if chain allowed for FORWARD. Something like: -A input-internal-vlan-if --protocol udp -m multiport -d (dc) --dports 88,389,636,137,138 -j ACCEPT -A input-internal-vlan-if --protocol tcp -m multiport -d (dc) --dports 88,389,636,139,445 -j ACCEPT -A FORWARD -i eth1 -s (registration) -d (dc) -p udp -m multiport --dports 88,389,636,137,138 -j ACCEPT -A FORWARD -i eth1 -s (registration) -d (dc) -p tcp -m multiport --dports 88,389,636,139,445 -j ACCEPT -A FORWARD -i eth1 -s (isolation) -d (dc) -p udp -m multiport --dports 88,389,636,137,138 -j ACCEPT -A FORWARD -i eth1 -s (isolation) -d (dc) -p tcp -m multiport --dports 88,389,636,139,445 -j ACCEPT Next, not everyone has to worry about this, but I happen to have my domain controller, the PF management web interface, and the PF server interface closest to the domain controller on 3 different firewall interfaces. Loops, asymmetric routing, and leaks (firewall bypass) are possible if we're not careful. To ensure that packets in a flow go in and out the same interface, use route tables. In this example: 10.1.1.0/24: Registration 192.168.1.0/24: Isolation 172.16.1.0/24: Production network including the DCs 172.16.1.1: PacketFence server internal router interface 172.16.1.254: Router facing PF internal router interface 172.17.1.1: PacketFence server management interface 172.17.1.254: Router facing PF management interface Tell your router to use PF as gateway to the reg/isolation networks. In Cisco-speak: ip route 10.1.1.0 255.255.255.0 172.16.1.1 ip route 192.168.1.0 255.255.255.0 172.16.1.1 # edit /etc/iproute2/rt_tables to include: 200 ROUTE10 201 ROUTE172 # There's probably a more "correct" way to do this, but I put # it in /etc/rc.local. # Make sure that traffic is routed out the correct interfaces, # to avoid asymmetric routing. ip rule add from 10.1.1.1/24 to 172.16.1.0/24 table ROUTE10 ip rule add from 192.168.1.0/24 to 172.16.1.0/24 table ROUTE10 ip rule add from 172.16.1.1 to 172.16.1.0/24 table ROUTE10 ip route list table ROUTE10 ip rule add from 172.17.1.1 to 172.16.1.0/24 table ROUTE172 ip route list table ROUTE172 ip route add default via 172.16.1.254 table ROUTE10 ip route add default via 172.17.1.254 table ROUTE172 ip rule ls ip route flush cache Wouldn't it be much easier just to NAT instead of route? Yes. But then your logs are wrong. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
