Mark, I think you would be best served by option 2 (filtering bridge). However, as you mentioned traffic shaping may be an issue, I have no clue if this setup is compatible or not. Even if traffic shaping is NOT compatible, at least this option is better than option 1 (no traffic shaping OR filtering). Remember if you use the same switch for both your LAN and DMZ, use VLANs (or use separate switches). Otherwise, your customer would be able to access your LAN.
With option 3, you can use 1-1 address mappings. Many VPNs can work through NAT, for Cisco IPSEC, you can use NAT-T. Windows 2003 also supports NAT-T for server side although it is not recommended by MS. Of course NAT is generally only a problem after the first tunnel, if your customers will run a single tunnel (point-to-point), NAT should be a non-issue. For a road-warrior setup (point-to-multipoint), NAT-T would be required. My personal experience with NAT-T is limited to the client-side. On Dec 4, 2007 12:52 PM, Mark Crane <[EMAIL PROTECTED]> wrote: > I'm working with a small wireless network with a 3mb connection to the > internet the majority of the wireless clients are behind the LAN > interface using DHCP. I have a couple customers that want static real > world IP Addresses. I would like to maintain ability to monitor and have > some control of the network to prevent one of these customers from using > all the bandwidth. These customers will add their own firewall to > provide their own VPN connections and other firewall related tasks. > > Here are the options that I can see. > > Option 1 > a. By pass the pfSense firewall. > Cons: Gives up monitoring and control of the customers that will be > given the static IP addresses. > > Option 2 > a. Add a new network card. > b. Bridge with the WAN. > c. Plug the new card into the switch that connects to the wireless > network along with the LAN. > Pros: In theory the traffic might show up on the WAN graph. > Cons: As far as I'm aware this is not compatible with traffic shaping. > > Option 3 > a. Add a new network card. > b. Create a subnet for the DMZ and use NAT > c. Setup rules to make the DMZ wide open in both directions > Pros: This method would work with traffic shaping. > Cons: I'm a little worried about this causing unknown problems with the > customers VPNs any advice? > > I would appreciate any comments! Which of these options or other options > not mentioned here would be the best practice? > > Thanks in advance. > > P.S. I'm working on the freeradius package so that it can be pointed to > an external database server from the pfSense freeradius package GUI. > I will share the changes if anyone is interested when it is completed > and tested. > > Best Regards, > Mark > > > >
