The XG does not allow the ability to choose which IP interface a built in service like VPN/IPsec and the SPX portal bind to. For example, I have a /24 public IP range, and in order for a NAT to function for outgoing traffic, I'm required to create an aliased IP address on the WAN link. Each and every aliased IP responds to requests on UDP 500 as the following (via namp or the nessus vulnerability scanner): 500/udp open isakmp StrongSwan ISAKMP.

The fact that there may be rules in place in the VPN configuration to limit who can actually make a connection is pointless when you are using a public IP for a whitelisted B2B service. In this type of scenario, you just don't want that IP address answering to *ANYTHING* other than the services and source IPs that you have configured in the firewall rules. Now, the entire internet, as well as your business partner, knows that something is answering on that interface.

This is not how firewalls are supposed to act. Needless to say, I have IPsec disabled through the web gui, but it still responds to IPsec inquiries on all of my aliased IPs. As to the SPX portal: I was able to defeat this behavior since I was given a choice as to which physical ethernet interface this service listens on, so I bound it to an unused port. I don't have this luxury with IPsec. Furthermore, I opened a support ticket on this matter, and the only way to defeat this behavior is to create a "business application rule" to blackhole this service to an IP that goes nowhere. This becomes problematic due to our /24 address space as I have to create at least 252 rules, one per public IP just to make the firewall do what it is supposed to do.

Neither the Cisco ASA nor the PaloAlto line of enterprise class firewalls behave this way; both allow you to define which IP interface to which services such as IPsec are bound. In addition, both of these products adhere to firewall rules that are put in place. For example, I can define a rule which drops traffic that would otherwise be answered by the firewall itself -- you can't do this with the XG.

I asked that this issue be escalated to engineering, and the support person was able to contact someone in engineering who replied that this behavior was 'by design' and that they would not fix the problem. My only recourse was to post this in the 'Idea' section on the Sophos site. In my opinion, this type of response from support is nothing short of a slap in the face to paying customers who rely on this product to secure their company's livelihood.

Please fix this problem. I don't want to have to purchase another pair of firewalls to replace my pair of XG650s, or worse, put another pair of firewalls in front of the XG650s just to do the job that the XGs are supposed to do themselves.

Add the option for Action on Failback on the Firewall Rule itself when using the Primary WAN and Backup WAN options.
We have situations where we have a Voice Firewall rule that is for the customers Hosted phones system. We offer the ability to have failover WAN on the system(phone and firewall). In cases due to poor ISP quality the backup WAN (on the voice rule) is not ideal for VOIP and has issues like echo, Dropped packets and so on.
In a failover event we are able to have there phones starting using the backup connection however when it comes back up VOIP Phones do not re negotiate the connection often enough and end up staying on the backup.

In the case above both WANs are set as Active in the WAN management. This is due to on the data network firewall rule the Backup for the voice is the Primary on the data.

There is more application than just voice for this option as it is just a setting to control the failback action for the WANs but on a per rule bases and when all WANs are Active WANs and not backup WANs.