HELP! Need to know Best/How-to give clients WAN IP's from ISP via pfsense



  • Hello!

    I hope I am posting in an appropriate place for my question. Basically in a nut shell, we have a client who
    owns an executive suite. He wants to provide his tenants with WAN ip's in which he has requested static IP's
    from his ISP (around 125 available).  By giving them WAN ip's directly, it forces them to be responsible for firewalling etc
    and would likely see that customers get their own routers within the office suites. So, what's the best way to accomplish this
    with pfsense? I have my own ideas but unsure of the best appropriate method. Can someone point me to the best way to do so?

    Here are a few crucial details:

    -There are aprox 83 offices and 125 available WAN ip's (Each office is small so likely not more than 5 PC's per office)
    -We will need to utilize features such as bandwidth shaping and priority for folks running VOIP over the internet (skype etc)
    -We do not want to restrict the clients in any way (DMZ like) so there would be no need for firewall rule implentation (except perhaps keeping known P2P out)

    -The facility is very modern and has very nice 3com switches with very nice hardware & GB capabilities
    -The current system is using VLAN and addressing the customers with LAN ip's.
    -We intend to implement failover pfsense with another physical pfsense unit

    If anyone has the time and can help me out I would be greatly appreciated.

    SNE - Local Engineering Firm
    THANKS FOR ANY HELP!



  • Couple things I forgot sorry:

    -We need the clients to obtain these WAN ip's via DHCP (relay or not)
    -We would like to find a way to ensure no other client can talk to any other client through subnetting
    (possibly more a question aimed at our ISP for segregating the subnets of our statics) VLAN would be suitable
    if subnetting is not as efficient.


  • Rebel Alliance Developer Netgate

    @intracoastalacs:

    -We need the clients to obtain these WAN ip's via DHCP (relay or not)

    This is traditionally done by having one IP outside of that subnet for the actual WAN IP on pfSense, and then the other IPs in a separate subnet, routed to that other WAN IP. You can then set an IP out of your big subnet on the LAN side, and use it for DHCP and such.

    @intracoastalacs:

    -We would like to find a way to ensure no other client can talk to any other client through subnetting
    (possibly more a question aimed at our ISP for segregating the subnets of our statics) VLAN would be suitable
    if subnetting is not as efficient.

    That is harder to pull off. You will need to use VLANs no matter what, but if you choose to separate them by subnet, that means using /30's at a minimum which will mean you use 4 IPs for every one customer. It's better to use a switch that supports "private" VLANs which ensure that a port can only talk to its gateway and not other client ports.



  • This is traditionally done by having one IP outside of that subnet for the actual WAN IP on pfSense, and then the other IPs in a separate subnet, routed to that other WAN IP. You can then set an IP out of your big subnet on the LAN side, and use it for DHCP and such.

    Thanks for the reply.  Can you give me more detail in what you mean? Thanks!



  • I originally thought that would be the most likely path.  My customer wants to be more like an ISP. Deliver the internet, and the rest is up the customer. So If I am understanding you correctly, you would say

    SETUP 1 WAN IP on the RED(WAN) of pfsense.
    Then Setup the DHCP server to address the clients the range of WAN ip's.
    Thus then each client would get a WAN ip and still pass through the pfsense.
    As far as segregating them, are there no isolation methods available?  
    –(referencing a feature like from DDWRT called AP Isolation which keeps clients from talking to other clients)

    Could we segregate by means of denying rules with the firewall ? aka DENY LAN to LAN (range only)


  • Rebel Alliance Developer Netgate

    AP isolation only works because wireless functions at the same level that a switch does when working physically. If these were wireless clients, the same function would work on pfSense if it were acting as an AP (Just don't check the box that allows communication between wireless clients). However when using physical ethernet, that is a function of the switch.

    You seem to be mixing the terms WAN IP and Public/Routable IP address. Let me see if this will clear things up, using some example IPs:

    Your ISP should give you one IP address for the WAN of pfSense that has nothing to do with the large block of IPs for customers, we'll call this 10.10.10.2, and that goes on the WAN side of pfSense.

    Your ISP would then route your large block of public IPs, we'll call this 172.16.16.0/25, to your single WAN IP - 10.10.10.2.

    On the LAN side, pfSense gets 172.16.16.1/25 for its LAN IP, and you set the DHCP range for 172.16.16.2-172.16.16.126

    You would then setup your managed switch to use Private VLANs, designating the port for pfSense LAN as the gateway, so that each client port can only communicate with the gateway itself.

    Then you can use rules to block traffic coming from your client address pool, so that it cannot reach other IPs in the client address pool.

    You could do this with separate VLANs for each client, but you would need to use a /30 for each one and lose a lot of IPs in the process. For example, with a /25 you get 125 usable client addresses (128 in the subnet, less the null route and broadcast, and one for pfSense). If you setup VLANs/subnets you would only be able to use 32 IPs – A lot of wasted space.



  • Great!  I understand completely. It looks as if VLAN is the only suitable route to go. I just thought perhaps there was a better way using traditional subnetting. The reason I am concerned about VLAN is because, then it adds an extra level of administration to assign the VLAN to the proper ports and, suppose a client took their laptop to the lobby or one of the conference rooms.  They might not have access to their office suite being that the VLAN A for conference room will not communicate with VLAN B in the users office. I suppose we could provide small inexpensive routers for the customers to place in their own office with simple VPN capabilities.

    Thank you so much for the time in explaining.  The path you suggested was the path I assumed but I generally like to assume I know nothing and keeps me learning new stuff.

    As far as the CIDR of the network I suppose it will be a moot point if I go with VLAN.

    One more thing, Would I be able to use traffic shaping at a granular level of the 'routable public IP's/clients'
    Example would be, we want to give SIP & Skype priority over HTTP and want a
    minimum level, and a maximum level of throughput.

    Thanks again for your time!


  • Rebel Alliance Developer Netgate

    If you tried to use multiple subnets all on one LAN, there is nothing stopping someone from simply changing their IP and landing in another subnet. That's why you need VLANs. Plus the administration of that is messy, and you'd still lose all those IPs from carving up the /25.

    If you use private VLANs, you do not need to use multiple internal subnets, since the access control is really handled by the switch.

    It's a lot of administration no matter how you do it, really, but most of that is just up front work and once it's set it should be fine. For a conference room, they would need a VPN no matter how you do it, because your VLANs would end up on the WAN side of any router they had, not on their individual LAN.

    You should be able to do shaping as long as you keep the single LAN/single WAN scenario. SIP is covered in the wizard, skype is different as it can use randomized ports.



  • The only benefits I can think of for using VLANs in this case are preventing someone from using someone else's IP address (if you configure VLANs on pfSense, each with their own subset, which it doesn't sound like you are doing) and preventing others from sniffing traffic going in or out (if your switches would allow it).  Since you said you are not firewalling the addresses, leaving it up to them to do so, I do not see any reason to block traffic between them.  If they can be accessed from the outside, why shouldn't they be able to access each other?

    There is one exception I can think of, however, which is that you may be wanting to block broadcasts.  Is there anything you can configure on your switches to do so? (but then again, ISPs don't always block broadcasts between their public addresses either)



  • Thanks so Much guys! I appreciate it. I will take your advise and well appreciated for your opinions.


Log in to reply