L2TP With FastTrack in MikroTik
Uploaded by
iwanbudakjambiL2TP With FastTrack in MikroTik
Uploaded by
iwanbudakjambiL2TP with FastTrack in MikroTik
Kullawat Chaowanawawee · Follow
2 min read · Nov 29, 2017
Share
I recently purchased a MikroTik Home Router hAP ac model based on Warodom
Werapun 's recommendation and found that it has an affordable price but its
capabilities are high-class. Because it can do many things that other home routers
in the same price range cannot do, such as L7 firewall, VLAN, IPsec, VPN,
WebProxy, BGP, OSPF, RIP, Traffic Engineer, and many other things that I have
not yet fully studied.
The story is that I need to use a VPN to access another network where I have an
L2TP/IPsec server ready. So I created an L2TP client interface on the MikroTik hAP
ac using the command
/interface l2tp-client
add name="myL2TP" disabled=no connect-to=.......... \
use-ipsec=yes ipsec-secret=......... user=. ...... password=.......
Now that the hAP ac has started contacting the prepared L2TP server, I created a
mangle rule (firewall) to make a routing mark that must be routed through the
VPN, then force all user traffic on the network to go. Stay on VPN with src-nat rule
using the following command:
/ip firewall mangle
add action=mark-routing chain=prerouting \
comment="L2TP Routing Mark" new-routing-mark=myL2TP \
passthrough=yes src-address=192.168.88.2-192.168.88.254
/ip firewall nat
add action=masquerade chain=srcnat comment="L2TP masquerade" \
out-interface="myL2TP" routing-mark=myL2TP
But... the story doesn't end there, because in newer MikroTik routers there is a
FastTrack feature [1] as a firewall rule added by default. FastTrack is a combination
of the FastPath [2] and ConnTrack systems to provide a connection that In
established, related state, they can be forwarded without kernel processing, which
results in 5 times faster data transfer and also reduces CPU load [1]
The problem is that FastTrack doesn't support IPsec... If I disable FastTrack, that
means that when I'm not using the VPN, I'll have to turn FastTrack back on.
Conversely, when I'm using the VPN, I'll have to turn FastTrack off. And in the
worst case scenario, FastTrack doesn't support IPsec. If the VPN server goes down,
the router is smart enough to cut NAT rules so you can continue using the internet,
but it's not smart enough to automatically turn on FastTrack.
// I'm stunned for 3 seconds.
I started looking for a solution in various forums/blogs [3, 4]. I tried many
methods, including making connection marks, which was unsuccessful in case 3
from the previously mentioned problem, and filtering with IPsec was unsuccessful
because of L2TP. will encapsulate IPsec another layer
In the end, I chose to create a simple firewall rule to solve this problem by adding a
forward rule that would pass the L2TP interface both in and out to accept
immediately before reaching the FastTrack forward rule.
/ip firewall filter
add action=accept chain=forward in-interface="myL2TP" \
comment="Forward L2TP connection (in)"
add action=accept chain=forward out-interface="myL2TP" \
comment="Forward L2TP connection (out)"
And can the problems encountered be solved or not?
Case 1 : Open VPN as usual. The packet will have a routing mark for VPN to be
issued, and the L2TP forward rule will work normally without going directly to
FastTrack.
Case 2 : Disable the use of VPN. Disabling the use of VPN in this way will not
disable the L2TP client interface, but will disable the routing mark instead. When
there is no routing mark, the NAT rule will not work, so the packet will not be
masquerade towards the L2TP interface, for example: This will cause the L2TP
forward rule to not work and will go directly to FastTrack... Hurry!
Case 3 VPN server down / connection lost In this case, both NAT rule and L2TP
forward rule will be disabled by default due to L2TP interface down. As a result, all
packets will pass through FastTrack… fast.
Summary
FastTrack is a very good thing because it makes forwarding packets about 5 times
faster because it doesn't have to go through the kernel and also reduces the CPU
load. But it is not compatible with L2TP/IPsec, so it must be fixed by using 2 L2TP
forward filters. rules with an example config as follows:
/interface l2tp-client
add name="myL2TP" disabled=no connect-to=.......... \
use-ipsec=yes ipsec-secret=......... user=. ...... password=.......
/ip firewall mangle
add action=mark-routing chain=prerouting \
comment="L2TP Routing Mark" new-routing-mark=myL2TP \
passthrough=yes src-address=192.168.88.2-192.168.88.254
/ip firewall nat
add action=masquerade chain=srcnat comment="L2TP masquerade" \
out-interface="myL2TP" routing-mark=myL2TP
/ip firewall filter
add action=accept chain=forward in-interface="myL2TP" \
comment="forward L2TP connection (in)"
add action=accept chain=forward out-interface="myL2TP" \
comment="forward L2TP connection (out)"
add action=fasttrack-connection chain=forward \
connection-state=established,related \
comment="defconf: fasttrack"
add action=accept chain=forward
connection-state=established,related \
comment="defconf: accept established,related"
** NOTE: The L2TP forward filter must always be placed before the FastTrack rule.
