we are reading this, but this currently is only the 278th most wanted feature, therefore it is hopefully somehow obvious that it is not top our lists right now.
Hi, do you need this feature purely to put the original source ip in the log file of the webserver? Because if yes, there might be a workaround which we could improve in the future. As far as i know, we already send the original source ip as an attribute in the http header to the webserver. The webserver now needs to be reconfigured to just log this ip adress instead of the proxy ip.
Another question is, can't you just use the proxy server logfile? It should hold all information just as the webserver with the correct source ip adresses.
thanks for the input, as we are not familar with ConnectWise, how does such an integration look like and what is more needed?
Astaro numbers -> ConnectWise
ConnectWIse Config/change -> Astaro
With our new RED Branch Office Security Product, this is built-in, as the branches are connected through a Layer2 VPN tunnel, which enables the whole branch office network to use the DHCP Server/Relay on the Astaro. Please check out the new RED product here an watch a 2-minute explainer video: http://www.astaro.com/landingpages/en-worldwide-innovations-2010
8 votesAngelo Comazzetto responded
So we understand this request, currently the pool has fail over built in (dead nodes are removed and added in real time to the balancing) but you wish to have resources there (or a cluster of resources) doing no work, but becoming responsible for tasks/work when a failure happens in the primary node(s) only?
Have you tried the workaround i explained? It should deliver what you expect.
you can define a fail-over cluster by using 'Availability Group' in combination with a standard 'DNAT'rule.
You are able to add multiple hosts into an availability group in a prioritized order. The group will always use the active host with the highest priority.
If you now use this availability group as the 'translate to' target host object in your HTTP DNAT rule like:
Internet -> HTTP -> External Interface translate to Availability Group -> HTTP
this way you have your fail-over mechanism with two servers.
I also understand your request, but what is the scenario where it makes sense to have fail-over clusters like (2x active, 2x fail-over) why not have all 4x servers active and evenly distribute load.
Is there a reason for that?
We are hard at work on this feature and will deliver the first implementation of front end authentication as part of our Web Server protection (reverse proxy) in UTM 9.2. The public beta will begin in October. Stay Tuned!
We have this feature on the roadmap of the "Web Application Security" subscription, but it won't make it into the initial release.
But we do support transparent authentication pass-through, that means if your webserver does authentication, we transparently handle that (with the exception of NTLM/NTLMv2).
Adding "webauth" is planned for a feature release. Depending on the # of votes, this might be earlier or later.
Hi all, this is a bit problematic and not easy.
The transparent skiplist is based on ip adresses/networks that gets bypassed from the redirect to the proxy within the firewall. In this case, we have not yet looked in the HTTP header. What we now do is resolve complete hostnames already ahead of time and than use the resolved ip adresses to bypass.
We can not get a zone transfer for most domains where we could extract all hostnames for that domains and match them against the wildcard and find the relevant ip adresses that way.
In order to implement this, we would need to implement a new kernel module in the firewall to properly parse and handle the HTTP and HTTPS protocol to extract domain information from the Host header of the http request.
This is a lot of work and it is not that of requested yet.
The current design requires to create a shadow account of the user from the active directory. The reason for this is, that we create a cert/key pair for this user automatically on the fly which is needed for additional authentication and this information can not be stored in the AD as Astaro never writes to the AD.
But we do NOT store the password of the user in this cached user account. we only cache it for 15min (i think). This means if the disable the account in the AD or remove it from the group, he will NOT be able to log in anymore after 15min, as we do the password authentication against the AD then. If he still can, it is a bug.
41 votesUnder Review · 6 comments · SG UTM » Remote Ethernet Device (RED) · Flag idea as inappropriate… · Admin →
We will NOT integrated SNAT and MASQ into RED devices as we want to make sure the functionality and logic inside RED stays as simple as it is today. The simpler it is, the less it fails. :)
But we are aware of these and similar use case and we already work on prototyping a feature called 'virtual networks for RED', which allows you to specify a Virtual network on the RED configuration inside the ASG and we will perform the Network Mapping NETMAP on the ASG. You will get a 1:1 mapping of RealIP and VirtualIP.
Hi Angelo, i override this, it is actually a good request, and yes there are hardware limitations that need to be overcome, but i still want to track how many customers would want that.
do you mean dhcp release by the dhcp client of an interface, or by the dhcp server from the lease table?
Hi, what would be the practical benefit of LLDP for a small network. Which other devices commonly support it. thx Gert
302 votesAngelo Comazzetto responded
While we worked on this , the V8 WebAdmin was updated and adjusted to fit better in a standard size. However simply full-screening it or adding massive amounts of resolution wasn’t visually attractive. We will revisit this in the future perhaps.