Posts

L2TP VPN fails after january 11, 2022 update

Microsoft January 11, 2022 update breaks L2TP VPN [solution]

Microsoft update KB5009543 breaks L2TP VPN functionality causing error message “The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer“. Investigating the log shows error 789 for rasclient.

A temporary solution is to uninstall KB50009543. Run cmd as administrator and enter:

wusa /uninstall /kb:5009543

After reboot VPN will work again.

See also this article.

pfSense port forward to a NAT:ed IP-address located on the other side of a ipsec tunnel

This is kind of a special scenario but actually occured for me. A port on the pfSense WAN should be NAT:ed to an IP-address located on a remote subnet via an ipsec tunnel. The problem here was the router on the other end of the tunnel did not route all it’s outgoing traffic over the tunnel. Only a few subnets behind the pfSense went through the tunnel. All other traffic was using the routers normal Internet connection.

In the image above, a port (123 in the example code below) on the pfSense (100.1.1.1) should be NAT:ed and port forwarded to 10.0.0.7. The result was the NAT:ed port forwarded packets reached the intended host (10.0.0.7) but replies probably went straight back on the internet, not going back through the tunnel.

I solved this by setting up a simple proxy on a server using iptables located on a machine in one of the subnets at the pfSense site which was reachable from 10.0.0.7 through the tunnel. See next image.

The proxy was made using iptables in a Ubuntu machine on 10.2.2.2. Both the proxy server on 10.2.2.2 and the host 10.0.0.7 could reach each other over the ipsec tunnel.

In pfSense I changed the NAT / port forward of port 123 from 10.0.0.7 to 10.2.2.2 (and deleted the existing states in pfsense from my previous tries, until I did that, this didn’t work).

The proxy server using IP-tables was set up like this (guide found here):

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i ens160 -p udp --dport 123 -j DNAT --to 10.0.0.7
sudo iptables -t nat -A POSTROUTING -o ens160 -p udp --dport 123 -j SNAT --to-source 10.2.2.2
sudo iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.2.2.2

You will probably want to make sysctl ip_forward and iptables statements persistent over reboots.

Automatic restart of IPSec VPN on Teltonika RUT-950 / RUT-240

On one location where I am using a Teltonika RUT-950 / RUT-240 router, the IPSec VPN can only be connected in one direction which is outbound. Normally both ends can initiate the connection. The reason for this is that the router is connecting using 3G/4G and the provider only allows outbound traffic (i.e. “surf the Internet”). I need to buy an extra service for “fixed IP-address” in order to get their firewall removed from my service.

My IPSec VPN setup is based on hostname updated through dynamic DNS. If the router reboots, it will get a new IP-address and sometimes the router tries to connect the VPN before the dynamic DNS has been updated, causing the VPN connection to fail. The router gives up and does not try anymore to connect the VPN. A manual workaround is to remote control a computer on the LAN side of the router, login to the router, disable the VPN profile, save, enable it and save again. Now the VPN connects.

The Teltonika products are wonderful in many ways but I lack a way of restarting IPSec VPN via SMS. It is only possible to restart OpenVPN connections using SMS.

To avoid manual actions to get the VPN up in a case like this I have created a small script. It checks if an IP-address on the other side of the tunnel is ping:able, if not it restarts IPSec VPN and it normally resolves the problem.

  • Log in to the Teltonika RUT-950 / RUT-240 using CLI or SSH.
  • Create a script in /root/chk_vpn.sh with the following content, or you can dowload it with wget from CLI or SSH:
    wget http://heltech.se/filer/chk_vpn.sh

#!/bin/ash
# chmod +x chk_vpn.sh
# crontab -e -> */6 * * * * /root/chk_vpn.sh
HOST=10.0.0.1

LANIP=/sbin/ifconfig br-lan | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}'
# Email settings
ROUTERNAME="MY ROUTER NAME"
EMAIL_SUBJECT="$ROUTERNAME: VPN restart"
EMAIL_BODY="$ROUTERNAME $LANIP: Ping $HOST failed, trying to restart VPN (date)"
EMAIL_FROM="senders.email@gmail.com"
EMAIL_TO="recipients.email@gmail.lt"
EMAIL_USER="senders.email@gmail.com"
EMAIL_PASS="MYEMAILACCOUNTPASSWORD"
EMAIL_SERVER="smtp.gmail.com"
EMAIL_PORT="587"
#
if ping -I $LANIP -c5 $HOST > /dev/null; then
  logger "chk_vpn.sh: $HOST responded; VPN is up!"
else
  logger "chk_vpn.sh: $HOST did not respond; trying to restart VPN"

echo -e "subject:$EMAIL_SUBJECT\nfrom:$EMAIL_FROM\n$EMAIL_BODY" | sendmail -v -H "exec openssl s_client -quiet -connect $EMAIL_SERVER:$EMAIL_PORT -tls1 -starttls smtp" -f $EMAIL_FROM -au"$EMAIL_USER" -ap"$EMAIL_PASS" $EMAIL_TO
  /usr/sbin/ipsec restart
fi

(The date in the code above should be in back aphostrophes but our WP editor removes it)

  • Edit the file chk_vpn.sh and replace the IP-adress on the HOST= line to an IP-address on the other side of the tunnel that you know should be up at all times and responds only when the IPSec VPN is up, for example the LAN interface of the other router.
    Change all lines regarding email to your email server’s settings and credentials.
  • chmod +x chk_vpn.sh
  • Check from the router’s CLI or SSH that you can ping the IP-address (if you mistakenly enter an IP-address that doesn’t respond to ping even thought IPSec VPN is up, your VPN will be disrupted 10 times per hour).
    You must use ping -I 192.168.0.1 10.0.0.1 where 192.168.0.1 should be replaced with your router’s LAN interface IP-address and 10.0.0.1 replaced with the ping:able IP-address on the other side of the tunnel.
  • Test the script by running it from CLI or SSH and verify that it can ping the host on the other side of the tunnel by entering the command: ./chk_vpn.sh and then go to System -> Administration -> Troubleshoot -> Show syslog and look for the chk_vpn.sh line (probably last row)
  • Edit the crontab by entering the command crontab -e and add the following line:

*/6 * * * * /root/chk_vpn.sh

  • Exit vi (ESC then :wq and enter)

This will check the VPN connection 10 times per hour and if necessary restart it.

Edit: 5 october 2022: Added LANIP as source

pfsense IPsec phase 1 disable rekey

pfsense IPsec VPN tunnel disconnects after 8 hours

I’ve been troubled by the annoying disconnection of the IPsec VPN tunnel on a pfsense firewall. The tunnel disconnects after about 8 hours.

The solution in my case was to enable “Disable rekey” which “Disables renegotiation when a connection is about to expire.“. The setting is found under Phase 1 advanced settings.

Disable rekey setting under Phase 1 Advanced settings

Windows 10 VPN-problem after update to 1903 [workaround]

After installing the 1903 Windows 10 update, also called may 2019 update, users experience problems when trying to connect a VPN connection.

The problem occurs when clicking Connect on the VPN-connection through the system tray. When the dialog box for user name and password should appear, nothing happens.

Until Microsoft solves this a temporary workaround is to connect through the control panel.

  • Click on the Windows start button (the Windows flag in the bottom left corner)
  • Click on the cogwheel for Settings
  • In the control panel search box, type “VPN” and select “VPN-settings
  • Click on the connection you want to use to display the Connect button
  • Click the Connect button and now the dialog box for user name and password will display and you can connect as usual