Choose interface IPs for built in services
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.