Hi everyone, I’m running the latest ROS 6.41rc, which establishes a PPPoE connection via the ONT router/modem that my fiber ISP gives me.
I use PulseSecure to connect to a VPN. I have no administrative access to the VPN, but it is well maintained with lots of users that have no complaints. However in my case, the VPN connection fails exactly every 20 minutes as the two sides try to do an ESP (UDP port 4500) re-key exchange. The logs make this very obvious, as the re-key interval is set (and I can’t change it) to 1200 seconds, and as soon as this time arrives the logs show that the re-key failed and then it tries to degrade the connection to NCP (SSL), and my VPN connection is effectively dead although it still shows as connected.
Hi, sorry to bump this old thread, but I’m still having the same problem.
Pulse describes the necessary behavior (in D-Link terminology) as follows:
The D-link setting “Endpoint Independent” allows NAT to forward any connection request with the same port to the VPN Tunneling application regardless if UDP port 4500 is already in use or if the connection is coming from a different IP (Connection request comes from the internal IP of the SA SSL VPN IP instead of the externally resolved IP).
Is there a defconf rule in RouterOS that needs to be disabled, or do I need to add a new rule to get the same behavior?
I would assume that the issue has nothing to do with NAT configuration as the rekey process takes place within the same firewall “connection”. Is the IPsec client the Mikrotik itself or some PC in Mikrotik!s LAN?
Well, if it is their own client (an application provided by them), it can behave in many broken ways, theoretically including an attempt to establish a new IPsec connection instead of actually rekeying the old one and establishing that new connection from a different source address than the machine’s LAN one, but in that case I cannot see how the RouterOS could route the ESP over UDP packets back if that address would be outside the LAN subnet.
So I’d suggest that you configure /tool sniffer on the Mikrotik to sniff into file with filter-ip-address=the.ip.of.the.vpn.server filter-interface=the-LAN-interface-name filter-port=4500 filter-ip-protocol=udp filter-operator-between-entries=and, start the sniffer, start the VPN connection, transfer no data through that connection so that Mikrotik’s disk wouldn’t explode, and stop the sniffer once the connection fails after the 20 minutes. And then have a look using Wireshark whether the packets towards the vpn.server.ip:4500 really start coming from a different source addresses after the first 20 minutes.
OK, I made a packet capture. It appears that all requests are coming from the same address, in this anonymized example “99.99.99.99”. Attached. UDP-4500_20180827_anon.pcapng.txt (34 KB)
Since both the responded packets and the unresponded ones (from packet 443 on) from the client come from the same IP address and also from the very same UDP port, there is no chance that the Mikrotik’s (or any other router’s) NAT handling could see any difference, so it NATs all of them exactly the same way. So the issue must be somewhere else.