Remote Winbox/HTTPS connection dropping out through IPsec VPN Configuration

RouterOS General
1

Hello everyone,

I’m having trouble maintaining a stable connection to Winbox over an IPsec VPN tunnel between two Mikrotik routers. Here’s the setup and the issue I’m encountering:

Setup:
-Two Mikrotik routers are connected over an IPsec VPN tunnel.
-The VPN is working as expected: the tunnel establishes successfully, and I can ping devices on the opposite end.
-I’ve set up firewall rules to allow traffic on port 8291 (Winbox) and 443 (HTTPS) for remote access to the routers.[/list]

The Issue:
While I can connect to the remote router using Winbox, the connection frequently drops out. And the Winbox session will sometimes load the configuration, sometimes not.
Winbox begins to load the configuration, but the session quickly resets, and I see messages in the router logs indicating that the remote PC is repeatedly logging in and out.

Troubleshooting Steps Taken So Far:
Firewall Rules: Verified that the firewall rules are correctly allowing traffic on the required ports (8291 for Winbox and 443 for HTTPS).

IPsec Policy Settings: Confirmed that IPsec policies match on both routers, so there shouldn’t be a mismatch in encryption or hashing settings.

MTU/MSS Mismatch Suspected:

Since VPN tunnels add overhead, I suspect that MTU or MSS mismatches are causing packet fragmentation, which might be interrupting the connection.
I’ve learned that lowering the MTU and clamping the MSS can help prevent this.
Configured MSS Clamping:

To address the potential packet fragmentation, I added a firewall mangle rule to adjust the MSS (Maximum Segment Size) on packets passing through the VPN.
I set up the following mangle rule on both ends of the VPN:
Chain: forward
Protocol: tcp
TCP Flags: syn (to ensure MSS changes only affect TCP SYN packets)
Action: change MSS
New MSS: 1300 (a safe value for most IPsec VPN tunnels)
By setting tcp-flags=syn, I avoided the Mikrotik error that prevents MSS adjustments on packets that aren’t SYN packets.
Adjusted MTU: Lowered the MTU on the VPN interface to 1300 on both routers to reduce the likelihood of fragmentation within the tunnel.

Current Status:
After applying these changes, the connection is somewhat more stable, but I still experience Winbox dropouts. I’m wondering if I need to fine-tune the MSS value or if there could be other underlying causes, such as IPsec rekeying issues or additional firewall adjustments.

Has anyone experienced similar issues with Winbox over an IPsec VPN, or are there other recommended settings for optimizing Mikrotik VPN stability?

Thanks in advance for any insights!

Kind regards.

2

I found the issue pretty soon after posting.

It was Fasttrack:

FastTrack is a feature in MikroTik RouterOS designed to optimise network performance by accelerating the processing of packets for established connections.

When FastTrack is enabled, packets that match specific criteria can bypass several processing steps, including firewall rules and connection tracking, resulting in faster packet forwarding and reduced CPU usage.
This is particularly beneficial for high-throughput environments.


The Problem with FastTrack and VPNs
While FastTrack can improve performance, it can also introduce issues, especially when dealing with VPN connections such as IPsec. Here’s why:

Bypassing Connection Tracking:
FastTrack skips connection tracking, which is crucial for maintaining the state of packets in a VPN tunnel.
VPN protocols like IPsec rely on consistent tracking to ensure packets are correctly encrypted, decrypted, and routed.
When packets from a VPN session are FastTracked, they do not go through the necessary stateful processing.
This can lead to inconsistencies in how packets are managed, often resulting in dropped or misrouted packets.

Impact on TCP Sessions:
TCP connections, like those used by Winbox for management, are highly sensitive to disruptions. They depend on a stable state for each connection.
FastTrack’s bypassing of connection tracking means that packets may arrive out of order or be misidentified, leading to session resets or drops.
This manifests as frequent login/logout behavior and connection timeouts when trying to manage devices through a VPN.

Firewall Rules and NAT:
FastTrack also skips many of the firewall and NAT rules that might be necessary for proper packet handling. This can create scenarios where certain packets do not receive the correct treatment as they travel through the router.
For example, if there are NAT rules that need to apply to packets entering from a VPN, FastTrack can prevent those rules from being applied, causing further connectivity issues.

Resolution by Disabling FastTrack
In my case, disabling FastTrack on the local router resolved the connectivity issues for both the local and remote routers.

Here’s how this helped:
Consistent Packet Handling: With FastTrack disabled, all packets were subjected to the normal firewall and connection tracking processes. This ensured that packets from the VPN were managed correctly and consistently, allowing for a stable connection.
Improved Session Stability: By maintaining stateful processing, TCP connections, such as those for Winbox, were able to remain stable and properly handled, preventing the frequent disconnects and timeouts experienced before.


Conclusion
In summary, while FastTrack can enhance performance for regular traffic, it can lead to significant issues when dealing with state-sensitive protocols like IPsec VPNs.
Disabling FastTrack allows for consistent connection tracking and proper handling of packets, resolving the connectivity issues.
If you’re encountering similar problems with VPN sessions, consider evaluating your FastTrack settings.