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:5009543After reboot VPN will work again.
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.
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.
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.1LANIP=/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)
chmod +x chk_vpn.shping -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../chk_vpn.sh and then go to System -> Administration -> Troubleshoot -> Show syslog and look for the chk_vpn.sh line (probably last row)crontab -e and add the following line:*/6 * * * * /root/chk_vpn.sh
This will check the VPN connection 10 times per hour and if necessary restart it.
Edit: 5 october 2022: Added LANIP as source
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.
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.