Use the following settings to configure a Fritz!Box – also a LTE version – to connect to a Sophos UTM (v9.7)
- Sophos UTM Settings
- Fritz!Box VPN VPN-Configfile
enabled = yes;
conn_type = conntype_lan;
name = "Sophos IPsec";
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = AAA.BBB.CCC.DDD; // Change to Sophos External IP
remote_virtualip = 0.0.0.0;
fqdn = "my.fqdn.net"; // No change needed. Is ignored from the UTN
ipaddr = "AAA.BBB.CCC.DDD"; // Change
mode = phase1_mode_idp; // Main Mode
phase1ss = "dh14/aes/sha";
keytype = connkeytype_pre_shared;
key = "MySecr3tPassw0rd!"; // has to be changed
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
ipaddr = 192.168.0.1; // change to local network
mask = 255.255.255.0; // change to local subnet
ipaddr = 172.16.0.0; // change to remote network
mask = 255.255.255.0; // change to remote subnet
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
accesslist = "permit ip any 172.16.0.0 255.255.255.0"; // to remote network
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
I got this error when I tried to add a SNMP HP ProLiant Physical Disk Sensor for HP Proliant DL 380 G7 with Windows 2012 R2 in our monitoring solution from Paessler (PRTG). The SNMP HP ProLiant System Health, Network and Storage Controller Sensor works fine.
HPE Insight Management Agents and HPE Insight Management WBEM Providers for Windows are installed.
An SNMP walk against OID 18.104.22.168.22.214.171.124.2.5 (used by Paessler for this sensor) works without errors but also without result.
I found some guys with the same probleme and a solution: The problem was the disk (controller) driver. Installed was v126.96.36.199, which seems to be a standard Microsoft driver. With the original HPE controller driver (for us 188.8.131.52) it works.
Today I switched from a Synology DS215play to a DS918+. Perfect time to change the file system – the DS215play didn’t support Btrfs. The migration also works with only one device. So I wrote down both ways.
Steps if you haven’t changed your DiskStation:
- Backup your data! If you switch to a device with new drives like me, you still have a copy of your data, but if you migrate without new drives, you don’t have a copy! In germany we say: No backup – no pity.
- Shut down the DS, remove drive 2. Format drive 2 with your computer.
- Turn the DS back on and DO NOT repair the fault volume.
- Create a new volume (SHA and Btrfs) in the Storage Manager on drive 2.
- For each shared folder, change the location to the new volume. You can only do this for one shared folder at a time and the move may need several hours depending on the size of your shared folders.
- When you have moved all the shared folders, shut down your DS and remove drive 1.
- Format drive 1 with your computer.
- Turn on your DS and go to the Package Center. Repair all apps.
- Expand your new volume to drive 1 and wait until RAID Resync is complete. You’re done.
Steps if you are switching to a new DiskStation with new drives (my situation):
- Turn off your old DS, remove drive 2.
- In the new DS, place the new drives in slot 1 and 2. Place the (old) drive 2 in slot 3.
- Turn on the new DS. Open your browser and navigate to the new DiskStation. In my case, the DS got a new IP address. I looked them up in my router DHCP table.
- Follow the Migration Wizard and wait until the DS restarts.
- Create a new volume (SHA and Btrfs) in the Storage Manager on drive 1 and 2. It is now recommended to change the RAID Resync speed to Fast and wait until RAID synchronization is complete.
- Now for each shared folder, change the location to the new volume. You can only do this for one shared folder at a time and may need several hours depending on the size of your shared folders.
- When you have moved all shared folders, shut down your DS and remove drive 3.
- Turn on your DS and go to the Package Center. Repair all apps. You’re Done.
Last week I noticed that the Single Sign-On (SSO) for the vSphere Client (Flex and HTML5) no longer works in my Firefox. Normally, the VMware Enhanced Authentication Plugin toolbar disappears at the bottom and you can enable the “Using Windows Session Authentication” option, but the checkbox remains unchecked. Reinstalling the VMware Enhanced Authentication plugin, updating the vCenter Server and reinstalling the plugin does not work.
Then I open a ticket at Vmware Support. Hours and some technology later, we had no idea what was going on. But, we find out that the local web server at https://vmware-plugin:8094/ (used by the SSO) displays the following error message in Firefox:
It looks like a problem with the Enhanced Authentication Plugin certificate. This is provided by the plugin. It creates a local web server to communicate with the web page. The VMware support team then created the certificate manually, but the error still occurred – even with IE and Edge.
Then I tried it with a fresh portable Firefox and it worked. In my installed Firefox I removed certificate exceptions for the normal host from the vCenter and vmware-plugin. I also – and most importantly – remove the certificate from the vCenter host and the vmware plugin from the certification authorities in Firefox. Reload the page and it’s working again.
After updating an iMac Late 2010 to Windows 10 1903 I got a blue screen “WDF_VIOLATION”. After checking the minidump, I could see that the MacHALDriver.sys (Macintosh Hardware Application Layer Driver) is involved. After renaming the file (c:\windows\system32\drivers\MacHALDriver.sys) over the network (works because the system crashes after user login) or in safe mode and rebooting, I was able to log back in. Since I don’t use an Apple keyboard I can do without the driver.
While researching I found out that other users also have problems with a similar keyboard driver for HP. In this case it is called HpqKbFiltr.sys. Is also responsible for the hotkeys (screen brightness and co.).
…command to show Port number, type of transceiver, product number including revion letter.
If username and password are right, maybe the UAC are the problem. Try to enable the LocalAccountTokenFilterPolicy to pass the local admin rights.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
To run a programm that doesn’t quit if you close the ssh session use nohup (no hangup). Attention, you have to run it as root for it to work!
admin@DiskStation:~$ sudo su
ash-4.3# nohup <command> &
ash-4.3# nohup cat /dev/zero | split -b 4095m - /volumeUSB2/usbshare/zeros -d --additional-suffix=.file &