I sure hope this isn't a duplicate. I have a client who has UTM at his sites. Each site has two internet circuits, from to difference providers, and each site has the same two providers as the other sites. He would like to pin a RED using the first vendor's internet circuits, and pin a second so the red will be built only on the second internet company's circuit. While you can control the destination of the RED, it doesn't appear that you can control the source interface for a given RED. I am suggesting that it would be possible to specify which outbound interface is used on a per RED basis.

As a Sophos Partner, I'm increasingly getting hammered by clients who have to subject themselves to audits in order to do business. Therefore I am asking that Sophos add access controls to the RED listening service. I am requesting that the RED service on the UTM be configured to use any arbitrary IP address on any of the WAN interfaces, and only allow connections from RED devices from known IPs. Here's why:

I have clients who fail PCI compliance audits because of the self signed IP. I know that the 1 CA trust model is better, but the auditors my clients use don't tend to make any exceptions. The bigger reason for the request is to lock down the service. It only takes one vulnerability in the RED server side code or one of the libraries it relies on, to open the door to a potential compromise. Enabling a more locked down ACL than "any" helps to reduce the surface area such a vuln could exploit.

In cases where the IP's were dynamic on the RED device side and the IPs could not be locked down, it is desirable to configure the RED service listener to an arbitrary IP on the WAN side of the UTM. I shouldn't have a service listening on an interface I don't specifically allow.

I'm not saying the defaults should be anything other than your current default config, but I am asking for the flexibility to configure things more tightly, should I choose to do so.

This is V2 of a previous post that I deleted, to tighten up the request and drop the part about using certs signed by a public CA. He posted some good info, so I wanted to include it here so it won't be lost:

I’ll leave this feature open for votes, though it should be limited to just the restriction of IP addresses, and not the use of a signed certificate for communication.

The RED service uses an unsigned certificate deliberately. Using a publicly signed certificate, and relying on public certificate infrastructure would actually weaken security in this case. The RED protocol uses an arranged key exchange to limit the trust to just two parties – The UTM and the RED device. RED receives the public CA cert of the UTM its connecting to as part of its configuration, and that is its ONLY trusted root ca used for communication between the RED device and the UTM. This is more secure than the the public CA model, which trusts certificates signed by any one of Many CAs.

As for restricting access to the service, I agree this is a desirable feature, but also one that could be highly problematic. RED works best (easiest to deploy) when the RED device receives a DHCP address from a provider. In this case, you wouldn’t know the IP of the RED device prior to its connection, and restrictions would have to cover a large range of public IPs to properly accomodate it in this case. If you are using static IPs at all RED locations, then locking it down might be more feasible. You can in fact do this today, though its not an explicit feature of RED. Instead, create two DNAT rules. The first, like this:
Source: Selected RED IP Addresses
Service: RED port 3400 TCP/UDP and port 3410TCP/UDP if using RED 50.
Destination: External WAN (Address)
Type: NO NAT

Then, for the second rule:
Source: Internet
Service: RED port 3400 TCP and port 3410 TCP if using RED 50.
Destination: External WAN (Address)
Type: DNAT
New Destination: (no change)
New Service: Some Unused port, like 1 or 65536

This will stop all connection attempts to the RED service port from anything other than the desired addresses.

For smaller independet companys it would be great to support a "router aon a stick" solution. I imagine a RED device only connected to any network and have two virtual interfaces, one for the uplink configuration and the second for the remote interface. With such a solution it is possible for the independent company to route all traffic supposed for the tunnel to the RED remote interface and the Tunnel would be established with the first interface. I could also imagine an alternative to Standard/Unified, Standard/Split and Transparent/Split. It would be something like "Routing/Split" where you need two interfaces one for uplink and a second for Routing/Remote Interface. In this mode only the the uplink interface only manages the tunnel and does not forward any other traffic. Rhe remote interface also only handels routet packages for the networks allowed for the RED device.