Hello everyone,
I am a newbie on Mikrotik. In my house, I have a RB750G ( 192.168.88.1) as the router and have 2 hAP lite as wireless AP ( 192.168.88.2, 192.168.888.3) + one NAS (192.168.88.4) connected to the LAN port of RB750G.
I set up the L2TP/IPsec VPN in order to remotely access my home network. The VPN network was assigned to 192.168.6.0/24. Everything works fine. I can connect VPN from outside. The IP address I got is 192.168.6.2 But once the VPN is established, I can get access to hAP, or NAS when I key in the hAP IP address or NAS address, but NOT 192.168.88.1.
I thought since I can access the hAP lite via VPN, I am supposed to acess the router as well, but no matter how I try, I cannot access my Router.
Hi Sindy,
Thank you for the help. Looks like the linked topic has the same issue as me. I will look throough carefully and see if I can solve it with the idea you provided in that link.
The key seems falls on the firewall settings.
Hi, I tried but no luck ! The linked topic has much more complicated firewall rules than mine.
I just have the default config and activate the L2TP/IPsec VPN server on the main router. - set DHCP server for VPN, enable L2TP,....., etc.
I can get VPN from my iPhone without any problem, and I can remotely access my hAP lite ( wireless AP connected to RB750G) or NAS, but NOT the router.
Here below are the config, please advise how to fix it. Thank you !
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 , so in your case it is (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
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?
Hi Sindy,
Thank you for such a detailed explanation for this issue ! Really appreciated your great help !
I modified the rule 7 as per your suggestion and it works !!! Now I can remotely access the whole LAN network including the Router.
As to your question regarding on the ‘untracked’ in rule 1, In fact, it is the default configuration from the factory setting. Once you reset configuration to factory setting, it is there.
To be honest, I don’t know very well why Mikrotik put it in the rule 1.
I found this topic, because I have a same issue the OP had. Except I don’t have L2TP/IPsec VPN, but IKE2 IPsec configured. And changing from !LAN to WAN does not fix issue, I can’t access to router from any device on 10.12.14.0/24 network at all. If I disable that default “not from LAN” rule, I can access to router. I think it’s because IKE2 IPsec doesn’t create separate virtual interface. I have one PPTP VPN configured as well. And if I change from !LAN to WAN, I can access to router from PPTP VPN network.
This is my FW and IPsec VPN configuration, basically everything is router default -
What do I need to change to make router accessible from 10.12.14.0/24 network? I have to accept another input from 10.12.14.0/24 network?
Screenshots are not a good method of presenting configuration for analysis. See my automatic signature below regarding proper way of posting configuration.
Yes, you have to add another accept rule to input for that source subnet; if you want to be super-sure, add in-interface=X ipsec-policy=in,ipsec to the rule, where X is the name of the interface through which the IPsec tunnel flows, so that packets from that IP could not be spoofed through other interface while IPsec policy would eventually be disabled (when the policy is active, packets matching the traffic selector of the policy in receive direction are dropped if they didn’t come via the IPsec tunnel).
