Hi, I’m having a problem with the firewall on my router.
My setup is as follows:
ISP → Modem → Hap AC2
Wan is using pppoe with dynamic public IP. I have set up the IP cloud and I can access the web config page through the IP Cloud DDNS when I allow for port 80 in the firewall.
I have tested it on both windows 10 and Windows 7.
RouterOS is version 6.45.7
So I have set up a L2TP server with IPSec. I can access it from the LAN, but not from the WAN. Here are my firewall rules:
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input in-interface=pppoe1 port=500,1701,4500 protocol=udp
add action=accept chain=input in-interface=pppoe1 protocol=ipsec-esp
add action=accept chain=input in-interface=pppoe1 protocol=ipsec-ah
add action=accept chain=input in-interface=pppoe1 protocol=l2tp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface=pppoe1
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe1
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
I’m not able to connect from WAN with the above config. But if I disable the rule:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface=pppoe1
Then I can connect to the vpn. However, obviously this is not recommended, as I immediately logged IP addresses trying to log into my network.
What other things should I try? Thanks in advance.
I cannot see anything among your chain=input rules that would explain this behaviour.
But please replace the rule action=accept chain=input protocol=udp port=500,1701,4500 by two rules: action=accept chain=input protocol=udp **dst-**port=500,4500
action=accept chain=input protocol=udp **dst-**port=1701 ipsec-policy=in,ipsec
The reasons are the following:
port matches also on source port, which means that if someone manages to send a DNS request from UDP port 500,1701, or 4500, he will get through to the DNS server listening on your Mikrotik,
for the reason above, this match condition is rarely used, so it may be actually broken but no one may have noticed that, which would explain why you have to remove the “drop anything else coming in via pppoe1” in order to get the L2TP/IPsec connection extablished,
access to L2TP ports should only be possible after the IPsec layer is up. Some clients permit fallback to L2TP without encryption if IPsec parameters cannot be negotiated, which is normally not what you want to permit
Originally I did use dst-port, but since it did not work, I changed it to “any port”, because I somehow thought that the communication was not able to be established because the ports were blocked when going out. That’s what I surmised from why disabling the “drop all not coming from LAN on pppoe1” solves the issue.
I further experimented on the rules, and found that I have to disable the rules for port 50 and 51, otherwise it somehow would not work, not sure why.
I assume you have in mind the rules for protocols 50 and 51, i.e. ESP and AH. To be honest, it is a surprise for me that disabling them makes it work better. Is the client on public IP? Because if yes and since the Tik has a public IP too, use of raw ESP should be negotiated, if the client is (or if the Mikrotik was) behind a NAT, the ESP is encapsulated into UDP on port 4500. So either the ESP rule should be necessary for it to work (it is the client who sends the first L2TP packet, so the ESP must be permitted in chain=input as the connection will not be established by a packet sent by the Tik) or it should be irrelevant (as the IPsec control communication and the transport communication both use UDP port 4500).
Yes I mean protocols ESP and AH on port 50 and 51, and the client is behind a NAT. I thought it would be necessary as well to include it, but apparently not. Enabling them makes me unable to connect - whereas disabling them enables the connection. Logically though, that should not matter, since the rule is accept, not drop. But for some reason that works.
Just terminologically, IP protocol number is not the same thing like port number. A payload protocol of IP called UDP has protocol number 17 and uses source and destination ports (0..65535 each), a payload protocol of IP called TCP has protocol type 6 and also uses source and destination ports (0..65535 each), whereas payload protocols of IP called GRE, ESP, AH have protocol numbers 47, 50, 51 respectively. Many other payload protocols of IP exist, only few of them use the notion of ports as an extension of the IP address allowing to distinguish connections between two IPs from one another. The absence of the notion of ports in ESP is the reason why for NAT traversal, ESP has to be encapsulated into UDP.