Security – Why are Wireless Networks more vulnerable to ARP Poisoning

Using the entire ip address space seems a bit excessive. Assuming you're talking about a contained environment (say behind a NAT) then you could use 10.0.0.0\8 without running into any routing related issues. Provided your actual network (ie the number of real machines) is small then the general problem of having a potentially huge broadcast domain is not really that relevant and if you set the lease time relatively low (a few minutes) you could ensure that it just wasn't practical for a single attacker to actually exhaust your range. However you would still have to fend off what might be a relatively large amount of traffic with millions of fake requests and it will be broadcast traffic remember so all the genuine devices on your network will see it too - so lots of spurious noise for everyone on the network to have to handle interrupts from. Your switches will start tracking all of these [fake] MAC\IP-address combinations now too so you're allowing your attacker to increase the amount of resources they consume, and those are finite too. For a serious attack I reckon DHCP exhaustion attack code probably push out requests faster than many DHCP servers can deal with if the scope is actually huge - the physical resources (CPU & RAM needed to handle the responses and tracking the table of active leases) on the DHCP server may eventually simply get consumed if the attacker can generate requests fast enough and the end result may be worse for you - you've now swapped a Denial of Service attack against new connections with an attack that might crash your DHCP server and Switches (and those might be exploitable).

If this is a valid concern, and you can't live with the possibility of DoS against clients you should use switches that have mechanisms to prevent this - there are specific DHCP starvation mitigation mechanisms like DHCP Snooping but just enabling controls to limit MAC address spoofing will generally help in this and also in CAM table flooding. The best approach is to enable port authentication but that is hard to implement in any large controlled environment and no use in an unmanaged scenario (such as a WiFi Hotspot). I don't believe there's a definitive general purpose solution, it's a case of balancing the risks of the various options available and selecting the one that works best in your environment.

You can keep pfSense doing that. WAN should always point to the side where your default gateway resides. The other network can stay OPT1 or be LAN. Then configure your rules accordingly so users can only hit your VPN and the Internet. May want to disable NAT in that scenario so the edge RVS4000 sees the true source IPs (Enable advanced outbound NAT, delete auto-added rule). Will need static route on RVS4000 in that case.