Multi WAN routing using wireless access points



  • Hello All,

    Could use some help…  I have a 2.0.1 pfSense running on a Dell server and with 4 interfaces configured as follows -

    Comcast
    ATT1
    ATT2
    LAN

    Our office primary Internet (Comcast) is connected to "Comcast"
    A "backup" link is connected to "ATT1"
    A second backup link is connected to "ATT2"
    Our office LAN is connected to "LAN"

    We use a 172.16.110.x/24 range for our internal IP's.
    I have a DHCP range on the firewall handing out LAN IP's in the range 172.16.110.100 - 250.
    The range of 172.16.110.1-99 is reserved for static IP's.

    This firewall has been running for years and everything (WAN, LAN, OpenVPN, etc.) all works perfectly.

    Now, on to my issue...

    I have installed two new Unifi UAP Pro access points and have assigned them as 172.16.110.9 and 172.16.110.11 
    The gateway for each is set to the firewall LAN interface.  The AP's do not support the function of nor hand out DHCP addresses.  The firewall handles all DHCP assignments.  We use the Comcast WAN link as our primary office connection and my goal is to route all traffic connecting to the 9 AP to ATT1 (WAN) and all traffic connecting to 11 to ATT2 (WAN), essentially load balancing the internal wireless LAN traffic to the two separate ATT backup links, used as a backup strategy when the primary Comcast link goes down.

    With that in mind -

    I added  two new firewall rules under "LAN" as follows -

    any proto  172.16.110.9 (source)  any port    any destination    any port  ATT1 (gateway)    none (queue)    none (schedule)

    and

    any proto  172.16.110.11 (source)  any port    any destination    any port  ATT2 (gateway)    none (queue)    none (schedule)

    expecting that to work, but it doesn't.  An IP lookup always reveals the connection is getting the Comcast WAN IP (normal if not connected to only the Unifi AP's (wired)), and even when connected only wirelessly to one of the AP's.

    On a related note, when I add an identical rule specifying any individual LAN IP (say 172.16.110.50 as an example), and point it to either ATT gateway, it both routes and assumes the IP of the appropriate WAN interface via outbound NAT and confirmed by both IP and speed test lookups.

    The only thing I have been able to conclude is that since the PC is the actual source, again (172.16.110.50) , the Unifi AP is simply passing the connection to the pfSense server and it is therefore ignoring the AP's IP (9 or 11) and the rule doesn't apply, so it still goes out on the Comcast interface as it normally would.

    In addition to the LAN rules mentioned above, I have also tried various NAT scenarios, including -

    1:1 -

    ATT1 (Interface)  External IP of ATT1 (External IP)    172.16.110.9 (Internal IP)    any (Destination IP)

    and

    ATT2 (Interface)  External IP of ATT2 (External IP)    172.16.110.11 (Internal IP)    any (Destination IP)

    Outbound -

    ATT1 (Interface)    172.16.110.9/32 (Source)    any (Source Port)    any (Destination)    any (Destination Port)    any (NAT Address)  any (NAT Port)    NO (Static Port)

    and

    ATT2 (Interface)    172.16.110.11/32 (Source)    any (Source Port)    any (Destination)    any (Destination Port)    any (NAT Address)  any (NAT Port)    NO (Static Port)

    all to no avail.  Not sure what I am missing or if/what I can do to basically tell the pfSense server that any traffic coming from 9 should go to ATT1 and any traffic coming from 11 should go to ATT2.

    Any help and/or suggestions would be greatly appreciated.

    Thanks!

    • Jim

  • Rebel Alliance Global Moderator

    "I have a 2.0.1 pfSense running"

    I didn't read past this… 2.0.1 is no longer supported.. Why are you on such an old version?  That was released back Dec of 2011, what possible reason could there be to be running such an old version?



  • No "good" answer, so the only one I've got.  It's a small office and basically considered non-critical to the organization, so no one cares about versions there.  They do however, want a backup plan in case they lose the primary link.  They also want it to work without flipping any rules.  The assumption is that, if working, they could just connect to the wireless and voila, instant backup strategy.  Sounded reasonable to me, except it is not working as planned.

    And yes, I have encouraged upgrading the pfSense server, but they are petrified to do it.


  • Rebel Alliance Global Moderator

    Well should be new hardware for your pfsense box as well.  Since have to assume the hardware is 5 some years old ;)

    So get new pfsense box, install current.  Put in your rules.  Unplug old, plug in new.. Works great, doesn't work plug in old and see what you did wrong.

    As to your AP, why would you think clients connected to these AP would use rules based upon the AP ip??  If you want your wireless to use a different wan.  Then put wireless on a different network than your lan.  Either a different interface than your lan in pfsense on different network or use vlan do you have vlan capable switches?  Lets call it 172.16.111.  Now you can create rules for this network to use wan 2 vs wan 1.  Now all devices on wireless will use wan 2, and all devices on lan will use wan 1.

    First course of action should be upgrade of pfsense..  On your new current hardware and version you can breakout your wireless to different network and create your policy based routing, etc.



  • I follow all of your logic and agree it's the best course of action.

    The problem is that making those changes (adding new box and switches) is outside of my control.  I have already suggested it many times and haven't received a warm response.  They know they will need to do it, just wanted to get this backup solution working first.

    Segregating the networks as you pointed out is the way to go, but can't be done today or in the next few days (or possibly weeks), so I am trying to make this scenario work in the meantime.

    Just seems that it might work if the firewall can actually identify those two IP's as a source and then route accordingly.  As I said, it works fine with any device other than the AP's as the source and it appears that's because they are not being seen as the source.

    In any case, looking for any suggestions to try in the short term.  Was just hoping maybe someone experienced the same issue and found a way around it.

    If upgrades (and additions) prove to be the only option, then they will have to "bite the bullet" and do so.


  • Rebel Alliance Global Moderator

    That is not how AP work..  They do not nat, All your clients will have their own IPs.  You can create your rules based upon their IPs.  So if you know all your clients get IP 192.168.1.100+ then you could create a rule that says if source 192.168.100 to .254 use wan 2, if not use wan 1, etc.

    Look at your clients do they have their own IP in your network 172.16.110, now send traffic to the internet and sniff at pfsense lan for where they are going.. What IP do you see ;)

    So if you can setup reservations for all your clients be it either lan or wlan to get specific IPs then sure you can setup your policy based routing that way.  Not sure about the old pfsense, but current pfsense would allow you use specific pool of addresses based upon say the make of the card.  So you could put in the first part of the mac of the wireless cards to always get IP from pool B in your network 172.16.100.100-254, and clients that mac did not start with that would be IPs from pool A ie 172.16.100.2-99



  • Why did you have to set the rules?  The units should not require any special rules?  Where is your controller?  Outside of the wan or on the Lan?



  • If you don't have a switch that supports vlans then get one.  Create a new vlan for the wireless and set your unifi AP to the vlan you set on the firewall and switch.  Create a gateway group for the 2 ATT links and set the gateway for that vlan to the group for ATT.

    You will need to ad a rule or maybe 2 to allow traffic from the wifi vlan to get to the other respective networks before the primary rule with the gateway group