Audiocodes Mediant VE SBC only shows InternalIF OSN

After configuring Audiocodes’ VM based SBC in a single NIC state, a need come up where a WAN interface needed to be brought online. When attempting to set an IP to the interface group the following error was displayed:

nwDevTable_CrossValidateRow: Validation failed, the ethernet group (index 1) already contains the OSN interface. No other device can be configured on this group. MATRIX DeviceTable: Unable to Activate Line(1) since it is invalid

As we can see, the Ethernet Device Status shows InternalIF OSN is the only other available device.

IP Interface Status doesn’t show much help either:

An idea attempted was exporting the configuration ini file, adding the configuration entries for the second NIC, applying the changed configuration file and restarting appears to bring it up, but it still had a red state of down/unknown. (the WAN_DEV Ethernet Device was created in the config file)

The following steps were taken to get the Audiocodes VM to work:

  • Delete the logical Virtual Machine network interface
  • Restart the VM
  • Add a new NIC to the VM
  • Restart the VM

Once those steps were taken, the interface came up, and the IP was active!

How to deal with The target of the symbolic link doesn’t exist

The other day I came across a Hyper-V host server where an OS crash had occurred. A new OS install was made on the C: drive. After the rebuild, the D: drive’s VMs (VHDX’s etc.) were visible and appeared to be fully available, but when an attempt was made to import the existing VMs or even access the files, the following error message was displayed:

"The target of the symbolic link doesn't exist"

Trying to access the with Windows Explorer gave an Error 0x80070780: The File cannot be accessed by the system.

The following observations were made:

In Windows Explorer, the files appeared with the attributes “APL”, which stands for:

  • L = Reparse Points
  • P = Sparse File

The command attrib was attempted to remove the L and the P, but no avail:

An interesting note, Windows Explorer had “Reparse Points” and “Sparse File” attributes, but looking at Attrib, it saw the files as symbolic links. It threw me off, but looking at how Windows Explorer saw the file started me down the path of Deduplication.

Looking at, we see that Windows Deduplication works with reparse points, so perhaps this data drive had deduplication turned on for data drive.

On that note, the Data Deduplication feature was installed, the server restarted, and YES!!! All the large files (VHDX, ISO, etc.) were available!!

To disable DeDuplication:

If DeDuplication is disabled, it doesn’t actually undo the work that was done, and if it is disabled, garbage cleanup commands can’t be run.

It’s VERY Important that Deduplication is left enabled, but leave the entire drive Excluded.

Once that’s done, run the following two commands (which will take quite a bit of time depending on how much data there is).

The unoptimise command:

Start-DedupJob -Volume  -Type Unoptimization

Check the status:


Clean up the Garbage:

Start-DedupJob -Volume -Type GarbageCollection

Once both above commands are run, you can remove the deduplication role from the server.

Serious vulnerability in Cisco IOS

Jeremy Kirk at Databreach just wrote about a serious vulnerability found on nearly all of Cisco’s IOS devices (Including ASA’s). The vulnerability named Thangrycat requires a good amount of effort to patch the affected hardware, although at the moment, its saving grace is that the attach requires the  “local attacker” to be authenticated in order to write a modified firmware image to the component.

Not all gloom and doom, but a significant find!



An insight into a hacked Exchange server

Matthieu Faou just wrote a whitepaper at ESET detailing the process where the sophisticated spy network Turla quietly exploited a backdoor in Microsoft Exchange servers that gave attackers unprecedented access to the emails of at least three targets over several years! The fascinating whitepaper is located here: ESET Lightneuron Whitepaper

Emails arrive on mobile device but not Outlook client

In a single AD Domain with an Exchange 2016 environment that was hosting multiple email domains, there was a power user that has several mailboxes with different email suffixes that would sporadically stop receiving inbound emails to his fully patched, Outlook 2016 client. (The 2013 client behaved exactly the same.)

The Exchange server system is a simple 2 server setup, the databases are replicated in a DAG array, with several different databases split out by company/department.

Exchange DB1


As you see in the figure, User1 has four different user accounts with four different mailboxes with different suffixes hosted on the same database, as he is from Company1, but needs to receive separated email to different mailboxes (reply with those unique email addresses), and authenticate separately.

After several hours of combing through the environment, and Microsoft support services unable to find anything amiss, one of the tests were creating a new Outlook profile, adding just one user account, and testing, well what do you know, it works! When a second mailbox is added to the profile, inbound mail stops to the client though. (Again, a mobile device receives the inbound mail immediately, but nothing occurs for the desktop Outlook client)

A hint on how to fix it came when I looked at User2. In this case, User2 also was opening up multiple mailboxes with the same clients, but there were no issues at all. As is evident, even though the mailboxes open from the same Exchange environment, the back end databases are separate.

After creating a new database for “”, and migrating the User1 mailbox over to it, when that additional mailbox was opened in Outlook, mail flow continued!

The Exchange environment pictured has a lot more complexity, to end users it is completely separate, seemingly different Auth Domains, DNS, URLs, etc., but in reality is all the same back end infrastructure for ease of maintenance, (hint, KEMP is used to do a bunch of backward and forward URL rewriting) so adding some additional mailbox databases in the back end didn’t really complicate efforts too much.

Inside access to external NAT IP services

The corporate office has an environment where there is a separate “guest” network for vendors, visitors, etc. that can use their own devices, to use internet services through Wi-Fi.
Due to the fact some internal services are needed such as joining internal Audio/Video conferences, and access to collaborative services, we had a requirement that access to those services be available through this semi-public network that is “external”, i.e. uses external DNS resolution, but is still “inside” the firewall boundary as shown below.

Access from GuestNet-Diag

To spell it out, we had the following infrastructure:

  • Internal services only accessible from inside the corporate network and internal devices.
  • External services accessible from outside the corporate network.
  • Guest network with external/public DNS resolution.

The requirements are as follows:

  • Internal services accessible externally if secured with boundary extending services, primarily Microsoft Direct Access, or if explicitly approved, Cisco VPN software.
  • Skype for Business availability for Guest Wi-Fi to join conferences and collaboration.
  • SharePoint services (specifically Office Online Server) for collaboration access from Guest Wi-Fi.

Cisco has a good article here: to make this process work, the D-NAT methodology was used, but the article can a bit confusing, so I just wanted to explain a couple things to clarify it, and show how the final NAT rules end up looking.

The following are the relevant NAT rules:

Access from GuestNet

  • For the Match Criteria:
    • Source is the Guest network.
    • Destination for the Skype for Business services is the “inside” DMZ interface, as in this case, the DMZ is sandwiched, has an internally facing network, and an externally facing network, or wherever the service resides, as some services are on the “services” network.
    • IP source is the Guest network object.
    • IP destination is the External IP of the service.
  • For the Action:
    • Source is wherever the service resides.
    • Destination is the Internal IP of the service.

I hope this helps clarify the Cisco article.