Hello,
I just upgraded ROS from 6.49.5 to 7.2 and remote management to WAN doesnt work anymore. Did anything change? I have enabled port 8291 in Firewall and it is locked down to 3 networks I am accesing it from.
Re: Remote management on WAN
Maybe best to post your config so we can have a look.
/export file= anynameyouwish
Review for sensitive info and post between [code] quotes.
/export file= anynameyouwish
Review for sensitive info and post between [code] quotes.
Re: Remote management on WAN
Here it is:
Code: Select all
# apr/12/2022 13:44:16 by RouterOS 7.2
# software id = 4VLT-G4K3
#
# model = RBD53iG-5HacD2HnD
# serial number = F34E0F6BD6E0
/interface bridge
add admin-mac=DC:2C:6E:13:6C:13 auto-mac=no name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
disabled=no distance=indoors frequency=auto installation=indoor mode=\
ap-bridge ssid=ap-snkfd wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
20/40/80mhz-XXXX disabled=no distance=indoors frequency=auto \
installation=indoor mode=ap-bridge ssid=ap-snkfd wireless-protocol=\
802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk eap-methods="" \
mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan1
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set max-neighbor-entries=8192
/interface list member
add interface=bridge list=LAN
add interface=ether1 list=WAN
/interface ovpn-server server
set auth=sha1,md5
/ip address
add address=192.168.88.1/24 interface=bridge network=192.168.88.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="mikrotik remote management" dst-port=\
8291 protocol=tcp
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=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
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 hw-offload=yes
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 comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="snkfd-srv ssh" in-interface=\
ether1 protocol=tcp to-addresses=192.168.88.234 to-ports=22
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set winbox address=192.168.88.0/24,10.78.146.0/23,10.78.128.0/23,10.77.8.0/23
set api-ssl disabled=yes
/ipv6 address
add address=::1 from-pool=pf interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=pf request=\
address,prefix
/ipv6 nd
set [ find default=yes ] ra-interval=20s-1m
add interface=bridge ra-interval=20s-1m
/system clock
set time-zone-name=Europe/Prague
/system leds
set 0 interface=wlan1 leds=led1,led2,led3,led4,led5 type=\
wireless-signal-strength
set 1 leds=poe-led type=poe-out
/system package update
set channel=testing
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LANRe: Remote management on WAN
According to this rule there is no restriction on IP address, so it should be open for everyone.
You might want to activate logging to be able to do some debugging.
Are you testing from another location?
You might want to activate logging to be able to do some debugging.
Are you testing from another location?
Code: Select all
/ip firewall filter
add action=accept chain=input comment="mikrotik remote management" dst-port=\
8291 protocol=tcp
Re: Remote management on WAN
Not really "no restriction":
only those private addresses.
Code: Select all
/ip service
set winbox address=192.168.88.0/24,10.78.146.0/23,10.78.128.0/23,10.77.8.0/23
Re: Remote management on WAN
All of the IPs on your "set winbox address" line are RFC 1918 private subnets.
Re: Remote management on WAN
@tangent, I hope @snakefood understand...
Re: Remote management on WAN
Yeah, of course. Network behind NAT, internal network and two networks where VPN is (both VPN IPs are fixed, so having enabled two more networks might be too much, but whatever..) I am getting inside exclusively just through VPN hosted in private network.All of the IPs on your "set winbox address" line are RFC 1918 private subnets.
Anyways, I will enable some more logging and will be back afterwards.
Re: Remote management on WAN
And only now you say "I use VPN"???????
Re: Remote management on WAN
Huh? Pardon me, I am confused. I think it has nothing to do with that. And it doesnt really matter if I use or dont use VPN.And only now you say "I use VPN"???????
Re: Remote management on WAN
Network behind NAT
Not if you're making use of that firewall rule on line 55, which allows direct connection to port 8291 from the WAN side. To make that usable, you'd have to put your WAN IP into the address list I pointed out.
But don't do that. Your IPsec VPN is likely much stronger than WinBox's encryption.
it doesnt really matter if I use or dont use VPN.
It does if your VPN IP address is in the winbox address list but your public IP is not.
Re: Remote management on WAN
Not if you're making use of that firewall rule on line 55, which allows direct connection to port 8291 from the WAN side. To make that usable, you'd have to put your WAN IP into the address list I pointed out.
Yes, as I need to access Mikrotik from virtual machine which is obviously out of my home network (ESXi hosted elsewhere in the network), but it is located in same private network. So I thought, I will just open 8291 in firewall and will restrict the service itself by setting networks explicitly. Mikrotik could be reached from Internet as it has public IPv4 tight to its private network IP, but I would like better to see it closed.
It does if your VPN IP address is in the winbox address list but your public IP is not.
I am not quite sure what you mean by that, because Mikrotik IP from my private network has assigned public IP to it. But it is not set up anywhere.
However this does not solve my problem at all, I need to go back to the logs and see why remote management doesnt work as it responds with ERROR: Router has refused connection.
Re: Remote management on WAN
I am testing from 2 different locations with "debug" enabled. Nothing shows up in the log. Winbox just says ERROR: Router refused connection.According to this rule there is no restriction on IP address, so it should be open for everyone.
You might want to activate logging to be able to do some debugging.
Are you testing from another location?Code: Select all/ip firewall filter add action=accept chain=input comment="mikrotik remote management" dst-port=\ 8291 protocol=tcp
Re: Remote management on WAN
The llama has arrived......
(1) Firstly, dont be a dufus and tell the whole world your winbox port. Change it from default and post XXXX on any config you present here.
(2) The others are right its poorly formulated (at least on the input chain itself wide open to LAN and WAN).
Ask yourself the simple question who needs access to the router for config purpose - Only the admin.....
add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized
You will need to allow LAN users access to DNS services.
and then complete the config by dropping all other traffic as the last rule in the input chain
Finally - at least stick the rule after the default rules of established, drop invalid, accept icmp ---------then your rules......
(3) I see that you also have some what I can only assume is some VPN addresses allowed to winbox as well, /
Where is the interface for the VPN I dont see anything in the config to indicate you have a VPN here, no input chain rules etc...........
(4) DST NAT RULE IS MISSING dst-port and protocol
(1) Firstly, dont be a dufus and tell the whole world your winbox port. Change it from default and post XXXX on any config you present here.
(2) The others are right its poorly formulated (at least on the input chain itself wide open to LAN and WAN).
Ask yourself the simple question who needs access to the router for config purpose - Only the admin.....
add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized
You will need to allow LAN users access to DNS services.
and then complete the config by dropping all other traffic as the last rule in the input chain
Finally - at least stick the rule after the default rules of established, drop invalid, accept icmp ---------then your rules......
(3) I see that you also have some what I can only assume is some VPN addresses allowed to winbox as well, /
Where is the interface for the VPN I dont see anything in the config to indicate you have a VPN here, no input chain rules etc...........
(4) DST NAT RULE IS MISSING dst-port and protocol
Re: Remote management on WAN
Dont think, instead - PROVIDE missing information. There is something not clear on your VPN and how you access this router externally that is not well understood.Huh? Pardon me, I am confused. I think it has nothing to do with that. And it doesnt really matter if I use or dont use VPN.And only now you say "I use VPN"???????
A diagram may help.
If you knew all the answers you wouldnt be asking for help, so help us help you by not making assumptions of what is or isnt relevant!!
Re: Remote management on WAN
My suggestion for this rule is as follows:The llama has arrived......
......
add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized
add chain=input action=accept in-interface-list=!WAN dst-port=8291 protocol=tcp src-address-list=Trusted
Why, to accept Winbox from everywhere except WAN for VPN specifically ... for the admin this IMO scales far better and prevents WAN exploits.
This way the port for Winbox can remain the default.
Re: Remote management on WAN
Dont think, instead - PROVIDE missing information. There is something not clear on your VPN and how you access this router externally that is not well understood.
Huh? Pardon me, I am confused. I think it has nothing to do with that. And it doesnt really matter if I use or dont use VPN.
A diagram may help.
If you knew all the answers you wouldnt be asking for help, so help us help you by not making assumptions of what is or isnt relevant!!
I absolutely agree with you, however from user perspective, it worked on 6.49.5, it suddenly doesn’t on 7.2. No changes were made. VPN is not served by Mikrotik, so the impact on it should be close to zero. This is the reason I ommited it. I can also draw a diagram for making it crystal clear.
For now I am going to absorb @anav hints and make sure its everything set up correctly. I admit I am llama as I have hAP for a week or so … hooray lets go back and learn from mistakes. I will report back with the progress.
Re: Remote management on WAN
Awesome, looking forward to it...........
Re: Remote management on WAN
Well its better than it was before, but also I prefer clear direct targettng and thus do not like any use of ! symbol unless absolutely necessary.My suggestion for this rule is as follows:The llama has arrived......
......
add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized
add chain=input action=accept in-interface-list=!WAN dst-port=8291 protocol=tcp src-address-list=Trusted
Why, to accept Winbox from everywhere except WAN for VPN specifically ... for the admin this IMO scales far better and prevents WAN exploits.
This way the port for Winbox can remain the default.
( you may use it properly but like RAW firewall rules, in the hands of a beginner or learner, it can be dangerous!! )
It is also redundant anyway because my input chain rule LAST RULE is drop all anyway, so I dont need no stinking ! crap :-0
You do have a point though!!!
Where it scales better for example is when you have multiple inject interfaces!
example 1 - the admin has IPs on a bunch of LAN subnets not just the trusted subnet and wants to be able to config the router from any location within the network
example 2 - the admin is coming in over a different interface (IE VPN)
Alternatives........
- one can add the wireguard interface to the trusted interface list as one option
- one can add a separate rule for VPN besides the above rule.
Re: Remote management on WAN
On further inspections. DISAGREE WITH WINBOX Port staying as default, CHANGE IT should be the automatic admin action!!!My suggestion for this rule is as follows:The llama has arrived......
......
add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized
add chain=input action=accept in-interface-list=!WAN dst-port=8291 protocol=tcp src-address-list=Trusted
Why, to accept Winbox from everywhere except WAN for VPN specifically ... for the admin this IMO scales far better and prevents WAN exploits.
This way the port for Winbox can remain the default.
Lets discuss in-interface-list=!WAN,
The problem I have with this one is more a question. What does that rule actually mean?
Does it mean allow all other interfaces list entries LAN, TRUSTED, MANAGMENT etc.............. if so ITS NO GAIN IMHO, because I can
always identify the list members I want to be trusted.........
Futhermore it FAILS to address an interface or entity that is NOT described under and interface list.
For example WIREGUARD can be an interface member but other VPNs cannot so your rule doesnt allow them becuase they are not on any interface list as a member!!!
Thinking this is better
" in-interface=!ether1" (or pppoe-out or ISP vlan etc......).
In this way what we are saying is that any interface other than the WAN interface is okay................................
Personally I would probably make two rules before getting to this point.
Re: Remote management on WAN
@anav
The admin wants to eliminate the threat posed by the WAN and the Winbox Port … by not allowing any “outside” connection to hit that port no need to change the default port. VPN on the other hand provides the needed security and path for “trusted devices” so that any interface inside can be accessed if so desired without jumping hoops or creating more rules … this is the KISS principle.
What is more important is the elimination of the default name used for Admin and its associated password … “admin” must be changed and a proper complex password used. Over the past few years that I have been asked to review Tik configs by very knowledgeable people all of whom used admin because they were to lazy to change it or what most stated was that they liked that name. The audience on this forum are mostly people who are new to Tik or experienced techs all of which perform Admin duties … it’s my opinion that to be an effective admin — security and flexibility is desirable by most and KISS principles apply because they are not here as PHD users…..
The admin wants to eliminate the threat posed by the WAN and the Winbox Port … by not allowing any “outside” connection to hit that port no need to change the default port. VPN on the other hand provides the needed security and path for “trusted devices” so that any interface inside can be accessed if so desired without jumping hoops or creating more rules … this is the KISS principle.
What is more important is the elimination of the default name used for Admin and its associated password … “admin” must be changed and a proper complex password used. Over the past few years that I have been asked to review Tik configs by very knowledgeable people all of whom used admin because they were to lazy to change it or what most stated was that they liked that name. The audience on this forum are mostly people who are new to Tik or experienced techs all of which perform Admin duties … it’s my opinion that to be an effective admin — security and flexibility is desirable by most and KISS principles apply because they are not here as PHD users…..
Re: Remote management on WAN
Hi Mozerd agree with you 100% and thus may be adjusting my firewall user article.
I just have to clarify the difference in my mind between
interface=!ether1
and
interface-list=!WAN
I was hoping sob would knock some sense into me.............. I need a vigorous massage!!
I just have to clarify the difference in my mind between
interface=!ether1
and
interface-list=!WAN
I was hoping sob would knock some sense into me.............. I need a vigorous massage!!
Re: Remote management on WAN
router refused connection is not a drop rule in the firewall, and if it was the user settings I think it says it was a bad login even if it was due to the IP address, I think that the IP address that OP is coming from through the tunnel is not in the ip>services list