Suggestions

[Rhongomiant]

I know that 2.1 is locked and 2.2 is expected to be a major upgrade which I guess will take many months to be released is not a year or more, so I am hoping there will be a 2.1.1 for these suggestions.

1. Allow the Parent interface for tunnels to be a gateway group.

2. Failover in general needs to be worked on. I have seen too many times with more complicated setups where some interfaces are master on the secondary firewall while the WAN interfaces are still primary on the primary firewall.

3. VPN connections and routing on secondary firewalls. There is a known issue with redundant firewalls connecting to the firewall to which the VPN is not established. e.g. I have a VPN connection to the primary firewall, so I can connect to the primary firewall, but I cannot connect to the secondary firewall. This can be resolved by creating route statements for the remote VPN subnets to use the primary firewall IPs or the CARP IPs when VPN connections are established. I would think this could be made part of the pfsync sync. Of course, if the secondary firewall is the active firewall for the VPN connection, pfsync or what ever would send the routes to the primary firewall.

4. Allow for interfaces that can be more dynamic. For example, currently firewall redundancy does not work unless carp can be used, so if you have a DHCP IP, there is no redundancy option. While it would take some scripting, the system could recognize that the connection has failed perform it reconnect attempts and after a period of time shutdown the interface so that it is not arping on the network. On the redundant firewall the like interface would be configured as a backup DHCP interface. When the interface on the primary firewall fails to make a connection on this interface, a signal would be sent to the secondary firewall to attempt a connection. If the connection fails nothing happens. If the connection succeeds and passes what ever tests are performed to verify the connection is good, the failover would occur.

Of course, none of this would even be attempted unless all the criteria are met. e.g. If someone has two WAN interfaces, only one failing may not warrant a failover, so the primary firewall would just continue to attempt the connection until all criteria are met for the system to consider a failover.

If this is possible with just scripting, someone is going to say submit the code to do this and it will be reviewed. My php skills are not up to snuff for me to submit what I would consider to be reliable code for something important like this. However, if someone with the php skills and understanding of pfSense wants to provide a quote to write this code, I will certainly consider it. Not sure if that is allowed in a forum post, but you can PM me.

5. One thing that pfSense lacks is the ability create rules generically for traffic that the firewall does not know how to reach specifically. For instance, lets say that you have two LAN interfaces and a WAN interface. If I do not want traffic from LAN2 to be able to get to LAN1, I have to create a block rule for that traffic and then create an any rule for all other traffic. This is easy in this example, but when you have multiple LAN interfaces this becomes cumbersome.

5a) It would be nice if you could specify rules for traffic that would be directed to specific interfaces.

5b) While that would be a great feature and I would like to see it added, the use of security levels for interfaces would also be nice. e.g. Interfaces could be assigned security levels and traffic could be allowed depending on the security level of the interface to which it is routed. WAN interfaces could be assigned lower security levels than the LAN interfaces and rules could be created allowing traffic to interfaces with lower security levels, specific security levels, security levels less than or equal a security level or security levels matching a range of security levels.

5c)  Even those features would be useless when using gateway groups. This is due to the way gateway groups work because they specifically change the way routing works for traffic the matching traffic. This feature is great just the way it is for some traffic, but it would be nice to have a softer version of a gateway group. Basically, lets say that we could specify a list of default gateways. This type of gateway group would simply determine which default gateway is used if the traffic is directed to the default gateway rather than forcing it to the default gateway. This may just not be possible, but if it is add it.