My firewall rules are below. I’ve setup a new unit pretty much identically to other units I have working with IPsec, but this is the first unit I’ve used with PPPoE (with rules added for PPPoE).
If I disable this rule:
add action=drop chain=input comment=“part of pppoe I guess” in-interface=pppoe-out1
…it seems I can get traffic to move across the tunnel (at least a ping to the MikroTik). But it also seems like I’m creating a giant security hole. For example, by disabling that rule, I can access the MikroTik router via webfig over the WAN from any address, not just the addresses on my whitelist.
Is there a way to modify the rules I have below, so the tunnel works but I don’t create a security problem for myself?
TIA for any help!!!
/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
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=“Allow remote config from whitelist” dst-port=80,23 protocol=tcp src-address-list=whitelist
add action=accept chain=input comment=“Allow DNS through VPN” dst-port=53 protocol=udp src-address=192.168.2.254
add action=drop chain=input comment=“defconf (edited): drop all coming from WAN (changed from !LAN)” in-interface-list=WAN
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=input comment=“part of pppoe I guess” in-interface=pppoe-out1
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=accept chain=srcnat comment=“vpn packets” dst-address=192.168.2.0/23 src-address=192.168.252.0/24
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat out-interface=pppoe-out1
BTW, if I add Src. Address ! 192.168.2.0/23 to that drop rule in question above, I seem to be able to ping the router from the other side of the tunnel, and seems to prevent accessing the router’s webfig, etc., from the WAN, but I’m not sure if that would be the correct approach.
Thought No.1: The default firewall you seem to base on assumes that all WAN interfaces are members of an interface list named WAN. So by adding your newly created pppoe-out1 as a member of that /interface list you get the same functionality of your firewall to which you are used at the other devices.
Thought No.2: Unless all the addresses in /ip firewall address-list name=whitelist are private ones in your LAN, the following rule is a really bad idea: add action=accept chain=input comment=“Allow remote config from whitelist” dst-port=80,23 protocol=tcp src-address-list=whitelist
Whoever can wiretap (sniff, capture - it’s all different names for the same thing) the traffic between you and any of these addresses can get the usernames and passwords. Telnet transfers them in plaintext, cracking the www authentication is a matter of hours if you have enough zombies to distribute the brute force attack among. And any compromised router can do wiretapping for no-one-knows-whom. And if it is in a good enough position in the network for wiretaping, it can equally easily spoof packets in the name of one of the whitelisted addresses and get the responses. All that can happen automatically, remotely controlled, without the owner of that device to be aware.
Thought No.3: If by “VPN” you mean the IPsec VPN (as your first rule in the /ip firewall nat suggests), then this rule add action=accept chain=input comment=“Allow DNS through VPN” dst-port=53 protocol=udp src-address=192.168.2.254
is redundant because the following rule add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
lets those packets in as well.
If you mean some other VPN, then the first rule should also refer to the virtual interface of that VPN as in-interface. Otherwise your device will respond to packets with forged address 192.168.2.254 actually coming from anywhere else and send the responses to 192.168.2.254. It probably doesn’t cause much harm but if the spoofed packets are properly formatted DNS queries, the DNS process of the Mikrotik will process them completely (send a request to the external DNS server, cache the response and forward it to 192.168.2.254). So waste of CPU as a minimum.
Thought No.4: once you follow Thought No.1, you may probably undo the change on the following rule: add action=drop chain=input comment=“defconf (edited): drop all coming from WAN (changed from !LAN)” in-interface-list=WAN
and drop completely this one: add action=drop chain=input comment=“part of pppoe I guess” in-interface=pppoe-out1
Thought No.5: see Thought No.1 regarding the following /ip firewall nat rule: add action=masquerade chain=srcnat out-interface=pppoe-out1
Holy smokes that is helpful, you don’t have any idea how much I appreciate this help.
It will take me a little while to digest this (especially the part about adding the pppoe interface to the WAN), but I will note that the purpose of that “whitelist” address list for remote management is, for me to be able to get into the router because it is in a different state, and nobody there has any IT skills.
Is there a better way to setup remote management? I doubt I’ll ever use it once things are running, but it has already saved my butt a few times while I’m trying to get the tunnel running.
Lucky guy to have the router as close as different state, some of mine are at different continents
If you were happy with telnet up until now, you can swicth to ssh which gives you the same level of user (dis)comfort like telnet but much higher security. It requires to permit ssh on the device using /ip service set ssh disabled=no port=some-number-between-10000-and-65534, add that port number to the rule I’ve criticised, and then /ip ssh set strong-crypto=yes, /ip ssh set host-key-size=4096 (or 8192 if you want), /ip ssh regenerate-host-key (this last step may take veeery long if the router is weak so the connection may even be lost during that time; don’t panic and log in again in 5 minutes or so).
Assuming you don’t use Windows because you use WebFig rather than Winbox, you can use command line ssh on linux - ssh the.mikrotik.address -p the-port-number-you-have-chosen, just like you did with telnet. If my guess is wrong and you use Windows, download PuTTY.
Once you get in using ssh, create a new user with new password and the same access privileges like the current one, log out, log in again, and if you succeed, disable the previous user and remove port 23 from the permissive rule.
Regarding Webfig, one way is to use ssh port forwarding to connect to the www (http) port 80, so that you would connect to the 'Tik as if from itself via the ssh tunnel, i.e. the encryption would be provided by the ssh. It might require to add some permissive firewall rule to work. Or you may generate a self-signed certificate on the 'Tik (there are tutorials on that out there) and enable wwws with that certificate, again on some non-standard port you would permit in the firewall rule. Depending on your browser, the number and colour of security warnings may differ, you should be able to mitigate them by downloading the certificate public part from the router and telling your PC/browser it is a trusted one.
Again, thank you for all the constructive help. I have some other routers configured similarly to this one, I’ll make sure I’m using ssh in the near future.
Right now I’m just watching to see if my modification to the pppoe drop rule keeps the tunnel working, it seemed to stop sending traffic a couple of times. But it is possible that the people in the office came in this morning and restarted the router because I know some devices were not communicating after changes I had made.
I understand my rules need help, but if they work for now they will buy me some time to evaluate your post more.
I felt like I had a pretty good handle on beginners setup of the Mikrotik units but then the PPPoE install at this location tossed me for a loop.
