The official Mikrotik router thread

Eish,

Scratching my head here...

Something in my Mikrotik Firewall setup is preventing my Cloudkey from accessing the internet which means that its unable to update date, time or run package updates.

I can ping other devices on the internal network (behind the Firewall) but can't ping any external addresses.

My knowledge of RouterOS is rudimentary at best so I'm a bit stumped.

I need a rule that will allow the Cloudkey (static IP) to access the internet...

Any help appreciated.
 
Eish,

Scratching my head here...

Something in my Mikrotik Firewall setup is preventing my Cloudkey from accessing the internet which means that its unable to update date, time or run package updates.

I can ping other devices on the internal network (behind the Firewall) but can't ping any external addresses.

My knowledge of RouterOS is rudimentary at best so I'm a bit stumped.

I need a rule that will allow the Cloudkey (static IP) to access the internet...

Any help appreciated.
Would you be able to post your firewall config?
 
Would you be able to post your firewall config?
0 ;;; default configuration
chain=forward action=accept connection-state=established log=no log-prefix=""

1 ;;; default configuration
chain=forward action=accept connection-state=related log=no log-prefix=""

2 ;;; default configuration
chain=forward action=drop connection-state=invalid log=no log-prefix=""

3 ;;; Allow established connections from Internet to router
chain=input-internet action=accept connection-state=established log=no log-prefix=""

4 ;;; Allow PPTP VPN connections from Internet to router
chain=input-internet action=accept protocol=tcp dst-port=1723 log=no log-prefix=""

5 ;;; Drop other connections from Internet to router
chain=input-internet action=drop log=no log-prefix=""

6 ;;; Allow established connections from Internet to router
chain=input-internet action=accept connection-state=established log=no log-prefix=""

7 ;;; Allow PPTP VPN connections from Internet to router
chain=input-internet action=accept protocol=tcp dst-port=1723 log=no log-prefix=""

8 X ;;; OLD ISP
chain=forward action=passthrough in-interface=*15 out-interface=*15 log=no log-prefix=""

9 ;;; CURRENT ISP
chain=forward action=passthrough in-interface=CURRENT_ISP out-interface=CURRENT_ISP log=no log-prefix=""

10 X ;;; OLD ISP
chain=forward action=passthrough in-interface=OLD ISP out-interface=OLD ISP log=no log-prefix=""

11 chain=output protocol=tcp content=530 Login incorrect dst-limit=1/1m,9,dst-address/1m

12 chain=output action=add-dst-to-address-list protocol=tcp address-list=ftp_blacklist address-list-timeout=3h content=530 Login incorrect

13 chain=input action=accept protocol=icmp

14 chain=input action=accept connection-state=established

15 chain=input action=accept connection-state=related

16 chain=input action=drop in-interface-list=!mactel log=no log-prefix=""

17 chain=input action=drop protocol=udp in-interface=CURRENT_ISP dst-port=53

I tried the following rule at line 3 but it didn't help.

3 X ;;; Allow Cloudkey through Firewall
chain=forward action=accept src-address=IP_ADDRESS_OF_CLOUDKEY log=no log-prefix=""
 
Eish,

Scratching my head here...

Something in my Mikrotik Firewall setup is preventing my Cloudkey from accessing the internet which means that its unable to update date, time or run package updates.

I can ping other devices on the internal network (behind the Firewall) but can't ping any external addresses.

My knowledge of RouterOS is rudimentary at best so I'm a bit stumped.

I need a rule that will allow the Cloudkey (static IP) to access the internet...

Any help appreciated.

If your cloudkey is on the same network as the rest of your natted network then there should be no need to create a special rule for the cloudkey. It should just be able to connect to the internet provided it has the correct gateway and subnet mask.

BTW, on my Mikrotik I always use DHCP to supply static ip addresses to certain devices instead of manually adding a static ip address to the device.
 
If your cloudkey is on the same network as the rest of your natted network then there should be no need to create a special rule for the cloudkey. It should just be able to connect to the internet provided it has the correct gateway and subnet mask.

BTW, on my Mikrotik I always use DHCP to supply static ip addresses to certain devices instead of manually adding a static ip address to the device.

Thanks. Thats what I thought should happen but the bloody Cloudkey just doesn't seem to want to play ball.

Oh yes, the static IP is being supplied via the Mikrotik DHCP.
 
Can you ping the cloudkey from other devices in the network, like your laptop?
Yep, no problem pinging the Cloudkey

ping xxx.xxx.xxx.xxx Pinging xxx.xxx.xxx.xxx with 32 bytes of data: Reply from xxx.xxx.xxx.xxx: bytes=32 time=1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Ping statistics for xxx.xxx.xxx.xxx: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
 
Yep, no problem pinging the Cloudkey

ping xxx.xxx.xxx.xxx Pinging xxx.xxx.xxx.xxx with 32 bytes of data: Reply from xxx.xxx.xxx.xxx: bytes=32 time=1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64 Ping statistics for xxx.xxx.xxx.xxx: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms

On your drop rules do you want to perhaps activate logging then try see if the cloudkey packets / ICMP packets are being dropped?

Also checking you don't have any RAW FW rules setup?
 
On your drop rules do you want to perhaps activate logging then try see if the cloudkey packets / ICMP packets are being dropped?

Also checking you don't have any RAW FW rules setup?

Right - switched on the logging, nothing being dropped by the router from that IP.

That led me to thinking a bit more, so, then switched on the Override Rule (chain=forward action=accept src-address=IP_ADDRESS_OF_CLOUDKEY log=no log-prefix="" ) and checked that log...

When I ping an internal address (success), this is what I see:

Sep/08/2020 11:48:05 firewall,info ckfirewall forward: in:bridge-local out:ISP_Name, src-mac mac:address:cloudkey, proto UDP, IP.ADDRESS.OF.CK:42807->196.25.1.5:123, len 76

[I don't recognise the IP address in red but the ping command gives me a normal result.

When I ping an external address (fail) 8.8.8.8 , this is what I see

Sep/08/2020 11:48:45 firewall,info ckfirewall forward: in:bridge-local out:ISP_Name, src-mac mac:address:cloudkey, proto ICMP (type 8, code 0), IP.ADDRESS.OF.CK->8.8.8.8, len 84

and nothing....
 
Right - switched on the logging, nothing being dropped by the router from that IP.

That led me to thinking a bit more, so, then switched on the Override Rule (chain=forward action=accept src-address=IP_ADDRESS_OF_CLOUDKEY log=no log-prefix="" ) and checked that log...

When I ping an internal address (success), this is what I see:

Sep/08/2020 11:48:05 firewall,info ckfirewall forward: in:bridge-local out:ISP_Name, src-mac mac:address:cloudkey, proto UDP, IP.ADDRESS.OF.CK:42807->196.25.1.5:123, len 76

[I don't recognise the IP address in red but the ping command gives me a normal result.

When I ping an external address (fail) 8.8.8.8 , this is what I see

Sep/08/2020 11:48:45 firewall,info ckfirewall forward: in:bridge-local out:ISP_Name, src-mac mac:address:cloudkey, proto ICMP (type 8, code 0), IP.ADDRESS.OF.CK->8.8.8.8, len 84

and nothing....

That IP is in the telkom IP space - not sure if this means anything to you

The only other option would be to systematically disable each rule in turn and try test?
 
SSH in to your key if you havent already - didnt read all posts.... ping and check routes from there, disable firewall until you get it right but starting at the source might help

root@ck-plus:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.8.1 0.0.0.0 UG 0 0 0 eth0
172.16.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
 
SSH in to your key if you havent already - didnt read all posts.... ping and check routes from there, disable firewall until you get it right but starting at the source might help

root@ck-plus:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.8.1 0.0.0.0 UG 0 0 0 eth0
172.16.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Did that - all seems ok from there

Can ping everything internal to the network; nothing outside

root@UniFi-CloudKey:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default xxx.xxx.xx.1 0.0.0.0 UG 1024 0 0 eth0
xxx.xxx.xx.0 * 255.255.255.0 U 0 0 0 eth0
xxx.xxx.xx.1 * 255.255.255.255 UH 1024 0 0 eth0
root@UniFi-CloudKey:~#
 
Did that - all seems ok from there

Can ping everything internal to the network; nothing outside

root@UniFi-CloudKey:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default xxx.xxx.xx.1 0.0.0.0 UG 1024 0 0 eth0
xxx.xxx.xx.0 * 255.255.255.0 U 0 0 0 eth0
xxx.xxx.xx.1 * 255.255.255.255 UH 1024 0 0 eth0
root@UniFi-CloudKey:~#

The only other thing I can think of is that for some reason the internal IP address that is assigned to the cloudkey is not being natted. Check your firewall nat masquerade rule, maybe it's set to only masquerade for a subset of ip addresses instead your entire internal range.
 
Did that - all seems ok from there

Can ping everything internal to the network; nothing outside

root@UniFi-CloudKey:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default xxx.xxx.xx.1 0.0.0.0 UG 1024 0 0 eth0
xxx.xxx.xx.0 * 255.255.255.0 U 0 0 0 eth0
xxx.xxx.xx.1 * 255.255.255.255 UH 1024 0 0 eth0
root@UniFi-CloudKey:~#
Somethings odd there bud whats the last IP - dont hide the IP address unless they are public as we cant do anything to your private IP's. If you dont want to show them thats fine but why have you got a 255.255.255.255 netmask?
 
Somethings odd there bud whats the last IP - dont hide the IP address unless they are public as we cant do anything to your private IP's. If you dont want to show them thats fine but why have you got a 255.255.255.255 netmask?

No idea.

Only have 1 config under DHCP Server - Networks

Address: 192.168.0.0/24
Gateway: 192.168.0.1
Netmask: 24

DNS Servers: 192.168.0.1



root@UniFi-CloudKey:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 1024 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.1 * 255.255.255.255 UH 1024 0 0 eth0
root@UniFi-CloudKey:~#
 
No idea.

Only have 1 config under DHCP Server - Networks

Address: 192.168.0.0/24
Gateway: 192.168.0.1
Netmask: 24

DNS Servers: 192.168.0.1



root@UniFi-CloudKey:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 1024 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.1 * 255.255.255.255 UH 1024 0 0 eth0
root@UniFi-CloudKey:~#

If you ssh into the cloudkey, can you ping an external host just by IP address? E.g. try pinging 8.8.8.8. Might be a DNS issue. Also, what happens if you do a traceroute from the cloudkey?
 
If you ssh into the cloudkey, can you ping an external host just by IP address? E.g. try pinging 8.8.8.8. Might be a DNS issue. Also, what happens if you do a traceroute from the cloudkey?

Nope - can't ping any external hosts from the Cloudkey - only internal

Cloudkey doesn't recognise 'traceroute' as a command - has a very rudimentary set of linux commands available
 
Sweet Mother of G*D!

Having eventually run out of ideas I changed the IP address of the CK (via the Mikrotik).....

o_O

and now everything is working o_Oo_O

for goodness sake...

Huge thank you to everyone for all your suggestions

PS: Traceroute now installed :)
 
Top
Sign up to the MyBroadband newsletter
X