Click on Join Now to Sign Up
Note: if the installation of a v2 image appears to fail, please check the logs. It might be that your system only supports v1 images. This will be evident by the presence of the following log messages in the system log:[writeimage.ERR]: *** Target root partition size is < 1.5G, only v1 images are supportedmgmtd: [mgmtd.WARNING]: Exit with code 2 from writeimage.shmgmtd: [mgmtd.WARNING]: Image installation failure: *** Target root partition size is < 1.5G, only v1 images are supported#012If this happens, please reboot your system once and try again. If it still persists, then please use the v1 image.
Edge Cache now supports HTTPS sites allowing the appliance to be a forwardproxy and decrypt content for caching. This is important as more and moreapplications and services are moving to the cloud. These SaaS- basedapplications are typically delivered over HTTPS and so to be effective,Edge Cache must support this HTTPS traffic. Sites to be cached can bespecified as a white list of specific sites to cache, such as youtube.com,or as a black list of sites to not cache. You can choose which everapproach works best for your environment. There is some importantinformation in the user manual about the handling of the certificates thatare needed to make this a seamless experience for your network users.
A new option has been added to the Virtual Circuit PDF report to provide a separate Peak vs Average Throughput report. This new graph displays two line graphs, one for the Peak throughput (maximum throughput seen in a 10 second sample) and the other is the throughput of traffic averaged over the time range (bytes seen during the sample period divided by the sample period duration). An option for this new graph is the scale on the Y axis. If the Y axis is requested in Kbps, then the Y axis will show the absolute throughput seen. If the Y axis is requested as a percent, then the Y axis will be 0 - 100%, where 100% represents the maximum bandwidth of the virtual circuit or circuit. If "All" is selected as the Virtual Circuit, then the peak vs average will be displayed for the circuit that.
- MEGANew Protocols
- MS Exchange including subtype Outlook Web Access
- Added subtype ‘encrypted’ to include encrypted traffic
- Added subtype for MPlus
- Ultrasurf: improved detection for Ultrasurf 14.03
- Added file-transfer subtype
exinda-2695b4 > en
exinda-2695b4 # configure terminal
exinda-2695b4 (config) # configuration
copy fetch merge new switch-to upload
delete jump-start move revert text write
exinda-2695b4 (config) # configuration switch-to
Honestly, at this time I'm not too sure at what threshold I'd want an alert...
I have previously asked to get the flow count included in the MIBs so I could graph it and establish a base line without running reports and/or checking the box everyday. If it was available via SNMP I could then tie it into our centralized management system and alert that way.
Here we tend not to touch each device with alert capabilities because every vendor has a different UI and config, so it gets a little crazy at times, so I rather poll, graph, check the delta from last poll, and decide from there to alert or not.
Currently yes the exinda is outside our firewall but that was done on purpose so we could physically "break" two ISP links with separate bandwidth limits and shape based on bridge rather than the aggregate of both. I understand the exinda is not build to thwart of DoS attacks and we were bitten twice, but that's our fault. That being said, ISP topology has changed and we will be moving the box behind our firewall as recommended, but the flows based on outside source would help with troubleshooting, which I use the exinda for all the time.
I wanted to provide you all with a better explanation of how the active directory integration works with Exinda. Exinda only sees IP addresses, in order to report users the appliance needs an external source of information that helps him map the IPs seen to the AD usernames they belong to, this is why the AD Connector application must be installed for each of the Domain Controllers.
1.- Where can I find the database for what usernames have been mapped to what IPs so far?
In the Exinda WebUI, go to Configuration: Objects-->Users&Groups. You are going to see an alphabetical breakdown of all the Users in the active directory and, if they have been mapped to an IP, you will see the IP (or IPs) next to them. If you don't see any Users mapped to any IPs, then go to your Domain Controller or Domain Controllers and filter the event viewer looking for the following Event IDs: 4624 for Windows Server 2008/2012 and 528/540 for Windows Server 2003. In your DC, click on Start-->Administrative Tools-->Event Viewer and then browse to Windows Logs-->Security Logs-->Filter by Event IDs. If you do not see any events filtered, then this is why the Exinda has not been mapping any users to any IPs. In that case follow the following Exinda Support post:
If you do see the logs, then ensure that the AD Connector was configured with the right password for the Exinda (or Exindas), it must be the same password you use to log into the box with the user "admin".
2.- There is a misunderstanding as to why there can be more than one IP attached to a single user:
Exinda software integrates with AD by grabbing the information depicted on the Logon Events (4624 for Windows 2008/2012 and 528/540 for Windows 2003). This being said, the software was designed to not make any own decisions with regards to what IP belongs to what username, instead the exinda only listens to what the Domain Controller has to say. If a user in IP (A) logs into the domain, that logon event should have produced a respective log, and that is what the exinda grabs from the domain controller. When the exinda sees a new 4624 event from the Domain Controller (or 528 and 540 for Windows 2003) it inspects what username logged in with what IP, then the exinda adds that IP to the respective username but it does not delete the previous records . Exinda will only delete a previous record if and when that old IP is used to login by another username, in which case exinda’s software removes the old IP from the old username and adds it to the new one. This takes me to the next bullet point:
3.- One or some IPs should no longer belong to that user, exinda should’ve removed it already and added it to another user that is currently using it/them
Once again, Exinda is designed to comply with the Logon Events coming from the domain controller. If it is believed that an IP/Username mapping is wrong, I would please ask you to follow the following verification procedure:
a.- Take note of that IP
b.- Go to the domain controller or domain controllers where the AD connector is installed and go to the Event Viewer by clicking on StartàAdministrative ToolsàEvent Viewer.
c.- Here, your goal is to find out what was the last user that logged in with that IP, this is what the exinda must have mapped by now. These logs are located under Windows Logs--->Security but they are too many to find the right one. We can create a custom view for only the specific ones we want.
d.- Right click on "Custom Views" and click on “Create Custom View”:
e.- A window will come up, you will need to click on the XML tab, and accept the "Edit" option (A warning about not being able to edit this script will show up, just agree with it).
f.- Use the following script and change the IP after “DATA” to search the IP you wrote down on step ‘a’:
This script is telling the event viewer: Filter every Security log that is related to the IP 10.10.10.10. After you accept you will just have to put a name and description on the Custom Query.
g.- You will expect to see some logs with the event id #4624 (or 528/540 for Windows Servers 2003). The latest log will tell you what was the last username that logged in with the respective IP (or at least what is the last username that logged into the AD for which the DC is reporting it). If this username is not what the exinda is showing, please communicate this to Support so we can have a look at it. If the last username/IP mapping complies with what the exinda is reporting, then the DC is not auditing the events correctly which is why the exinda cannot report as expected. This could occur for many reasons, one of them could be that the username is logging to another Domain Controller for which the AD Connector has not been installed yet, in this case I would recommend to install the AD Connector on all the Domain Controllers. Another possible reason is that some of the logging tasks are being taken care of by a third party product that unfortunately does not make the DC generate a respective security log or the security log generated does not contain the appropriate information. In this case, the exinda AD connector cannot work as desired as this is a not supported scenario, I would recommend to speak to the third party vendor.
Exinda Mobile ServerVMware ESX
Exinda ESP partition
Exinda Mobile Manager
Exinda ESP partition
Exinda Mobile Server
Exinda ESP partition
Exinda Mobile Manager
Exinda ESP partition