I assume you claim the fact that the client cannot access internet via the L2TP tunnel. If the client cannot access internet at all while the L2TP connection is active, the issue is at Mikrotik side; if it can access internet but bypassing the L2TP tunnel, it is the routing setting at client side which differs depending on client type.
The instructions on the Wiki cover the key subject, but cannot cover all individual environments, so the reader always has to implement the key subject into his local context. And referring to the Wiki doesn’t provide any information on how your actual firewall rules and routing look like. Don’t ask what it might be, post the configuration to let someone else find what it really is, as this is a much easier task.
The only rule in the firewall chain of your “drop-all-but-exceptions” firewall which permits outbound connections through WAN is
action=accept chain=forward comment=“Alllow LAN interface-list out wan interface-list” in-interface-list=LAN out-interface-list=WAN,
but as the VPN interfaces are not members of interface list LAN, this rule doesn’t allow packets coming from these interfaces to establish new connections to internet.
Another permissive rule is action=accept chain=forward comment=“Allow VPN to main network connections” dst-address-list=main src-address-list=vpn which refers to src-address-list=vpn but only the LAN subnet 192.168.254.0/24 is listed in the dst-address-list=main so this rule also doesn’t match packets from VPN clients to internet.
And that’s it, the two remaining permissive rules which refer to ipsec-policy are irrelevant because IPsec is only used to encrypt the transport packets of the L2TP, so the payload packets coming in via the L2TP tunnel do not match any IPsec policy.
So either add an interface-list=LAN item to the /ppp profile, so that each dynamically created L2TP server interface would be added as a member to the interface list, or add another rule like action=accept chain=forward comment=“Allow VPN to internet” out-interface-list=WAN src-address-list=vpn before the last action=drop rule, and remove the last-but-one and last-but-two action=drop rules because they are useless in the current setup. The first one permits dst-natted packets which came in via WAN to go further through the chain but the next rule ignores them and the last rule drops them; the second one drops anything from LAN to anywhere else but again, what this rule ignores is dropped by the last one.
“So either add an interface-list=LAN item to the /ppp profile”
This looks like a cleaner way to do it. Should I add the interface-list=LAN to both the default and default-encryption profile? To test, I added it to the default-encryption profile and it worked. I did not realize you could dynamically add to an interface list - even thought it was right in front of me… Very neat feature.
“ipsec-policy are irrelevant because IPsec is only used to encrypt the transport packets of the L2TP”
To be honest I left these rules as they came in MTs default firewall rules. I did not have a clear understanding of when they would match. Now I mostly do… .
“remove the last-but-one and last-but-two action=drop rules because they are useless in the current setup.”
The last drop rule needs to stay - it is these two that are useless?
add action=drop chain=forward comment=\
"Drop new connections from internet which are not dst-natted" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Drop packets from LAN interface-list th\
at do not come from the LAN interface-list" in-interface-list=LAN \
out-interface-list=!LAN
Would the first rule be more effective (match) earlier in the chain? I assume it simply does not matter as it will hit the last rule and drop anyway. So perhaps there is no advantage to it.
Last Question - Is it a best practice to have one catch all Masq rule, or to use multiple Masq rules for each network? I can be more granular with a rule for each, but is not as clean. What is your preference?
It depends on which profile your /interface l2tp-server server, or your /ppp secret refer (the latter, if set, supersedes the former)
Correct.
Exactly. That rule (drop what comes in via WAN unless dst-nated) remained there from the default firewall settings, and its effect in the default firewall settings is “accept any connection initiated from LAN side, accept any connection initiated from WAN side if dst-nated, drop the rest” because what is not dropped by that rule is accepted as it is the last rule in the forward chain and the default handling if no rule matches is hardcoded to “accept” (unlike in naked linux iptables where you can set default handling for each chain).
First of all, action=masquerade should only be used with interfaces whose address dynamically changes, because each change of address or interface going down causes all masqueraded connections to be dropped. Other than that, there is no actual preference - whereas in the mangle chain every packet is handled so you it is important to make the number of rules a packet has to pass through as low as possible, the nat chains only handle the initial packet of each connection so it is not so critical to have one rule per WAN interface. So after all it is the readability what matters most if you plan to modify your firewall now and then.
Hello
I am trying to access the internet while connected to L2tp tunnel from windows client
1)Masq setup:
2)Here are nat rules:
0 ;;; Customer_Nat_sector_2
chain=srcnat action=src-nat to-addresses=x.x.x.79 to-ports=0-65535
protocol=tcp src-address=10.10.1.0/28 log=no log-prefix=“”
I’ve promised to explain why you should have removed the export file. You’ve left the public IP in the file you’ve posted, you’ve left the complete /ppp secret row there, and your firewall is non-existent as you’ve missed the fact that the default handling is accept, i.e. if a packet doesn’t match any of your action=accept rules, it is accepted anyway because there is no “drop the rest” rule.