Hi Scott/List, I was actually the person who asked for this feature. I
have been testing it lately because I am about to use it in a test lab
(finally).
What I have found is that ONLY the MAC addresses listed can communicate
to the router. So if I have a PC that acquired an IP address from the
DHCP server that is not a static IP reservation, it cannot communicate
to the router. (The PC in question acquired the IP address BEFORE I
turned on the static arp feature). The 'arp -da' after turning off the
static arp feature does not fix the problem, only rebooting does. I am
wondering if it is an 'ipfw' rule that does not get removed.
I think it would be good to make this feature a bit more flexible. My
thoughts are as follows
Option 1. Only static DHCP entries can communicate to the router (the
behavior presently shown).
Option 2. Static ARP entries only for DHCP reservations while allowing
other IP addresses (say those assigned from DHCP pool) to be useable.
Some people might find Option 1 useful in a very controlled environment.
Option 2 would be useful in a situation like this. My IT department
controls a wireless lab where we trust and configure the laptops. We
would assign static DHCP reservations to these laptops and setup WPA2
between the laptops and AP. In the firewall, we could give elevated
privileges to these laptops, which say live in the 192.168.100.64/26
range with appropriate firewall rules applied to that network. The DHCP
server would give out addresses in the 192.168.100.128/26 which would
have a more restrictive firewall set applied to that network). The
static arp mappings help assure that other people won't steal an IP
address that has elevated privileges (192.168.100.64/26. Yes I am aware
you can fake a MAC address).
So I am proposing option 1 or 2 can be selected, each with different
behavior.
I am not sure how you implemented option 1, but option 2 would appear to
only be a matter of using the 'arp' command to make static arp mappings
or to delete them.
What do you think? I am willing to help code option 2.
-Original Message-
From: Scott Ullrich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 21, 2006 11:54 AM
To: Wesley K. Joyce
Subject: Re: [pfSense Support] DHCP Server - Enable Static ARP entries
http://www.pfsense.com/~sullrich/1.0-BETA1-TESTING-SNAPSHOT-2-20-06/
should have it.
That file was the only one that needs updating after the change.
On 2/21/06, Wesley K. Joyce [EMAIL PROTECTED] wrote:
I would like to do some further testing of this feature. Other than
the
services_dhcp.php, what other files should I review to see exactly
what
is
going on?
From: Scott Ullrich [mailto:[EMAIL PROTECTED]
Sent: Mon 2/20/2006 9:45 PM
To: support@pfsense.com
Subject: Re: [pfSense Support] DHCP Server - Enable Static ARP
entries
Stored in ipfw.
Do a ipfw show.
Scott
On 2/20/06, Wesley K. Joyce [EMAIL PROTECTED] wrote:
Glad to help. Out of curiosity, where does the pfsense/CP keep
the
MAC
address state information?
From: Scott Ullrich [mailto:[EMAIL PROTECTED]
Sent: Mon 2/20/2006 5:02 PM
To: support@pfsense.com
Subject: Re: [pfSense Support] DHCP Server - Enable Static ARP
entries
On 2/20/06, Wesley K. Joyce [EMAIL PROTECTED] wrote:
I was testing the static ARP feature in the DHCP. I see it
created
the
static arp entries, which I confirmed by executing a 'arp -an'
from
the
exec.php. When I turn off static arp entries, the permanent arp
entries
don't go away.
My immediate thought was all that needs to happen is an 'arp
-da',
but I
suspect that my interfere with whatever is going on with the
Captive
Portal?
On the other hand, arp entries could easily time out from the
arp
cache
way
before the idle or hard limit is reached in the CP. Obviously
the
arp
table
would be rebuilt as frames are sent So this seems to disprove
my
previous
statement.
So pfsense gods, what is required to get the disabling of static
arp
entries
to work without breaking anything else?
arp -da will work okay. I'll commit the fix, thanks for bringing
it
to my attention.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
