RED should be able to do DSL/VDSL (PPPOE), as this way it can be used with an ISP which is very common worldwide in requiring authentication against their modem.

Please implement data compression ability for RED Tunnels. This would allow more effective throughput using RED devices with slow internet connections - especially with slow uplink speeds, and also saving RED Bandwidth on Internet Uplink on HQ if there's for example heavy usage of good compressible content as HTTP traffic, SMB access etc.

Virtual Appliance image using as RED Device

It would be VERY useful to have an Option to activate an ASG as RED-Device (also known as RED-Hub-Mode). ASG works as RED-Device/Client.

ASG connects directly to another ASG using RED-function. Thus you can share SAME Networks at different Locations and bandwith is only limited by ASG and not to 30 MBit/s of a RED-Device without the need for an additional device.

capability to create VLAN on a "Red interface" to support voip or camera vlan

Our company uses PoE VoIP telephones. It would be a nice feature to be able to plug a PoE VoIP phone directly into the Red. This would provide much needed connectivity for our road warriors and employees that work out of their homes. Money would be saved since we wouldn't need to pay for dedicated business lines. A bonus would be that many commercial wireless AP's support PoE as well.

RED rocks. It's simple and it works. I would like to see an option where the uplink would not have to be a hard cable to an Internet connection. Make it an option where the WAN link could be WiFi

It would be great to know the status of the internet connection uplink(s) in use on our RED sites. Especially with the 3G/UMTS option, perhaps a way could be found to display the signal strength as well for extra benefits?

I would like to have granular control on what traffic is split-tunneled through the RED. Specifically based on port number.

Currently all in-line RED deployment options (Standard/Unifed, Standard/Split, Transparent/Split) will fail "closed" when the UTM is unreachable. Ah option to permit the RED to fail "open" when the UTM is unreachable and allow traffic to the internet (as it does during normal operation with split-tunnel traffic) would greatly reduce dependence upon the central location for businesses that heavily use internet hosted applications. We can live without the AV & URL filtering for short periods of time.

We have an opportunity that has about 90 remote sites and due to the cheap alternative of using 3G USB dongle for Internet access, they would like to see that the REDs device would have the ability to not just use the 3G connection as a failover link but is a primary link for all subsequent updates after initial provisioning at the HQ, Ethernet connection in those remote area is not possible.

At the moment it is not possible to use multiple failover options for UMTS. This means that it can take up to 2 minutes for the UMTS to startup if the wired line fails.

I have some customers which want to use the RED and also would like to use the failover, but it needs to work quicker.

It would be a good enhancement if the client gets an option how long the Astaro will wait till the failover takes please, and has an option to keep the UMTS connection open(to help reduce connectino setup time)

I travel alot... and I would love to extend my network into my hotel room. Systems like iBahn, which is found in alot of US hotels use a captive portal, RED needs a way to work with those portals and then connect to the gateway unit... even if it means a little web app in the unit its self... PLEASE work on this...

to be able to do basic troubleshooting on RED devices it would be fine to include CLI access and some basic commands like:
tcpdump
traceroute
ping
telnet (for Port checks)
...

this would be fine, if something fails between remote location and central device. It would be nice to be able to prove functionality for other involved parties.

It would be nice to have an Report about all the REDs and how long they use the failover 3G connection. This would be helpful to reduce costs with UMTS-Dongles with on demand contracts and to debug problems with the primary connection.