Problem (bug?) in creating Multi-WAN (2x IPv4 DHCP WAN, pfSense 2.1)



  • Hello!    …and a million thanks for a super product, I LOVE pfSense :)

    To accomplish Dual-WAN load balancing, I freshly installed pfSense 2.1 and created WAN1 and WAN2 interfaces, both with IPv4 DHCP (and IPv6: none).

    Then I created a Gateway Group called "MultiWAN", with both WANs in "Tier 1".

    However, when I tried to create a firewall default rule from "LAN subnet" to the Internet (Firewall:Rules -> LAN tab) with Gateway: "MultiWAN", I got an error saying "You can not assign a IPv6 gateway group on IPv4 Address Family rule", although both my WANs are IPv4 only. (Perhaps an important note: at this point the WAN NICs do not have DHCP IPv4 addresses yet, the NICs are still "down".)

    The only way around this (it seems to me) was to use Static IPv4 WANs instead. (But that's not what I want to do: I'm going to use two ADSL lines with modems in bridge mode, so that pfSense WAN NICs would get their public IPv4 addresses with DHCP from ISP.)

    So, perhaps there is a bug in the validation logic when creating the firewall rule?

    Interestingly, if I try to create exactly the same firewall rule but with "TCP/IP Version: IPv6" instead, I get this error message "You can not assign a IPv4 gateway group on IPv6 Address Family rule". So, regardless of the IPversion of the FW rule, the gateway group ("MultiWAN") always seems to have the wrong IP version…

    (Maybe this problem goes away when both of my WAN NICs really get their DHCP IPv4 addresses, but I think one should be able to create this setup even if the DHCP addresses are not yet assigned?)

    Yours sincerely,
    Eino



  • Yes, I believe this is a bug/feature  ;) - if none of the gateways in the group currently have a gateway IP then the code does not figure out which IP protocol the gateway is.
    The problem is in /etc/inc/gwlb.inc function return_gateway_groups_array()

    Looping around each gateway in the group...
    if (!empty($int) && is_ipaddr($gatewayip)) {
    ...
      $gateway_groups_array[$group['name']]['ipprotocol'] = $gateway['ipprotocol'];
      $gateway_groups_array[$group['name']][] = $groupmember;
    }
    
    

    The IP protocol of the gateway group as a whole is only set if one of the members actually currently has a gateway IP, even though the IP protocol of every gateway is already an attribute that is defined in the data structure when the gateway is defined - it does not need to be deduced from the IP address.
    return_gateway_groups_array() is a way too complicated function to need to use here when saving a firewall rule - actually we do not care about the current gateway status, we just want to validate some gateway attributes in the fixed config. I am sure this could be fixed easily - but myself I don't have a suitable system to really test on right now.
    It will fix itself when at least 1 NIC gets an IP address and gateway.



  • and I think this change to gwlb.inc wil make it return the ipprotocol even when no gateways in the group have a gateway IP:
    https://github.com/phil-davis/pfsense/commit/4a5bce90cee8c865dd4e3d0b440bfc14e1d64086
    I have tested the syntax and that it calls OK on a test system. But I don't have access to somewhere where I can test your scenario right now. If you are just setting things up, then try this version of gwlb.inc (which I edited on 2.1 branch) and confirm if it fixes the issue.



  • Thanks for a quick response!

    I tested the gwlb.inc you sent - now the FW rule creation works great (even though both gateways of the MultiWAN gw group are DHCP IPv4 and without assigned addresses yet).

    However, using the new gwlb.inc causes warning messages to show up on Status:Dashboard:System Information:Version. Like this: "Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/gwlb.inc:1158) in /usr/local/www/guiconfig.inc on line 48" and so forth, a long list of warnings.

    Reverting back to my original gwlb.inc, I guess I'll manage just fine when my IP addresses get assigned.

    But as far as the bug/feature goes, the new version of gwlb.inc seems to fix it  :)



  • gwlb.inc only has 1022 lines, so I do not see how it is reporting about line 1158 - perhaps somehow you got extra blank lines or… on the end?
    Anyway, great to hear that the code functions.



  • :-X  I have met the same problem.



  • The gwlb.inc code change I made at https://github.com/phil-davis/pfsense/commit/4a5bce90cee8c865dd4e3d0b440bfc14e1d64086 should let you do all the setup even while none of the WAN gateways have actually been connected or got an IP address by DHCP.
    The pull request has been sitting for a while - I guess with other things in development the devs have not had time to be sure there are no side-effects on other things, before committing the change.


Log in to reply