Can I serve DHCP on an IP alias in pfSense 2.0?
-
I am in the process of moving from Zentyal to pfSense 2.0, and I am using one capability that I can't seem to find in pfSense:
Here's my current setup:
-
The LAN interface has two IP addresses. One is an IP alias. Let's call them 10.1.1.1 and 192.168.1.1.
-
All the LAN servers are on 10.1.1.0/24. All our office computers have IP addresses in the 10.1.1.0/24 subnet.
-
The DHCP service for 10.1.1.0/24 ignores unknown MAC addresses. If it sees the MAC address for my laptop or my business partner's laptop, it assigns IP addresses in the 10.1.1.0/24 range.
-
DHCP grants IPs in the 192.168.1.1 range to unknown MAC addresses. That way, guests come in and use their laptop, they can access the internet, but their subnet mask prevents them from seeing our servers. The router/firewall is set up to not forward traffic between the 192.168.1.0/24 subnet and the 10.1.1.0/24 subnet
-
Due to problems that I have had with guests in the past, the 192.168.1.1 subnet is very limited in the ports that it can use to access the Internet. Basically, guests can use ports 80/443 to browse the web via http/https, retrieve and send mail via ports 25/143/993 etc, and do a few simple tasks like MSN messenger. They cannot run file sharing applications.
In this way, I can hook up my laptop and it works fine, but it a colleague uses his laptop, he can't do anything malicious. (I know he could manually set his IP address to the 10.1.1.0/24 range, but I'm assuming he's not that devious.)
FYI, here is the dhcpd.conf file that makes this all work:```
shared-network eth1 {subnet 10.1.1.0 netmask 255.255.255.0 {
option routers 10.1.1.1;
option domain-name-servers 10.1.1.1, 10.1.1.2;
}
group {
option routers 10.1.1.1;
option domain-name-servers 10.1.1.1, 10.1.1.2;
group {
host MYLAPTOP {
hardware ethernet MYMACADDRESS;
fixed-address 10.1.1.122;
}
host MYOTHERLAPTOP {
hardware ethernet ANOTHERMACADDRESS;
fixed-address 10.1.1.123;
}
}
}
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222, 208.67.220.220;
pool {
range 192.168.1.50 192.168.1.100;
}
}
group {
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222, 208.67.220.220;
}
}I do not have a VLAN enabled switch, but this setup seems to work. Now that I have moved to pfSense, if I manually edit /var/dhcpd/etc/dhcpd.conf, it works fine. However, I cannot figure out how to use the web interface to set the DHCP server to serve IPs in the 192.168.1.0/24 range (the IP alias). This means that as soon as I make a change, pfSense overwrites /var/dhcpd/etc/dhcpd.conf, and all my changes are lost. The only solution I can figure out is to turn off dhcp in the pfSense web interface, add dhcpd manually to /etc/rc, and then edit dhcpd.conf manually to do what I want to do. Is there a better way?
-
-
The DHCP server can only run on the primary subnet of an interface, though you can hack the source that generates the dhcpd.conf if you want to hard code something, grep dhcpd in /etc/inc/.
Mixing subnets on the same broadcast domain isn't recommended in any circumstances with any devices, properly segmenting the network is always best, whether VLANs, separate switches, etc.
-
Thank you for the advice. I'll look at hardwiring something in /etc/inc/.
I realize that mixing subnets is not the ideal situation, but I hesitate to buy extra hardware to accommodate the 10 or so visitors per year who come to the office and ask if they can hook up their laptop.
I also think it's rude to say "NO you can't hook up your laptop," since they let me hook up my laptop when I visit their office.
Assigning visitors an IP address on a different subnet with stricter rules is a cheap and easy way to avoid problems like visitors being able to browse our samba shares. It also would prevent problems like we had when a temp that we hired to help us with filing happened to have a torrent client running in the background on his laptop, and we got a DMCA notice because of an illegal download. Since only 5 or 6 ports are open from that subnet to WAN, the torrent client wouldn't have worked.
I know it won't stop the NSA or a malicious hacker, but that's not the kind of people we invite into our office anyway.