Gnome NetworkManager and vpnc – use nm-connection-editor

Gnome NetworkManager is awsome, supporting almost all kinds of VPN solutions, and all you need to do is install a plugin. My main issue is, that my customers often have a pre-build package (for Windows) containing a VPN client including configuration, so they actually dont know how it’s configured.

I usaually figure it out, and then its a breeze to click the network icon, select VPN and activate the connection, this is how it should be on all OS’es.

Unfortunatly there are some minor issues, one of them beeing that if you install the network-manager-vpnc module, you will have the option to create a VPNC based connection, and if you type everything right the first time, it will work. But….

You will not be able to edit the connection, it’s simply not listed when you select VPN settings (Ubuntu 22.04). using nmcli will list the connection, and you will be able to modify it, but I found another soluition, that is much easier.

nm-connection-editor

It will open a small GUI, letting you create, modify or delete all connections.

I have created a bug report here:
https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1951313
It has been confirmed, bot not fixed. Hopefylle it will be fixed in later releases.

Another issue, that I discovered today, is that you are not allowed to add the connection when creating it 🙁 See some discussion here:
https://askubuntu.com/questions/1403896/cant-add-cisco-compatible-vpn-vpnc-on-network-manager-ubuntu-22-04
This issue is also not present in nm-connecttion-editor.

The connections will be working perfectly from the build in NetworkManager application in gnome.

systemd.mount replacing autofs

I have been a very satisfied user of autofs for several years. Using a laptop in multiple location without reboot, could often cause annoying timeouts with hard mounted NFS shares.

So I found autofs, which did a great job, especially the ghost option is nice, making you able to browse the filesystem when it’s not mounted, and only seeing a small delay when the autofs mounts it for you at your wish.

I have now discovered that systemd has a mount option: https://www.freedesktop.org/software/systemd/man/systemd.mount.html
It can be used as systemd units, but also directly from /etc/fstab where I prefer to have my mount options.

To replicate the autofs functionality, add something like this to your mount options:

noauto,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.mount-timeout=30,_netdev

The above options will mount when you try to access the share, and it will unmount after 1 minute of idling, and the _netdev tells the system not to mount it before the network is ready.
More or less the same functionality as autofs, but no need to install additional software.


Postgresql not listening on docker interface after reboot

/etc/postgresql/12/main/postgresql.conf is where you define the interfaces for postgresql to listen on. It’s done with the line “listen_interfaces =”
So, to get postgresql to listen on a docker interface, you have to add the IP address to the configuration:

listen_addresses = 'localhost,172.18.0.1'

This will make postgresql listen after connections from my docker container. Unfortunately when i rebooted the machine, postgresql was only listening on the localhost. That was strange.

After doing some fiddling around, I discovered that I might had a timing issue, and I even found a couple of articles covering the issue. The postgresql service needs to wait for the docker service to be started, or it cannot listen on the docker interface, that seems logical. I tried following some of the workarounds described, but I couldn’t get it to work. I then took a look on how the default systemd is build, and it seems that /etc/systemd/system/default.target.wants/ consist of symbolic links to /lib/systemd/system/whatever, so i did the same:

sudo ln -s /lib/systemd/system/postgresql@.service /etc/systemd/system/default.target.wants/

I then added this line to the unit block:

After=docker.service

This seems to have done the trick. After a reboot, postgresql is listening on my docker interface. You can always verify with:

sudo ss -nltp | grep postgres

Ping not permitted in WSL

Using Windows subsystem for Linux (WSL) is so nice, when you are forced to work from an inferior OS, sometimes also referred to as “a gaming console”
Especially combined with the Windows Terminal, which I wrote about here: https://www.nordal-lund.dk/?p=592 I’m sure that most Linux/Unix administrators will feel right at home.

Despite all the goodness, there are some minor annoyances preventing me from experiencing a big burst of happiness. One of them are the inability to use ping on a std. WSL Debian as a non-root user. That’s right, you need to do “sudo ping nice.little.address” or you will be denied 🙁

The root cause is the ping utility missing the SUID bit, which it has on the real distro. Luckily there’s an easy fix, add the SUID bit to the ping utility:

sudo chmod u+s /bin/ping

Thats it, now you can ping without sudo again 🙂

Happy pinging
/Kasper

Looking for clear text authentication with tcpdump

Login services not using encryption, is unfortunately still often seen in the wild. I started out in the IT business around 2000, and even back then, clear text authentication was bad, but still we see it today.

Examples of services using clear text authentication is: HTTP, FTP and telnet. Don’t ever authenticate using any of these protocols, unless you know exactly what you are doing.

Sometimes you may want to verify, if the password is actually sent in clear text, and one of the tools to use is tcpdump. Tcpdump is the default network analyse tool on most Linux distributions, and it’s very easy to get started with. Maybe you just want to know if your network changes is routing traffic to your server, you can use tcpdump to verify.

When sniffing for clear text passwords, we need to give the parameters -s 0 and -A and then we can give the destination port the service is listening on with dst port. So the full command would look like this:

tcpdump -s 0 -A dst port xxx

You can also specify the interface to listen on, by using the -i option. If your interface is enp0s31f6, then it would look like.

tcpdump -i enp0s31f6 -s 0 -A dst port xxx

Another option is the “and” and the “not” keyword. Imagine you are logged in with SSH, and looking for ssh traffic, but you don’t want to see your own traffic. The you can use and not host ${your own IP address}, like this

tcpdump -i enp0s31f6 dst port 22 and not host xx.xx.xx.xx

In the last example i have removed the -s 0 and the -A option, since i don’t need it just to see if traffic is getting to my server.

SFTP files to vSphere vcenter Appliance 6.5 or vSphere PSC

When logging in with SSH the default shell on these platforms is some vmware specific menu based system. In order to get a real shell you need to type shell. But this is not possible when using sftp, therefore you need to tell your tool to use a real shell.

In WinSCP this is done by configuring the advanced connection parameters for the sftp protocol connection. Press the advanced button and head for the sftp paragraph. In here you need to specify the sftp-server as your shell in the SFTP server text box.
The sftp-server path may change depending on specific version, find the path on your system by running: “find / -name sftp-server”.

On my system the sftp-server was in /usr/libexec/sftp-server. Therefore i had to specify “shell /usr/libexec/sftp-server” as the SFTP-server.

 

Check for open outgoing ports

Want to know which ports are allowed (or open) to use in your organization?
You can check all ports with http://portquiz.net/
In bash somthing like this would help you get going:

for i in `seq 1024 65535`; do if nc -z portquiz.net $i; then echo “Port $i Success”; :; fi done

You will now get a fine list of outgoing ports that are open. Remember that just because some port is open, it doesn’t necessarily mean that it is allowed to use it!

 

Test network connection with powershell

Sometimes you need to test the network connection for a range of IP addresses. Normally I would use ping from a commandline, but it could be a hugh task to test more than 20-30 addresses.
Utilizing a bit of powershell and the test-connection command will help us overcome the task in an easy way:

[code language=”powershell”]1..100 | %{write-host -nonewline "Testing 10.0.0.$_ : "; Test-Connection 10.0.0.$_ -quiet -Count 1}[/code]

The above one-liner will test the connection to all hosts in a range from 10.0.0.1 to 10.0.0.100 and giva a False or True status.
Remember that % is a short way of using the foreach loop, so you could use “foreach” instead of %.

EDNS på Technicolor TG799VN V2

I dag skiftede jeg Internet udbyder fra Telenor til Telia, begge kører med en Technicolor router, men med forskellige versioner. Den nye fra Telia er en technicolor TG799VN V2. Selve skiftet gik faktisk super nemt og det hele var oppe at køre efter ca. 30 minutter – men der var altså lige et lille problem med hastigheden

Jeg kører mit eget hjemmenetværk og bl.a. også en bind DNS server, hvor jeg bruger googles servere som forwarders. Jeg havde fine målinger på speedtest.net, men jeg kunne se at den var meget langt tid om at slå navnene op, hvis det overhovedet lykkedes. Et opslag mod dr.dk med dig/host svarerede meget langsomt, ofte slet ikke.

Jeg ændrede mine forward adresser til telieas egne, men lige lidt hjalp det 🙁

Til sidst begyndte jeg at se på logfiler i min dns servers syslog, og her fandt jeg problemet. Loggen havde masser af disse linier:

named[4505]: success resolving ‘www.dr.dk/A‘ (in ‘dr.dk‘?) after reducing the advertised EDNS UDP packet size to 512 octets

Ydermere kunne jeg se at min Technicolor havde over 60.000 i count på “udp_rate_limiting” i IDS funktionen.

Google ledte mig frem til denne Wikipedia: http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS#Issues

Routeren havde altså et problem med Exentension mechanism for DNS som er en udvidelse af DNS protokolen der gør at man kan sende mere end 512 bytes pr. frame og som bl.a. er nødvendigt for at køre DNSSec.

Jeg har ikke tidligere haft problemer med dette, selvom jeg snart har haft en del forskellige routere i mit setup.

Jeg kontaktede Telia med mine observationer og aftalte med hotlinen at jeg sendte en mail med beskrivelse, så de havde noget at gå videre med. Vi aftalte også at vi lige kunne prøve at opgradere firmwaren, den flinke mand mente dog ikke at det ville virke – men det gjorde det 🙂

Så nu kører min Technicolor TG799VN V2 med firmware version 10.5.1.Q og lider ikke af manglende understøttelse for EDNS mere.