Here below are the config, please advise how to fix it. Thank you !
The relevant part of your configuration is the following one:
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip firewall filter
1. add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
2. add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
3. add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
4. add action=accept chain=input comment="allow l2tp" dst-port=1701 protocol=udp
5. add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
6. add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
7. add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
The issue must be in chain input of the firewall filter rules because
- you can reach other devices on the LAN via the VPN
- there are no non-standard rules in raw and mangle tables, and rules in srcnat chain of nat table do not handle packets sent out by the router itself
- there are no rules in chain output of the firewall filter, and rules in chain forward do not handle packets sent by the router itself nor those whose destination is the router itself
Next, you have to understand how the L2TP/IPsec works. L2TP creates a virtual interface. Any packet routed through that interface is encapsulated into a UDP packet with destination port 1701 (see note below) and sent to the remote side. If L2TP is tunnelled via IPsec, the UDP packet to port 1701 is encapsulated and encrypted using the security association of IPsec into an ESP packet. And if there is NAT between the local and remote end, the ESP packet is further encapsulated into a UDP packet with destination port 4500.
Note: the server always listens at port 1701, the client may use a different port at its side which has some advantage.
On receiving side, the onion is peeled in reverse order.
- The IPsec encrypted and encapsulated packet arrives via WAN interface (in your case, ether1) as a UDP packet to port 4500.
- If it is the first one of the connection, rule 1 ignores it but rule 2 matches and accepts it; further packets are matched and accepted already by rule 1.
- Now the IPsec processing takes place. The outer UDP and ESP envelope is removed and the decrypted UDP packet to port 1701 remains.
- This extracted packet is treated as a new incoming packet which came in via the same interface as the one from which it has been extracted. So the firewall inspects it as such.
- If it is the first one of a connection, rules 1, 2 and 3 ignore it and rule 4 matches and accepts it, otherwise already rule 1 matches and accepts it.
- Now L2TP processing takes place. The outer IP and UDP envelope is removed and an L2 packet is extracted. But this time, the packet is not seen as coming in via the WAN (ether1) interface, but via the virtual interface which has been dynamically created (at server side, at client side it is a static one) when the L2TP session has been established. And this "new" packet is processed by the input chain of firewall filter rules as well.
- None of rules 1-6 match it, so it reaches rule 7. And as the dynamically created L2TP interface is not a member of interface list LAN, the rule matches and the packet is dropped.
You have several possibilities to resolve this, depending on how complex the rest of your configuration is going to grow.
- the simplest one is to modify the rule 7 - instead of in-interface-list=!LAN, use in-interface-list=WAN. That way you only prevent the router from being accessed directly via WAN, but access from any other interface, including virtual ones and including some added later, like e.g. your wireless network for guests at home, will be possible
- the name of the dynamically created virtual L2TP interface is always <l2tp-username>, so in your case it is <l2tp-vpn> (including the shap brackets). But when the tunnel goes down, the interface is destroyed, so it is also automatically removed from the interface list, and it is not re-created there when another interface, albeit with the same name, appears again. What you can do is to create a static interface of type "L2TP Server Binding" and link it to the ppp user name (vpn in your case). Such an interface is static, therefore it exists regardless whether the L2TP connection is established or not, and you can add it as a member of the interface list "LAN", or insert a rule
anywhere between existing rules 1 and 7.
chain=input action=accept in-interface=your-static-binding-name
- you might be tempted to permit incoming packets based on their source address regardless the in-interface as @misucatinas suggests, but it is not a good idea as a packet with a "proper" source address can be spoofed and sent to your WAN interface. Scenarios exist where such packet may cause some harm to your network.
One extra question, do you have any special reason to permit "untracked" packets in rule 1?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.