Community discussions

MikroTik App
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Unable to update CCR

Wed May 13, 2020 10:52 pm

I am unable to update RouterOS, the setup is complex but there are no issues with regard to traffic. Bizarrely a similar CCR which is at the other end of a L2TP connection is able to Update normally.

Happy to post logs but would need instructions.

Current Version is 6.45.8
ping to mikrotik.com is successful
ping to upgrade.mikrotik.com is successful

Thanks
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Wed May 13, 2020 11:31 pm

What happens if you attempt to do the update? Do you get any error message? How does the failing manifest itself?

Not sure, just a guess: there could be a setting that prevents any updates; would need first to change that setting.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 13, 2020 11:36 pm

What happens if you attempt to do the update? Do you get any error message? How does the failing manifest itself?
In the Check for Updates Window:

ERROR: connection timed out


Thanks,
Andrew.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Wed May 13, 2020 11:49 pm

Can you issue the following in the terminal (CLI) and post the output:
/system package update check-for-updates

At this very moment the update server is operational from my location in Central Europe. It says in my case the following:
[admin2@CRS326] > /system package update check-for-updates
channel: development
installed-version: 7.0beta5
latest-version: 7.0beta5
status: System is already up to date
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Thu May 14, 2020 12:03 am

At this very moment the update server is operational from my location in Central Europe. It says in my case the following:
[admin2@CRS326] > /system package update check-for-updates
channel: development
installed-version: 7.0beta5
latest-version: 7.0beta5
status: System is already up to date
I get:

[admin@Malford1016] >> /system package update check-for-updates
channel: long-term
installed-version: 6.45.8
status: ERROR: connection timed out
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 12:14 am

Try this too:
/tool fetch mode=https url="https://update.mikrotik.com/dummy.html"

Do you get something different than 404 ?

It could be a firewall issue at your side. ping uses a different protocol (ICMP) than https (TCP),
and the IP of update.mikrotik.com seems to have changed in the DNS.
A few days ago it had these 2 IPs:
159.148.147.204
159.148.172.226

but today it has just this (new?) IP:
159.148.147.205

So, it could also be a DNS server issue, ie. maybe it could also be possible that it's not yet replicated to your DNS server.

Try via IP too:
/tool fetch mode=https url="https://159.148.147.205/dummy.html"

Should give error "404 Page Not Found", but this indicates that the connection at least was ok.


UPDATE: they are 2 different domains, as follows:

1)
Name: update.mikrotik.com
Address: 159.148.147.205

2)
upgrade.mikrotik.com canonical name = download.mikrotik.com.
Name: download.mikrotik.com
Address: 159.148.147.204
Name: download.mikrotik.com
Address: 159.148.172.226
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Thu May 14, 2020 2:12 pm

/tool fetch mode=https url="https://update.mikrotik.com/dummy.html"
/tool fetch mode=https url="https://159.148.147.205/dummy.html"
I've tried those as well as 172.226 and all give me:

[admin@Malford1016] > /tool fetch mode=https url="https://159.148.172.226/dummy.html"
status: failed
failure: connection timeout

I have also changed the DNS setting to 1.1.1.1 to isolate the P-Hole based White/Black list and get the same result. I've tried with and without "Allow remote requests"

I have another CCR in a remote location whose DNS is set by RouterOS to 1.1.1.1 and it updates fine. That is connected to the home location via L2TP.

Thanks.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 2:56 pm

/tool fetch mode=https url="https://update.mikrotik.com/dummy.html"
/tool fetch mode=https url="https://159.148.147.205/dummy.html"
I've tried those as well as 172.226 and all give me:

[admin@Malford1016] > /tool fetch mode=https url="https://159.148.172.226/dummy.html"
status: failed
failure: connection timeout

I have also changed the DNS setting to 1.1.1.1 to isolate the P-Hole based White/Black list and get the same result. I've tried with and without "Allow remote requests"

I have another CCR in a remote location whose DNS is set by RouterOS to 1.1.1.1 and it updates fine. That is connected to the home location via L2TP.

Thanks.
It very much looks like that in your firewall rules on this device all traffic originating from that device, except ICMP (ping), gets blocked. Maybe a security setting by you or your co-admins?
If there is any other firewall on the way between this device and the WAN, then you should check it too for the cause.

So, you should first ensure that your device can make TCP connections to the WAN (ie. try to get the index.html of other web sites with the above said fetch tool).

You could also export and post here your config with this CLI command:
/export hide-sensitive file=myconfig.rsc
It will be put into the Files area on the device. Via Winbox/Webfig/ssh/telnet etc. you can download it to your PC.
It is a text file. You can inspect it and remove/edit any sensitive private data, and then post it here for analysis by others.

You can of course also compare that config with the config of your other working device that you mentioned.

Another possibility is to download the correct file from here https://www.mikrotik.com/download and install it manually as described here:
https://wiki.mikrotik.com/wiki/Manual:U ... de_methods

As can be seen, you have many alternatives to chose from :-)
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Thu May 14, 2020 3:26 pm

/export hide-sensitive file=myconfig.rsc
The time won't update either, seems to be about a minute out.

This is the config of the Problematic CCR (below that is the remote CCR which has no issues):
# may/14/2020 13:15:01 by RouterOS 6.45.8
# software id = PZJX-KJ04
#
# model = CCR1016-12G
# serial number = 42D402B557C9
/interface bridge
add fast-forward=no name=bridge-lan
add name=bridgeDRGuest
add name=bridgeGuest
/interface ethernet
set [ find default-name=ether2 ] name=BT
set [ find default-name=ether1 ] comment=\
"Virgin Modem Mode connection to DHCP Client" name=ISP-Virgin
/interface pppoe-client
add add-default-route=yes comment="BT PPPoE Client Modem Mode" \
default-route-distance=3 disabled=no interface=BT name=ISP-BT user=\
bthomehub@btbroadband.com
/ip pool
add name=pool-malford ranges=172.16.105.90-172.16.105.129
add name=pGuest ranges=10.10.10.10-10.10.10.100
add name=pDRGuest ranges=20.20.20.20-20.20.20.100
/ip dhcp-server
add address-pool=pool-malford interface=bridge-lan lease-time=1d name=\
dhcp-lan
add address-pool=pGuest disabled=no interface=bridgeGuest name=DHCPGuest
add address-pool=pDRGuest disabled=no interface=bridgeDRGuest name=\
DHCPDRGUEST
/system logging action
add email-to=andrew.gebhardt@finexlondon.com name=sendemail target=email
/interface bridge port
add bridge=bridge-lan interface=ether3
add bridge=bridge-lan interface=ether4
add bridge=bridge-lan interface=ether5
add bridge=bridge-lan interface=ether6
add bridge=bridge-lan interface=ether7
add bridge=bridge-lan interface=ether8
add bridge=bridge-lan interface=ether9
add bridge=bridge-lan interface=ether10
add bridge=bridgeDRGuest interface=ether11
add bridge=bridgeGuest interface=ether12
/ip settings
set tcp-syncookies=yes
/interface l2tp-server server
set enabled=yes
/interface pptp-server server
set enabled=yes
/interface sstp-server server
set certificate=Server default-profile=default-encryption port=8443 \
tls-version=only-1.2
/ip address
add address=172.16.105.1/24 interface=bridge-lan network=172.16.105.0
add address=192.168.1.2/24 interface=BT network=192.168.1.0
add address=192.168.2.2/24 disabled=yes interface=BT network=192.168.2.0
add address=10.10.10.254/24 interface=bridgeGuest network=10.10.10.0
add address=20.20.20.254/24 interface=bridgeDRGuest network=20.20.20.0
/ip cloud
set ddns-update-interval=2m
/ip dhcp-client
add add-default-route=no comment=\
"DHCP Client for Virgin Router in Modem Mode" dhcp-options=\
hostname,clientid disabled=no interface=ISP-Virgin use-peer-dns=no
/ip dhcp-server network
add address=10.10.10.0/24 dns-server=1.1.1.1,1.0.0.1 gateway=10.10.10.254 \
netmask=24
add address=20.20.20.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=20.20.20.254 \
netmask=24
add address=172.16.105.0/24
/ip dns
set servers=172.16.105.2
/ip firewall address-list
add address=172.16.105.0/24 list=allowed
add address=172.16.110.0/24 list=allowed
add address=2.87.174.170 disabled=yes list=allowed
add address=2.87.174.170 list=TinosIP
/ip firewall filter
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=\
172.16.105.0/24
add action=accept chain=input src-address-list=allowed
add action=accept chain=input protocol=icmp
add action=accept chain=forward connection-state=established,related,new
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input disabled=yes protocol=ipsec-ah
add action=accept chain=input disabled=yes protocol=ipsec-esp
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=udp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=udp
add action=drop chain=input connection-state=invalid in-interface=ISP-Virgin
add action=drop chain=input connection-state=invalid in-interface=ISP-BT
add action=drop chain=input in-interface=ISP-Virgin
add action=drop chain=input in-interface=ISP-BT
/ip firewall mangle
add action=mark-routing chain=output disabled=yes log=yes new-routing-mark=\
virgin passthrough=no src-address=10.10.10.0/24
add action=change-mss chain=forward dst-address=172.16.110.0/24 new-mss=1442 \
passthrough=yes protocol=tcp tcp-flags=syn
add action=change-mss chain=forward new-mss=1470 passthrough=yes protocol=tcp \
tcp-flags=syn
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT to Internet"
add action=dst-nat chain=dstnat disabled=yes dst-port=53 protocol=udp \
src-address-list=allowed to-addresses=172.16.105.2
add action=src-nat chain=srcnat disabled=yes dst-port=53 protocol=tcp \
to-addresses=172.16.105.2 to-ports=53
add action=src-nat chain=srcnat disabled=yes dst-port=53 protocol=udp \
to-addresses=172.16.105.2 to-ports=53
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=82.17.140.1
add comment="Tinos via SSTP" distance=1 dst-address=172.16.110.0/24 gateway=\
10.10.20.10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=172.16.105.0/24,172.16.110.0/24
set api disabled=yes
set winbox address=172.16.105.0/24,172.16.110.0/24
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/ip upnp
set enabled=yes show-dummy-rule=no
/ppp secret
add local-address=172.16.105.1 name=tinos-l2tp remote-address=10.10.20.10 \
service=l2tp
/queue simple
add disabled=yes max-limit=10M/10M name=queue-tinos target=*F
/system clock
set time-zone-name=Europe/London
/system identity
set name=Malford1016
/system logging
add action=sendemail topics=script
/system ntp client
set enabled=yes primary-ntp=130.159.196.118 secondary-ntp=178.79.152.182
/system package update
set channel=long-term
/system scheduler
add interval=5s name=RunFailover on-event=FailoverScript policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
start-date=jun/10/2019 start-time=14:09:11
/system script
add dont-require-permissions=no name=FailoverScript owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# -----\
-------------- header -------------------\r\
\n# Script by Tomas Kirnak, version 1.0.7\r\
\n# If you use this script, or edit and\r\
\n# re-use it, please keep the header intact.\r\
\n#\r\
\n# For more information and details about\r\
\n# this script please visit the wiki page at\r\
\n# http://wiki.mikrotik.com/wiki/Failover_Scripting\r\
\n# ------------------- header -------------------\r\
\n\r\
\n\r\
\n\r\
\n# ------------- start editing here -------------\r\
\n# Edit the variables below to suit your needs\r\
\n\r\
\n# Please fill the WAN interface names\r\
\n:local InterfaceISP1 ISP-Virgin\r\
\n:local InterfaceISP2 ISP-BT\r\
\n\r\
\n# Please fill the gateway IPs (or interface names in case of PPP)\r\
\n:global GatewayISP1 82.17.140.1\r\
\n:global GatewayISP2 ISP-BT\r\
\n\r\
\n# Please fill the ping check host - currently: resolver1.opendns.com\r\
\n:local PingTarget 82.17.140.1\r\
\n\r\
\n\r\
\n# Please fill how many ping failures are allowed before fail-over happen\
ds\r\
\n:local FailTreshold 3\r\
\n\r\
\n# Define the distance increase of a route when it fails\r\
\n:local DistanceIncrease 5\r\
\n\r\
\n# Editing the script after this point may break it\r\
\n# -------------- stop editing here --------------\r\
\n\r\
\n\r\
\n\r\
\n# Declare the global variables\r\
\n:global PingFailCountISP1\r\
\n:global PingFailCountISP2\r\
\n\r\
\n#set PingFailCountISP1 0\r\
\n#set PingFailCountISP2 0\r\
\n\r\
\n# This inicializes the PingFailCount variables, in case this is the 1st \
time the script has ran\r\
\n:if ([:typeof \$PingFailCountISP1] = \"nothing\") do={:set PingFailCount\
ISP1 0}\r\
\n:if ([:typeof \$PingFailCountISP2] = \"nothing\") do={:set PingFailCount\
ISP2 0}\r\
\n\r\
\n# This variable will be used to keep results of individual ping attempts\
\r\
\n:local PingResult\r\
\n\r\
\n\r\
\n\r\
\n# Check ISP1\r\
\n:set PingResult [ping \$PingTarget count=1]\r\
\n:put \$PingResult\r\
\n\r\
\n:if (\$PingResult = 0) do={\r\
\n\t:if (\$PingFailCountISP1 < (\$FailTreshold+2)) do={\r\
\n\t\t:set PingFailCountISP1 (\$PingFailCountISP1 + 1)\r\
\n\t\t\r\
\n\t\t:if (\$PingFailCountISP1 = \$FailTreshold) do={\r\
\n\t\t\t:log warning \"ISP1 has a problem en route to \$PingTarget - incre\
asing distance of routes.\"\r\
\n\t\t\t:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\
\\\r\
\n\t\t\t\t{/ip route set \$i distance=\$DistanceIncrease}\r\
\n\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :i\
f ([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\r\
\n\t\t\t:log warning \"Route distance increase finished.\"\r\
\n\t\t}\r\
\n\t}\r\
\n}\r\
\n:if (\$PingResult = 1) do={\r\
\n\t:if (\$PingFailCountISP1 > 0) do={\r\
\n\t\t:set PingFailCountISP1 (\$PingFailCountISP1 - 1)\r\
\n\t\t\r\
\n\t\t:if (\$PingFailCountISP1 = (\$FailTreshold -1)) do={\r\
\n\t\t\t:log warning \"ISP1 can reach \$PingTarget again - bringing back o\
riginal distance of routes.\"\r\
\n\t\t\t:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\
\\\r\
\n\t\t\t\t{/ip route set \$i distance=1}\r\
\n\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :i\
f ([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\r\
\n\t\t\t:log warning \"Route distance decrease finished.\"\r\
\n\t\t}\r\
\n\t}\r\
\n}\r\
\n"
add dont-require-permissions=no name=ResetFailover owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="#\
\_Declare the global variables\r\
\n:global PingFailCountISP1\r\
\n:global PingFailCountISP2\r\
\n:global GatewayISP1\r\
\n:global GatewayISP2\r\
\n\r\
\n# Reset Variables\r\
\nset PingFailCountISP1 0\r\
\nset PingFailCountISP2 0\r\
\n\r\
\n# Reset Routes\r\
\n:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\\\r\
\n {/ip route set \$i distance=1}\r\
\n\r\
\n# Reset Connections\r\
\n{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :if ([:l\
en \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n\r\
\n:log warning \"Route Failover Reset.\""
/tool e-mail
set address=smtp.office365.com from=andrew@finexlondon.com port=587 \
start-tls=yes user=andrew@finexlondon.com
/tool netwatch
add down-script="tool e-mail send to=andrew@finexlondon.com subject=\
\"Virgin DOWN\"" host=8.8.8.8 up-script="tool e-mail send to=andrew@finexlondon.com subject=\"Virgin UP\""

Below is the remote CCR where everything works:

# may/14/2020 13:16:03 by RouterOS 6.46.4
# software id = 2Y8R-F05B
#
# model = CCR1016-12G
# serial number = 42D402FA6367
/interface bridge
add fast-forward=no mtu=1500 name=bridge-lan protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] comment="OTE Router - NOT Modem Mode" l2mtu=\
1590 name=ether1-isp1 speed=100Mbps
set [ find default-name=ether2 ] speed=100Mbps
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] speed=100Mbps
set [ find default-name=ether7 ] speed=100Mbps
set [ find default-name=ether8 ] speed=100Mbps
set [ find default-name=ether9 ] speed=100Mbps
set [ find default-name=ether10 ] speed=100Mbps
set [ find default-name=ether11 ] speed=100Mbps
set [ find default-name=ether12 ] speed=100Mbps
/interface l2tp-client
add add-default-route=yes comment=\
"Virgin VPN Connection - change only Virgin external IP" connect-to=\
82.17.140.24 disabled=no name=l2tp-out1 user=tinos-l2tp
add add-default-route=yes comment=\
"BT VPN Connection - change only BT external IP" connect-to=\
109.145.13.198 default-route-distance=2 name=l2tp-out2 user=tinos-l2tp
/ip pool
add name=pool-tinos ranges=172.16.110.10-172.16.110.200
/ip dhcp-server
add address-pool=pool-tinos authoritative=after-2sec-delay disabled=no \
interface=bridge-lan lease-time=1d name=dhcp-tinos
/interface bridge port
add bridge=bridge-lan hw=no interface=ether2
add bridge=bridge-lan hw=no interface=ether3
add bridge=bridge-lan hw=no interface=ether4
add bridge=bridge-lan hw=no interface=ether5
add bridge=bridge-lan hw=no interface=ether6
add bridge=bridge-lan hw=no interface=ether7
add bridge=bridge-lan hw=no interface=ether8
add bridge=bridge-lan hw=no interface=ether9
add bridge=bridge-lan hw=no interface=ether10
/ip firewall connection tracking
set udp-stream-timeout=30s
/ipv6 settings
set max-neighbor-entries=1024
/ip address
add address=172.16.110.1/24 interface=bridge-lan network=172.16.110.0
add address=192.168.1.2/24 interface=ether1-isp1 network=192.168.1.0
/ip dhcp-server network
add address=172.16.110.0/24 dns-server=1.1.1.1 gateway=172.16.110.1
/ip dns
set servers=1.1.1.1
/ip firewall filter
add action=accept chain=input comment=\
"Change to Malford/Virgin/BT external IP address" src-address=\
82.17.140.24
add action=accept chain=forward
add action=accept chain=input src-address=172.16.110.0/24
add action=drop chain=input connection-state=invalid
add action=accept chain=forward dst-address=172.16.110.0/24 src-address=\
172.16.105.0/24
add action=accept chain=forward dst-address=172.16.105.0/24 src-address=\
172.16.110.0/24
/ip firewall mangle
add action=change-mss chain=forward comment=\
"Rule to change MTU size to 105.x try not to use" disabled=yes \
dst-address=172.16.105.0/24 new-mss=1442 passthrough=yes protocol=tcp \
tcp-flags=syn
add action=mark-routing chain=prerouting new-routing-mark=VOIP passthrough=\
yes src-address=172.16.110.125
/ip firewall nat
add action=accept chain=srcnat dst-address=172.16.105.0/24 src-address=\
172.16.110.0/24
add action=accept chain=srcnat dst-address=172.16.100.0/24 src-address=\
172.16.110.0/24
add action=masquerade chain=srcnat src-address=172.16.110.0/24
add action=dst-nat chain=dstnat disabled=yes dst-port=8443 protocol=tcp \
src-address=82.17.140.24 to-addresses=172.16.110.125 to-ports=443
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=192.168.1.1 routing-mark=VOIP
add comment="Main connection in case of L2TP IP Address Change" distance=3 \
gateway=192.168.1.1
/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=172.16.0.0/16
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/ipv6 nd
set [ find default=yes ] advertise-dns=no
/lcd
set default-screen=stats time-interval=hour
/lcd interface
set ether2 disabled=yes
set ether3 disabled=yes
set ether4 disabled=yes
set ether5 disabled=yes
set ether6 disabled=yes
set ether7 disabled=yes
set ether8 disabled=yes
set ether9 disabled=yes
set ether10 disabled=yes
set ether11 disabled=yes
set ether12 disabled=yes
/lcd screen
set 1 disabled=yes
set 2 disabled=yes
set 3 disabled=yes
set 4 disabled=yes
set 5 disabled=yes
/system clock
set time-zone-name=Europe/London
/system health
set fan-mode=manual
/system identity
set name=Tinos1016
/system leds
add disabled=yes leds=user-led type=on
Much obliged.

Andrew.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 5:20 pm

Hi, can you please also do this in the CLI of the two devices and post the output:
/tool traceroute duration=15 download.mikrotik.com
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Thu May 14, 2020 6:07 pm

Hi, can you please also do this in the CLI of the two devices and post the output:
/tool traceroute duration=15 download.mikrotik.com
No Update CCR:
[admin@Malford1016] > /tool traceroute duration=15 download.mikrotik.com
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 100% 2 timeout
2 62.255.109.1 0% 2 287.6ms 238.2 188.7 287.6 49.5
3 100% 2 timeout
4 100% 2 timeout
5 62.254.42.174 0% 2 23.3ms 77 23.3 130.6 53.7
6 100% 2 timeout
7 100% 1 timeout
8 213.248.84.25 0% 1 69ms 69 69 69 0
9 100% 1 timeout
10 62.115.122.160 0% 1 68.3ms 68.3 68.3 68.3 0 <MPLS:L=682,E=0>
11 62.115.115.59 0% 1 126.1ms 126.1 126.1 126.1 0
12 62.115.136.79 0% 1 189.9ms 189.9 189.9 189.9 0
13 213.248.84.33 0% 1 120.9ms 120.9 120.9 120.9 0
14 100% 1 timeout
15 100% 1 timeout
16 100% 1 timeout
17 159.148.147.204 0% 1 183.7ms 183.7 183.7 183.7 0

[admin@Malford1016] >

Working remote CCR (notice first hop is into the CCR that doesn't update!!!!)

[admin@Tinos1016] > /tool traceroute duration=15 download.mikrotik.com
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 172.16.105.1 0% 2 213.5ms 154.2 94.9 213.5 59.3
2 100% 2 timeout
3 62.255.109.1 0% 2 263.3ms 364.8 263.3 466.2 101.5
4 100% 2 timeout
5 100% 2 timeout
6 62.254.42.174 0% 1 310ms 310 310 310 0
7 100% 1 timeout
8 84.116.136.102 0% 1 254.2ms 254.2 254.2 254.2 0
9 213.248.84.25 0% 1 488.9ms 488.9 488.9 488.9 0
10 62.115.114.234 0% 1 494.5ms 494.5 494.5 494.5 0 <MPLS:L=1722,E=0>
11 80.91.249.11 0% 1 342.9ms 342.9 342.9 342.9 0
12 80.91.249.9 0% 1 337.3ms 337.3 337.3 337.3 0
13 62.115.136.77 0% 1 501.8ms 501.8 501.8 501.8 0
14 213.248.84.33 0% 1 733.1ms 733.1 733.1 733.1 0
15 100% 1 timeout
16 100% 1 timeout
17 100% 1 timeout
18 159.148.172.226 0% 1 223.7ms 223.7 223.7 223.7 0

[admin@Tinos1016] >
Cheers,

Andrew.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 7:43 pm

Andrew, you have an advanced, not to say complicated :-), network environment.
I'm not sure but do you think it could have to do with the following:
/ppp secret
add local-address=172.16.105.1 name=tinos-l2tp remote-address=10.10.20.10 \
service=l2tp
According to this thread viewtopic.php?t=131615 :
you can set any address to local address, no problem. you can set local address same as remote address"

Same with the 2nd entry at this location (btw, the distance of the 2nd should be set to a higher value, IMO):
/ip route
add distance=1 gateway=82.17.140.1
add comment="Tinos via SSTP" distance=1 dst-address=172.16.110.0/24 gateway=\
10.10.20.10

Can you in the GUI temporarily disable the 2 entries and see what happens?
I'll continue looking in the cfg.

Maybe some more people with more experience than me could take a look in to this case.

Btw, can you confirm that 82.17.140.1 is indeed your gateway? Or is this perhaps a misconfiguration? B/c the traceroute did not list that IP...
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 8:44 pm

Andrew, you seem to have multiple ISPs, ie. multiple WAN connections (ISP-Virgin, ISP-BT). Are both or just one active?
I think best would be if you could make a simple drawing of your network structure and attach it to your posting.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Thu May 14, 2020 9:18 pm

You have this one:
add action=accept chain=forward connection-state=established,related,new

I would add also the following before or after the above one:
add action=accept chain=input connection-state=established,related,new
Maybe without the ",new" at the end.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Thu May 14, 2020 9:40 pm

Andrew, you seem to have multiple ISPs, ie. multiple WAN connections (ISP-Virgin, ISP-BT). Are both or just one active?
I think best would be if you could make a simple drawing of your network structure and attach it to your posting.
Indeed I have two ISPs in failover. One L2TP connection to a remote location. There are two guest networks 10.x and 20.x which are physically isolated.

I have tried either ISP what baffles me is that the remote CCR connects first to the faulty CCR and then to Mikrotik with no issues, yet the faulty one doesn't:

Remote CCR is 172.16.110.1 Local CCR is 172.16.105.1

On the traceroute the remote CCR connect to x.105.1 then to exactly the same hops as the traceroute initiated from 105.1 itself.

How can this possible be???

I am very confused.

With regard to the last rule you spoke about I saw no change but also little or no activity.

Thanks.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Fri May 15, 2020 1:10 am

On the traceroute the remote CCR connect to x.105.1 then to exactly the same hops as the traceroute initiated from 105.1 itself.

How can this possible be???

I am very confused.
The reason of that remarkable difference is that your firewall on the problematic CCR is very unusual, to put it really softly.

You have no /ip firewall filter rules whatsoever for chain=forward of the problematic CCR, which means that it sets no limit on what the other CCR, or whatever else connected via this problematic CCR, can send and/or receive.

But the rules in chain=input of your /ip firewall filter, which handle incoming traffic to the problematic CCR itself, drop almost everything (with a few exceptions like icmp) that arrives via WANs, so no surprise that any download fails.

The way your chain=input is currently configured, you do not use the benefits of the stateful firewall concept, where packets belonging to already existing connections are handled by a single rule action=accept connection-state=established,related placed as the very first one in the chain, and the decision whether to permit or deny a given connection as a whole is taken when handling its initial packet. So even if you router itself initiates a new connection by sending a packet to some remote server, which it is free to do because there are no rules in chain=output of /ip firewall filter, the response packet from the remote server, which makes the state of that connection change from new to established, is later dropped because it matches none of the rules in chain=input of your /ip firewall filter except one of the last two ones ("drop whatever has arrived via WAN x").

Do you have any special reason not to use the stateful firewall approach? If not, just insert chain=input connection-state=established,related action=accept as the first rule in chain=input, and you'll be good.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Fri May 15, 2020 3:19 am

Andrew, as @sindy's analysis shows, you should insert these 3 rules at the right locations
in their respective chains, ie. after the specific drops, but before the final drop in each of the 3 chains, if present:

add action=accept chain=input connection-state=established,related
add action=accept chain=output connection-state=established,related,new
add action=accept chain=forward connection-state=established,related,new

If it still does not work, then try also with ".new" at end also in the input chain.

See also this very useful posting of @sindy on how to organize the firewall rules:
viewtopic.php?f=2&t=130419&start=50#p642323

And: see also your log file (via GUI) for any errors/warnings.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Fri May 15, 2020 9:25 am

you should insert these 3 rules at the right locations
in their respective chains, ie. after the specific drops, but before the final drop in each of the 3 chains, if present:

add action=accept chain=input connection-state=established,related
add action=accept chain=output connection-state=established,related,new
add action=accept chain=forward connection-state=established,related,new

If it still does not work, then try also with ".new" at end also in the input chain.
No.
accept (established or related or new) before those drop anything from WANs ones would effectively permit any connection in the respective chain, so it would invalidate the firewall functionality.

On the other hand, as long as there are currently no rules in chains forward and output, there is no need to add accept (established or related or new) to them, because the default handling of the chains is accept anyway, so adding such a rule would only slow down packet processing but would change nothing about the result.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Fri May 15, 2020 9:47 am

you should insert these 3 rules at the right locations
in their respective chains, ie. after the specific drops, but before the final drop in each of the 3 chains, if present:

add action=accept chain=input connection-state=established,related
add action=accept chain=output connection-state=established,related,new
add action=accept chain=forward connection-state=established,related,new

If it still does not work, then try also with ".new" at end also in the input chain.
No.
accept (established or related or new) before those drop anything from WANs ones would effectively permit any connection in the respective chain, so it would invalidate the firewall functionality.

Yes, I hink I understand what you mean: the connection-state=established,related,new would be wrong in following scheme, so it has to be w/o ",new":
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=accept chain=forward connection-state=established,related
... (add all those to accept)
add action=drop chain=forward comment="drop all other"
And "add action=accept chain=forward connection-state=established,related" can also safely be moved to the top of the chain.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Fri May 15, 2020 10:33 am

Do you have any special reason not to use the stateful firewall approach? If not, just insert chain=input connection-state=established,related action=accept as the first rule in chain=input, and you'll be good.
Thanks Sindy, no particular reason. I tried a couple of people to help build the config on the CCRs but both "experts" left me with big bills and big problems. Then I found a kind soul who helped me a lot but as he only did it to help I couldn't ask him for too much and he got the failover working really well, email doesn't always work but failover does really well.

Just checking the following rules block ANY traffic between 10.10.x.x and 172.16.x.x, and 20.20.x.x and 172.16.x.x. These are my rules #0 to #2
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
If so shouldn't there be a 4th rule? ie #3
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=172.16.105.0/24
If the above is correct I should add as Rule #4 and #5. confusingly the 5th and 6th rule
add action=accept chain=forward connection-state=established,related,new
add action=drop chain=forward comment="drop all other"
However starting to read the thread Mutluit pointed me to my Rules look very different to what is suggested.

Thanks,

Andrew.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Fri May 15, 2020 10:53 am

See also this very useful posting of @sindy on how to organize the firewall rules:
viewtopic.php?f=2&t=130419&start=50#p642323
I'm reading the post you suggested, and I am starting to see. So I can happily deal with those 4 rules at the highest order, the 4 that stop traffic between segregated LANs. Then normal service resumes:
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
Does this make sense?

Thanks.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Fri May 15, 2020 11:21 am

See also this very useful posting of @sindy on how to organize the firewall rules:
viewtopic.php?f=2&t=130419&start=50#p642323
I'm reading the post you suggested, and I am starting to see. So I can happily deal with those 4 rules at the highest order, the 4 that stop traffic between segregated LANs. Then normal service resumes:
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
Does this make sense?
Yes.
But see also the beforementioned general scheme for each chain.
Read also this info on the 3 built-in chains (input, output, forward) https://wiki.mikrotik.com/wiki/Manual:I ... ter#Chains

Btw, on my CRS device I'm primarily using the "Hardware Firewall" (ACL on ASIC chip) b/c of performance reasons. It does not have any connection-states as it's a stateless firewall. But it is possible to redirect a packet to the normal stateful firewall(s) (dubbed "CPU firewall") like that under "/ip firewall filter".
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Fri May 15, 2020 11:55 am

So I can happily deal with those 4 rules at the highest order, the 4 that stop traffic between segregated LANs.
No. The accept established or related rule should be the very first one in the chain (except very specific cases), because it won't allow any packet not belonging to a connection (flow) whose first ever packet was not accepted by one of the subsequent rules (which it has reached because the accept established or related didn't match it). So all mid-connection packets will be handled by that single rule, and only the initial packet of each connection will be handled by one of the subsequent rules. If the first one is dropped, the subsequent ones will never come (some UDP flows may continue coming anyway but will be dropped too, by the same rule which has dropped the initial one).

It is critical for the overall routing performance to force most packets through as few firewall rules as possible.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Fri May 15, 2020 1:13 pm

No. The accept established or related rule should be the very first one in the chain (except very specific cases),
Understood, and I have created and moved that rule to position #0 and low and behold, Updates and SNTP work!!
It is critical for the overall routing performance to force most packets through as few firewall rules as possible.
Is it normal to have this many firewall rules?
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=\
172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=\
172.16.105.0/24
add action=accept chain=input src-address-list=allowed
add action=accept chain=input protocol=icmp
add action=accept chain=forward connection-state=established,related,new
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input disabled=yes protocol=ipsec-ah
add action=accept chain=input disabled=yes protocol=ipsec-esp
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=udp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=udp
add action=drop chain=input connection-state=invalid in-interface=ISP-Virgin
add action=drop chain=input connection-state=invalid in-interface=ISP-BT
add action=drop chain=input in-interface=ISP-Virgin
add action=drop chain=input in-interface=ISP-BT
Thanks.
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Unable to update CCR

Fri May 15, 2020 2:03 pm

Then the reason was the following:
Your previous firewall rules in the input chain did allow input traffic from those addresses in the "allowed" address list
OR icmp traffic OR traffic to some select ports (1701, 500, 4500), else it dropped all other incoming packets.
Ie. this is about traffic to the device itself only (ie. the input chain), not traffic through the device (ie. the forward chain).

Hmm. IMO there's still a mystery in this setup. Maybe @sindy can tell more.

But, glad to see it now works.

Btw, you should group your firewall rules by the chain.

You can delete the following rules as they are redundant:
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-Virgin protocol=udp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ISP-BT protocol=udp
add action=drop chain=input connection-state=invalid in-interface=ISP-Virgin
add action=drop chain=input connection-state=invalid in-interface=ISP-BT

And check whether you need these two currently disabled rules:
add action=accept chain=input disabled=yes protocol=ipsec-ah
add action=accept chain=input disabled=yes protocol=ipsec-esp
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Fri May 15, 2020 2:26 pm

Is it normal to have this many firewall rules?
It is normal to have as many rules as you really need. In absolute figures it may mean five or five thousand depending on the role of your router in the network.

As it looked yesterday, the router could be managed from any device in one of its LAN subnets, and itself it was basically unable to do anything but ping via any of the WANs. It wasn't possible to manage it from WAN (definitely good). It didn't limit any transit connections ( (V)LAN <-> (V)LAN or (V)LAN <-> WAN) because chain forward in firewall table filter was totally empty.

To get a tailored advice, you have to provide sufficient information about the network topology (a photo of a handmade drawing is sufficient) and specify the required firewall rules in plain English - at best by specifying what needs to be allowed, so that the rest could be dropped.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Fri May 15, 2020 3:38 pm

To get a tailored advice, you have to provide sufficient information about the network topology (a photo of a handmade drawing is sufficient) and specify the required firewall rules in plain English - at best by specifying what needs to be allowed, so that the rest could be dropped.
I do not have any specifics other than security, we do not host any services nor broadcast. Only different devices are our SIP Phones. The connection to the remote CCR has been a problem, tried a number of protocols and then chose L2TP, although throughput is very low compared to its theoretical limit. (Upload of Sender - Download of Receiver)

Does this picture help:
Network.png
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Fri May 15, 2020 3:57 pm

So if I get you right, the sole purpose of the two CCRs is to interconnect the two sites using a VPN, and no firewall functionality between internet and the LANs is required (if really not but devices in the LANs should have internet access, how else is protection of these networks provided, do you rely on NAT alone)?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Fri May 15, 2020 4:12 pm

So if I get you right, the sole purpose of the two CCRs is to interconnect the two sites using a VPN, and no firewall functionality between internet and the LANs is required (if really not but devices in the LANs should have internet access, how else is protection of these networks provided, do you rely on NAT alone)?
Definitely Internet access, remote CCR accesses Internet via the local CCR, if L2TP fails it accesses Internet directly

Local CCR accesses Internet directly.

Both would need full Internet firewalls.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Mon May 18, 2020 10:11 pm

So if I get you right, the sole purpose of the two CCRs is to interconnect the two sites using a VPN, and no firewall functionality between internet and the LANs is required (if really not but devices in the LANs should have internet access, how else is protection of these networks provided, do you rely on NAT alone)?
Sindy? Are you able to help me please.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Mon May 18, 2020 10:35 pm

Likely yes, but it won't be within hours.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Mon May 18, 2020 10:41 pm

Likely yes, but it won't be within hours.
Brilliant, I can wait. One thing the addition of the first rule:
add action=accept chain=input connection-state=established,related
Doesn't expose the network?

Thanks.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Mon May 18, 2020 10:45 pm

You can delete the following rules as they are redundant:
And check whether you need these two currently disabled rules:
add action=accept chain=input disabled=yes protocol=ipsec-ah
add action=accept chain=input disabled=yes protocol=ipsec-esp
I'm not left with much!!! How can I check that nothing untoword can get through?

Thanks,

Andrew.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Mon May 18, 2020 10:58 pm

How can I check that nothing untoword can get through?
You can't check. You can only set up firewall rules which will prevent that, but bear in mind that L3 firewall rules only prevent a certain kind of malware from actively connecting to your network; other kind of malware, which relies on downloads from infected web servers as people click on phishing e-mails or people opening e-mail attachments, cannot be stopped by a firewall which doesn't analyze the payload. And analysing payload requires deciphering HTTPS communication using MITM techniques. Most anti-virus software does that, which brings other kind of security concerns (passwords are often transported in plaintext if HTTPS is used, assuming that the whole channel is encrypted by TLS, whereas this security software can see the TLS payload in plaintext). Also cross-platform malware exists, which gets downloaded to your PCs but attacks your router (or SIP phones) from LAN side. So you shouldn't enable plaintext management services, such as telnet or http, even for access from LAN. And even if you don't, there are keyloggers which record the passwords you fill in to secure clients...

Post the export of the current configurations of both routers following the hint in my automatic signature below so that I could give you some lines of configuration scripts to add or modify the firewall rules.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Tue May 19, 2020 12:03 am

So you shouldn't enable plaintext management services, such as telnet or http, even for access from LAN.
Does PuTTY use the same principals as Telnet? I use that quite often to manage a few headless Raspberry Pi. Can HTTP simply not be silenced at the network level? My greatest fear is quite honestly loosing family pictures, almost everything else is backed up to a cloud service.

Local CCR
# may/18/2020 21:54:29 by RouterOS 6.46.6
# software id = PZJX-KJ04
#
# model = CCR1016-12G
# serial number = 42D402B557C9
/interface bridge
add fast-forward=no name=bridge-lan
add name=bridgeDRGuest
add name=bridgeGuest
/interface ethernet
set [ find default-name=ether2 ] name=BT
set [ find default-name=ether1 ] comment=\
"Virgin Modem Mode connection to DHCP Client" name=ISP-Virgin
/interface pppoe-client
add add-default-route=yes comment="BT PPPoE Client Modem Mode" \
default-route-distance=3 disabled=no interface=BT name=ISP-BT user=\
bthomehub@btbroadband.com
/ip pool
add name=pool-malford ranges=172.16.105.90-172.16.105.129
add name=pGuest ranges=10.10.10.10-10.10.10.100
add name=pDRGuest ranges=20.20.20.20-20.20.20.100
/ip dhcp-server
add address-pool=pool-malford interface=bridge-lan lease-time=1d name=\
dhcp-lan
add address-pool=pGuest disabled=no interface=bridgeGuest name=DHCPGuest
add address-pool=pDRGuest disabled=no interface=bridgeDRGuest name=\
DHCPDRGUEST
/system logging action
set 1 disk-file-name=flash/log
add email-to=andrew.gebhardt@finexlondon.com name=sendemail target=email
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
sword,web,sniff,sensitive,api,romon,dude,tikapp"
/interface bridge port
add bridge=bridge-lan interface=ether3
add bridge=bridge-lan interface=ether4
add bridge=bridge-lan interface=ether5
add bridge=bridge-lan interface=ether6
add bridge=bridge-lan interface=ether7
add bridge=bridge-lan interface=ether8
add bridge=bridge-lan interface=ether9
add bridge=bridge-lan interface=ether10
add bridge=bridgeDRGuest interface=ether11
add bridge=bridgeGuest interface=ether12
/ip settings
set tcp-syncookies=yes
/interface l2tp-server server
set enabled=yes
/interface pptp-server server
set enabled=yes
/interface sstp-server server
set certificate=Server default-profile=default-encryption port=8443 \
tls-version=only-1.2
/ip address
add address=172.16.105.1/24 interface=bridge-lan network=172.16.105.0
add address=192.168.1.2/24 interface=BT network=192.168.1.0
add address=192.168.2.2/24 disabled=yes interface=BT network=192.168.2.0
add address=10.10.10.254/24 interface=bridgeGuest network=10.10.10.0
add address=20.20.20.254/24 interface=bridgeDRGuest network=20.20.20.0
/ip cloud
set ddns-update-interval=2m
/ip dhcp-client
add add-default-route=no comment=\
"DHCP Client for Virgin Router in Modem Mode" disabled=no interface=\
ISP-Virgin use-peer-dns=no
/ip dhcp-server network
add address=10.10.10.0/24 dns-server=1.1.1.1,1.0.0.1 gateway=10.10.10.254 \
netmask=24
add address=20.20.20.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=20.20.20.254 \
netmask=24
add address=172.16.105.0/24
/ip dns
set servers=172.16.105.2
/ip firewall address-list
add address=172.16.105.0/24 list=allowed
add address=172.16.110.0/24 list=allowed
add address=2.87.174.170 disabled=yes list=allowed
add address=2.87.174.170 list=TinosIP
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=\
20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=\
172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=\
172.16.105.0/24
add action=accept chain=input src-address-list=allowed
add action=accept chain=input protocol=icmp
add action=accept chain=forward connection-state=established,related,new
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input disabled=yes protocol=ipsec-ah
add action=accept chain=input disabled=yes protocol=ipsec-esp
add action=drop chain=input disabled=yes dst-port=53 in-interface=ISP-Virgin \
protocol=tcp
add action=drop chain=input disabled=yes dst-port=53 in-interface=ISP-Virgin \
protocol=udp
add action=drop chain=input disabled=yes dst-port=53 in-interface=ISP-BT \
protocol=tcp
add action=drop chain=input disabled=yes dst-port=53 in-interface=ISP-BT \
protocol=udp
add action=drop chain=input connection-state=invalid disabled=yes \
in-interface=ISP-Virgin
add action=drop chain=input connection-state=invalid disabled=yes \
in-interface=ISP-BT
add action=drop chain=input disabled=yes in-interface=ISP-Virgin
add action=drop chain=input disabled=yes in-interface=ISP-BT
/ip firewall mangle
add action=mark-routing chain=output disabled=yes log=yes new-routing-mark=\
virgin passthrough=no src-address=10.10.10.0/24
add action=change-mss chain=forward dst-address=172.16.110.0/24 new-mss=1442 \
passthrough=yes protocol=tcp tcp-flags=syn
add action=change-mss chain=forward new-mss=1470 passthrough=yes protocol=tcp \
tcp-flags=syn
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT to Internet"
add action=dst-nat chain=dstnat disabled=yes dst-port=53 protocol=udp \
src-address-list=allowed to-addresses=172.16.105.2
add action=src-nat chain=srcnat disabled=yes dst-port=53 protocol=tcp \
to-addresses=172.16.105.2 to-ports=53
add action=src-nat chain=srcnat disabled=yes dst-port=53 protocol=udp \
to-addresses=172.16.105.2 to-ports=53
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=TINOSGATEWAY
add comment="Tinos via SSTP" distance=1 dst-address=172.16.110.0/24 gateway=\
10.10.20.10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=172.16.105.0/24,172.16.110.0/24
set api disabled=yes
set winbox address=172.16.105.0/24,172.16.110.0/24
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/ip upnp
set enabled=yes show-dummy-rule=no
/ipv6 nd
set [ find default=yes ] advertise-dns=no
/ppp secret
add local-address=172.16.105.1 name=tinos-l2tp remote-address=10.10.20.10 \
service=l2tp
/queue simple
add disabled=yes max-limit=10M/10M name=queue-tinos target=*F
/system clock
set time-zone-name=Europe/London
/system identity
set name=Malford1016
/system logging
add action=sendemail topics=script
/system ntp client
set enabled=yes primary-ntp=130.159.196.118 secondary-ntp=178.79.152.182
/system scheduler
add interval=5s name=RunFailover on-event=FailoverScript policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
start-date=jun/10/2019 start-time=14:09:11
/system script
add dont-require-permissions=no name=FailoverScript owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# -----\
-------------- header -------------------\r\
\n# Script by Tomas Kirnak, version 1.0.7\r\
\n# If you use this script, or edit and\r\
\n# re-use it, please keep the header intact.\r\
\n#\r\
\n# For more information and details about\r\
\n# this script please visit the wiki page at\r\
\n# http://wiki.mikrotik.com/wiki/Failover_Scripting\r\
\n# ------------------- header -------------------\r\
\n\r\
\n\r\
\n\r\
\n# ------------- start editing here -------------\r\
\n# Edit the variables below to suit your needs\r\
\n\r\
\n# Please fill the WAN interface names\r\
\n:local InterfaceISP1 ISP-Virgin\r\
\n:local InterfaceISP2 ISP-BT\r\
\n\r\
\n# Please fill the gateway IPs (or interface names in case of PPP)\r\
\n:global GatewayISP1 82.17.140.1\r\
\n:global GatewayISP2 ISP-BT\r\
\n\r\
\n# Please fill the ping check host - currently: resolver1.opendns.com\r\
\n:local PingTarget 82.17.140.1\r\
\n\r\
\n\r\
\n# Please fill how many ping failures are allowed before fail-over happen\
ds\r\
\n:local FailTreshold 3\r\
\n\r\
\n# Define the distance increase of a route when it fails\r\
\n:local DistanceIncrease 5\r\
\n\r\
\n# Editing the script after this point may break it\r\
\n# -------------- stop editing here --------------\r\
\n\r\
\n\r\
\n\r\
\n# Declare the global variables\r\
\n:global PingFailCountISP1\r\
\n:global PingFailCountISP2\r\
\n\r\
\n#set PingFailCountISP1 0\r\
\n#set PingFailCountISP2 0\r\
\n\r\
\n# This inicializes the PingFailCount variables, in case this is the 1st \
time the script has ran\r\
\n:if ([:typeof \$PingFailCountISP1] = \"nothing\") do={:set PingFailCount\
ISP1 0}\r\
\n:if ([:typeof \$PingFailCountISP2] = \"nothing\") do={:set PingFailCount\
ISP2 0}\r\
\n\r\
\n# This variable will be used to keep results of individual ping attempts\
\r\
\n:local PingResult\r\
\n\r\
\n\r\
\n\r\
\n# Check ISP1\r\
\n:set PingResult [ping \$PingTarget count=1]\r\
\n:put \$PingResult\r\
\n\r\
\n:if (\$PingResult = 0) do={\r\
\n\t:if (\$PingFailCountISP1 < (\$FailTreshold+2)) do={\r\
\n\t\t:set PingFailCountISP1 (\$PingFailCountISP1 + 1)\r\
\n\t\t\r\
\n\t\t:if (\$PingFailCountISP1 = \$FailTreshold) do={\r\
\n\t\t\t:log warning \"ISP1 has a problem en route to \$PingTarget - incre\
asing distance of routes.\"\r\
\n\t\t\t:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\
\\\r\
\n\t\t\t\t{/ip route set \$i distance=\$DistanceIncrease}\r\
\n\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :i\
f ([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\r\
\n\t\t\t:log warning \"Route distance increase finished.\"\r\
\n\t\t}\r\
\n\t}\r\
\n}\r\
\n:if (\$PingResult = 1) do={\r\
\n\t:if (\$PingFailCountISP1 > 0) do={\r\
\n\t\t:set PingFailCountISP1 (\$PingFailCountISP1 - 1)\r\
\n\t\t\r\
\n\t\t:if (\$PingFailCountISP1 = (\$FailTreshold -1)) do={\r\
\n\t\t\t:log warning \"ISP1 can reach \$PingTarget again - bringing back o\
riginal distance of routes.\"\r\
\n\t\t\t:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\
\\\r\
\n\t\t\t\t{/ip route set \$i distance=1}\r\
\n\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if\
\_([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\t\t\t{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :i\
f ([:len \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}\
}\r\
\n\r\
\n\t\t\t:log warning \"Route distance decrease finished.\"\r\
\n\t\t}\r\
\n\t}\r\
\n}\r\
\n"
add dont-require-permissions=no name=ResetFailover owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="#\
\_Declare the global variables\r\
\n:global PingFailCountISP1\r\
\n:global PingFailCountISP2\r\
\n:global GatewayISP1\r\
\n:global GatewayISP2\r\
\n\r\
\n# Reset Variables\r\
\nset PingFailCountISP1 0\r\
\nset PingFailCountISP2 0\r\
\n\r\
\n# Reset Routes\r\
\n:foreach i in=[/ip route find gateway=\$GatewayISP1 && static] do=\\\r\
\n {/ip route set \$i distance=1}\r\
\n\r\
\n# Reset Connections\r\
\n{ :local cons [/ip firewall connection find protocol=\"udp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"tcp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"rtp\"]; :if ([:le\
n \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n{ :local cons [/ip firewall connection find protocol=\"icmp\"]; :if ([:l\
en \$cons] > 0) do={ /ip firewall connection remove numbers=\$cons;}}\r\
\n\r\
\n:log warning \"Route Failover Reset.\""
/tool e-mail
set address=smtp.office365.com from=andrew.gebhardt@finexlondon.com port=587 \
start-tls=yes user=andrew.gebhardt@finexlondon.com
/tool netwatch
add down-script="tool e-mail send to=andrew.gebhardt@finexlondon.com subject=\
\"Virgin DOWN\"" host=8.8.8.8 up-script="tool e-mail send to=andrew.gebhar\
dt@finexlondon.com subject=\"Virgin UP\""
Remote CCR
# may/18/2020 21:54:29 by RouterOS 6.46.4
# software id = 2Y8R-F05B
#
# model = CCR1016-12G
# serial number = 42D402FA6367
/interface bridge
add fast-forward=no mtu=1500 name=bridge-lan protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] comment="OTE Router - NOT Modem Mode" l2mtu=\
1590 name=ether1-isp1 speed=100Mbps
set [ find default-name=ether2 ] speed=100Mbps
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] speed=100Mbps
set [ find default-name=ether7 ] speed=100Mbps
set [ find default-name=ether8 ] speed=100Mbps
set [ find default-name=ether9 ] speed=100Mbps
set [ find default-name=ether10 ] speed=100Mbps
set [ find default-name=ether11 ] speed=100Mbps
set [ find default-name=ether12 ] speed=100Mbps
/interface l2tp-client
add add-default-route=yes comment=\
"Virgin VPN Connection - change only Virgin external IP" connect-to=\
GATEWAY84 disabled=no name=l2tp-out1 user=tinos-l2tp
add add-default-route=yes comment=\
"BT VPN Connection - change only BT external IP" connect-to=\
GATEWAY198 default-route-distance=2 name=l2tp-out2 user=tinos-l2tp
/ip pool
add name=pool-tinos ranges=172.16.110.10-172.16.110.200
/ip dhcp-server
add address-pool=pool-tinos authoritative=after-2sec-delay disabled=no \
interface=bridge-lan lease-time=1d name=dhcp-tinos
/interface bridge port
add bridge=bridge-lan hw=no interface=ether2
add bridge=bridge-lan hw=no interface=ether3
add bridge=bridge-lan hw=no interface=ether4
add bridge=bridge-lan hw=no interface=ether5
add bridge=bridge-lan hw=no interface=ether6
add bridge=bridge-lan hw=no interface=ether7
add bridge=bridge-lan hw=no interface=ether8
add bridge=bridge-lan hw=no interface=ether9
add bridge=bridge-lan hw=no interface=ether10
/ip firewall connection tracking
set udp-stream-timeout=30s
/ipv6 settings
set max-neighbor-entries=1024
/ip address
add address=172.16.110.1/24 interface=bridge-lan network=172.16.110.0
add address=192.168.1.2/24 interface=ether1-isp1 network=192.168.1.0
/ip dhcp-server network
add address=172.16.110.0/24 dns-server=1.1.1.1 gateway=172.16.110.1
/ip dns
set servers=1.1.1.1
/ip firewall filter
add action=accept chain=input comment=\
"Change to Malford/Virgin/BT external IP address" src-address=\
GATEWAY84
add action=accept chain=forward
add action=accept chain=input src-address=172.16.110.0/24
add action=drop chain=input connection-state=invalid
add action=accept chain=forward dst-address=172.16.110.0/24 src-address=\
172.16.105.0/24
add action=accept chain=forward dst-address=172.16.105.0/24 src-address=\
172.16.110.0/24
/ip firewall mangle
add action=change-mss chain=forward comment=\
"Rule to change MTU size to 105.x try not to use" disabled=yes \
dst-address=172.16.105.0/24 new-mss=1442 passthrough=yes protocol=tcp \
tcp-flags=syn
add action=mark-routing chain=prerouting new-routing-mark=VOIP passthrough=\
yes src-address=172.16.110.125
/ip firewall nat
add action=accept chain=srcnat dst-address=172.16.105.0/24 src-address=\
172.16.110.0/24
add action=accept chain=srcnat dst-address=172.16.100.0/24 src-address=\
172.16.110.0/24
add action=masquerade chain=srcnat src-address=172.16.110.0/24
add action=dst-nat chain=dstnat disabled=yes dst-port=8443 protocol=tcp \
src-address=GATEWAY84 to-addresses=172.16.110.125 to-ports=443
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=192.168.1.1 routing-mark=VOIP
add comment="Main connection in case of L2TP IP Address Change" distance=3 \
gateway=192.168.1.1
/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=172.16.0.0/16
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/ipv6 nd
set [ find default=yes ] advertise-dns=no
/lcd
set default-screen=stats time-interval=hour
/lcd interface
set ether2 disabled=yes
set ether3 disabled=yes
set ether4 disabled=yes
set ether5 disabled=yes
set ether6 disabled=yes
set ether7 disabled=yes
set ether8 disabled=yes
set ether9 disabled=yes
set ether10 disabled=yes
set ether11 disabled=yes
set ether12 disabled=yes
/lcd screen
set 1 disabled=yes
set 2 disabled=yes
set 3 disabled=yes
set 4 disabled=yes
set 5 disabled=yes
/system clock
set time-zone-name=Europe/London
/system health
set fan-mode=manual
/system identity
set name=Tinos1016
/system leds
add disabled=yes leds=user-led type=on
Thanks.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Tue May 19, 2020 7:29 pm

OK, so for the "local CCR" (Malford), the script below should make the firewall rules simple and efficient:
  • devices in all LAN subnets will be able to set up connections to any servers in the internet (including the Tinos subnet accessing internet via Malford via the VPN link),
  • devices in the primary LAN subnet of Malford will be able to set up connections to devices in the primary subnet of Tinos, and vice versa, over the VPN link
Any other communication passing through the router will be forbidden.
  • devices in all LAN subnets will be free to use the Malford CCR as a DNS server (if themselves configured to use it)
  • from devices in the primary LAN subnets of both Malford and Tinos, it will be possible to manage the Malford router using SSH, HTTPS (currently not configured) or Winbox
All other incoming connections to the router itself will be forbidden.

The router itself will stay free to initiate connections towards anywhere.

If the above is what you want, copy-paste the script below. If it is not, suggest modifications.

The next step will be to do a similar thing at the Tinos device. And then I'd suggest to either switch from L2TP to bare IPsec, or at least to add IPSec encryption of the L2TP, because currently anyone who can sniff the internet traffic betwen the sites can read the data flowing between Malford and Tinos LAN subnets in plaintext.

/system backup save name=before-change

/ip firewall address-list
add list=primary-subnets address=172.16.105.0/24
add list=primary-subnets address=172.16.110.0/24

/interface list
add name=WAN

/interface list member
add list=WAN interface=ISP-Virgin
add list=WAN interface=ISP-BT

/ip firewall filter
set [find] comment=the-old-rules

add action=accept chain=input connection-state=established,related,untracked
add action=drop connection-state=invalid
add action=accept protocol=udp dst-port=53 in-interface-list=!WAN
add action=accept protocol=icmp
add action=accept protocol=udp dst-port=500,1701,4500 in-interface-list=WAN
add action=accept protocol=tcp dst-port=22,443,8291 src-address-list=allowed
add action=drop

add action=accept chain=forward connection-state=established,related,untracked
add action=drop connection-state=invalid
add action=accept in-interface-list=!WAN out-interface-list=WAN
add action=accept src-address-list=primary-subnets dst-address-list=primary-subnets
add action=drop

/ip firewall filter remove [find comment~"the-old-rules"]
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Tue May 19, 2020 10:08 pm

OK, so for the "local CCR" (Malford), the script below should make the firewall rules simple and efficient:
To run the script I just create a new Script with all policies checked, permissions uncheked, and then just save and run script.
it will be possible to manage the Malford router using SSH, HTTPS (currently not configured) or Winbox
I'd rather only access internally via Winbox, last night I already a number of login attempts.
The next step will be to do a similar thing at the Tinos device. And then I'd suggest to either switch from L2TP to bare IPsec, or at least to add IPSec encryption of the L2TP
That would make sense.

Thanks,

Andrew.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 12:12 am

To run the script I just create a new Script with all policies checked, permissions uncheked, and then just save and run script.
No. Log in using SSH (PuTTY) or connect using Winbox and open a terminal in it. Then, press Ctrl-X to get to Safe Mode in the text window, and then copy-paste the script there. Then keep the session running and connect using the same application again, to confirm that the rules allowed you in. If yes, go to the original window and press Ctrl-X again to leave the Safe Mode and thus make the changes permanent.

You can also do it the way you've suggested, but before running the script, you have to activate the Safe Mode by the corresponding button in the left hand menu of Winbox, and then do the same test before leaving Safe Mode.

I'd rather only access internally via Winbox, last night I already a number of login attempts.
Login attempts from LAN? In your export the firewall was broken again, as the "drop the rest" rules for input traffic coming in via WANs were disabled. And having only Winbox open doesn't save you from attacks from outside.

When you say "access internally via Winbox", do you want to connect to an IP address or to a MAC address? I'm not sure from where mac-winbox is permitted by default, so you'd have to set up an interface list first.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 10:18 am

Then keep the session running and connect using the same application again, to confirm that the rules allowed you in.
All good thanks, now I have a rules list that looks like this:
add action=accept chain=input comment=the-old-rules connection-state=established,related disabled=yes
add action=drop chain=forward comment=the-old-rules dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward comment=the-old-rules dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward comment=the-old-rules dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=drop chain=forward comment=the-old-rules dst-address=20.20.20.0/24 src-address=172.16.105.0/24
add action=accept chain=input comment=the-old-rules src-address-list=allowed
add action=accept chain=input comment=the-old-rules protocol=icmp
add action=accept chain=forward comment=the-old-rules connection-state=established,related,new
add action=accept chain=input comment=the-old-rules dst-port=1701 protocol=udp
add action=accept chain=input comment=the-old-rules dst-port=500 protocol=udp
add action=accept chain=input comment=the-old-rules dst-port=4500 protocol=udp
add action=accept chain=input comment=the-old-rules disabled=yes protocol=ipsec-ah
add action=accept chain=input comment=the-old-rules disabled=yes protocol=ipsec-esp
add action=drop chain=input comment=the-old-rules dst-port=53 in-interface=ISP-Virgin protocol=tcp
add action=drop chain=input comment=the-old-rules dst-port=53 in-interface=ISP-Virgin protocol=udp
add action=drop chain=input comment=the-old-rules dst-port=53 in-interface=ISP-BT protocol=tcp
add action=drop chain=input comment=the-old-rules dst-port=53 in-interface=ISP-BT protocol=udp
add action=drop chain=input comment=the-old-rules connection-state=invalid in-interface=ISP-Virgin
add action=drop chain=input comment=the-old-rules connection-state=invalid in-interface=ISP-BT
add action=drop chain=input comment=the-old-rules in-interface=ISP-Virgin
add action=drop chain=input comment=the-old-rules in-interface=ISP-BT
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain="add action=accept protocol=udp dst-port=53 in-interface-list=!WAN" connection-state=invalid
add action=accept chain="add action=accept protocol=udp dst-port=500,1701,4500 in-interface-list=WAN" protocol=\
icmp
add action=accept chain="add action=drop" dst-port=22,443,8291 protocol=tcp src-address-list=allowed
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain="add action=accept in-interface-list=!WAN out-interface-list=WAN" connection-state=invalid
add action=accept chain="add action=drop" dst-address-list=primary-subnets src-address-list=primary-subnets
Don't the new rules make most of the old rules redundant? At the very least I would need to shift them higher up in the rankings? The rules you kindly wrote are now numbers 20 to 27.

Login attempts from LAN? In your export the firewall was broken again, as the "drop the rest" rules for input traffic coming in via WANs were disabled.
From the WAN, I lost the logs as had to restore all settings and reboot if not I would have posted. With regard to the rule I had disabled I needed to do that because it was interfering with the SIP phones.

And having only Winbox open doesn't save you from attacks from outside.
I'm happy with services on being available from the LAN (in IP Service List). Thank you!
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 11:44 am

Don't the new rules make most of the old rules redundant? At the very least I would need to shift them higher up in the rankings? The rules you kindly wrote are now numbers 20 to 27.
The last line of my script,
/ip firewall filter remove [find comment~"the-old-rules"]
should have removed those old rules - that's why it has marked the existing ones with a specific comment before adding the new ones. Have you executed that last line? It is a common issue that when copy-pasting, one doesn't copy-paste the "enter" on the last line.

If this was the case, you can now just execute that line, but again, please do that while in Safe Mode, then test that you can still establish a new connection, and only if you can, exit the Safe Mode in the original connection.

With regard to the rule I had disabled I needed to do that because it was interfering with the SIP phones.
I can't see how a rule in chain=input dealing with connections to the router itself (whose disabling has caused failed ssh attempts to appear in the log) could interfere with operation of SIP phones which are handled by chain=forward.

Regardless that, are the SIP phones registering to a server in the internet or you have some own PBX at one of the sites?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 1:20 pm

If this was the case, you can now just execute that line, but again, please do that while in Safe Mode, then test that you can still establish a new connection, and only if you can, exit the Safe Mode in the original connection.
Did them manually in the end as I needed the isolation rules so, these are the active ones:
/ip firewall filter
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain="add action=accept protocol=udp dst-port=53 in-interface-list=!WAN" connection-state=invalid
add action=accept chain="add action=accept protocol=udp dst-port=500,1701,4500 in-interface-list=WAN" protocol=icmp
add action=accept chain="add action=drop" dst-port=22,443,8291 protocol=tcp src-address-list=allowed
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain="add action=accept in-interface-list=!WAN out-interface-list=WAN" connection-state=invalid
add action=accept chain="add action=drop" dst-address-list=primary-subnets src-address-list=primary-subnets
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=172.16.105.0/24
and these are all the disabled ones:
add action=accept chain=input comment=the-old-rules disabled=yes src-address-list=allowed
add action=accept chain=input comment=the-old-rules disabled=yes protocol=icmp
add action=accept chain=forward comment=the-old-rules connection-state=established,related,new disabled=yes
add action=accept chain=input comment=the-old-rules disabled=yes dst-port=1701 protocol=udp
add action=accept chain=input comment=the-old-rules disabled=yes dst-port=500 protocol=udp
add action=accept chain=input comment=the-old-rules disabled=yes dst-port=4500 protocol=udp
add action=accept chain=input comment=the-old-rules disabled=yes protocol=ipsec-ah
add action=accept chain=input comment=the-old-rules disabled=yes protocol=ipsec-esp
add action=drop chain=input comment=the-old-rules disabled=yes dst-port=53 in-interface=ISP-Virgin protocol=tcp
add action=drop chain=input comment=the-old-rules disabled=yes dst-port=53 in-interface=ISP-Virgin protocol=udp
add action=drop chain=input comment=the-old-rules disabled=yes dst-port=53 in-interface=ISP-BT protocol=tcp
add action=drop chain=input comment=the-old-rules disabled=yes dst-port=53 in-interface=ISP-BT protocol=udp
add action=drop chain=input comment=the-old-rules connection-state=invalid disabled=yes in-interface=ISP-Virgin
add action=drop chain=input comment=the-old-rules connection-state=invalid disabled=yes in-interface=ISP-BT
add action=drop chain=input comment=the-old-rules disabled=yes in-interface=ISP-Virgin
add action=drop chain=input comment=the-old-rules disabled=yes in-interface=ISP-BT
[/quote]

Regardless that, are the SIP phones registering to a server in the internet or you have some own PBX at one of the sites?
I have absolutely no idea why, but it did the job. Currently SIP is working fine with the above configuration.

Are the following ports ok to be visible from the outside:
ports.JPG
You do not have the required permissions to view the files attached to this post.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 2:34 pm

Login attempts from LAN?
Today's attempts:
11:26:59 warning denied winbox/dude connect from 113.190.197.22
11:26:59 warning denied winbox/dude connect from 113.190.197.22
11:27:00 warning denied winbox/dude connect from 113.190.197.22
11:49:34 warning denied winbox/dude connect from 41.90.249.200
11:56:55 warning denied winbox/dude connect from 90.143.205.249
11:56:56 warning denied winbox/dude connect from 90.143.205.249
11:56:56 warning denied winbox/dude connect from 90.143.205.249
12:11:44 warning denied winbox/dude connect from 82.200.40.29
12:11:44 warning denied winbox/dude connect from 82.200.40.29
12:11:44 warning denied winbox/dude connect from 82.200.40.29
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 3:38 pm

Did them manually in the end as I needed the isolation rules so, these are the active ones:
No, you didn't need any extra isolation rules. I gave you firewall rules which drop everything except what I've explicitly stated will be permitted.

You have actually not implemented my rules - according to what you've posted, what you ended up with is a nonsense, sometimes a fraction of my original rule ended as a chain name which is a complete nonsense and cannot work.

So until you manage to run the script as I gave it, there is nothing more to talk about. I'm not going to debug the configuration remotely if you cannot do properly what I ask you to do.

Every proper run of my script will replace any previously existing firewall rules with the new ones, so you can simply run it again, preferably after changing the name of tha backup file.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 5:23 pm

No, you didn't need any extra isolation rules. I gave you firewall rules which drop everything except what I've explicitly stated will be permitted.
If I switch off these 4 rules:
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=172.16.105.0/24
Then machines in the segregated "guest" networks, 10.10.10.x and 20.20.20.x can ping the home networks 172.16.105.x and 172.16.110.x.

I have checked as I have a Ubuntu box in network 20.20.20.x that can ping past the gateway 172.16.105.1 to devices across the network.
You have actually not implemented my rules
The rules as you have applied then in the script are all there, just those extra 4 at the end. As you suggested I have reapplied the Script, and uncommented my 4 Rules and the result is this:
/ip firewall filter
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain="add action=accept protocol=udp dst-port=53 in-interface-list=!WAN" connection-state=invalid
add action=accept chain="add action=accept protocol=udp dst-port=500,1701,4500 in-interface-list=WAN" protocol=icmp
add action=accept chain="add action=drop" dst-port=22,443,8291 protocol=tcp src-address-list=allowed
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain="add action=accept in-interface-list=!WAN out-interface-list=WAN" connection-state=invalid
add action=accept chain="add action=drop" dst-address-list=primary-subnets src-address-list=primary-subnets
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.105.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.105.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=172.16.105.0/24
In fact it is clear that I have not isolated properly the 110 Tinos network so would need to add:
add action=drop chain=forward dst-address=172.16.110.0/24 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=172.16.110.0/24 src-address=20.20.20.0/24
add action=drop chain=forward dst-address=10.10.10.0/24 src-address=172.16.110.0/24
add action=drop chain=forward dst-address=20.20.20.0/24 src-address=172.16.110.0/24
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 5:37 pm

Can you copy-paste my script here exactly the same way how you have copy-pasted it to the Mikrotik? Because the resulting rules are not those in my script, something went totally wrong:

add action=drop chain="add action=accept protocol=udp dst-port=53 in-interface-list=!WAN" connection-state=invalid

whereas in my script, the above was two rules:
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=udp dst-port=53 in-interface-list=!WAN


This corruption is also the reason why you need your selective drop rules, because my wide-span drop one which normally does their job hasn't survived the copy-paste.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 5:46 pm

Can you copy-paste my script here exactly the same way how you have copy-pasted it to the Mikrotik?
Sure, I first copy/paste it into notepad then onto Terminal via a Winbox connection.
/system backup save name=before-change

/ip firewall address-list
add list=primary-subnets address=172.16.105.0/24
add list=primary-subnets address=172.16.110.0/24

/interface list
add name=WAN

/interface list member
add list=WAN interface=ISP-Virgin
add list=WAN interface=ISP-BT

/ip firewall filter
set [find] comment=the-old-rules

add action=accept chain=input connection-state=established,related,untracked
add action=drop connection-state=invalid
add action=accept protocol=udp dst-port=53 in-interface-list=!WAN
add action=accept protocol=icmp
add action=accept protocol=udp dst-port=500,1701,4500 in-interface-list=WAN
add action=accept protocol=tcp dst-port=22,443,8291 src-address-list=allowed
add action=drop

add action=accept chain=forward connection-state=established,related,untracked
add action=drop connection-state=invalid
add action=accept in-interface-list=!WAN out-interface-list=WAN
add action=accept src-address-list=primary-subnets dst-address-list=primary-subnets
add action=drop
This corruption is also the reason why you need your selective drop rules, because my wide-span drop one which normally does their job hasn't survived the copy-paste.
Understood, thanks. It could have been a forum issue, or browser, for example "Code: Select All" doesn't work on Edge browser.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 6:09 pm

I have just copied the rules from here (Firefox used - mark, copy, paste, no "select all") and pasted them into a PuTTY window, no corruption. Please do it that way. It seems that pasting to Winbox window has some negative effect.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 7:35 pm

I have just copied the rules from here (Firefox used - mark, copy, paste, no "select all") and pasted them into a PuTTY window, no corruption. Please do it that way. It seems that pasting to Winbox window has some negative effect.
I feel like I am doing something really dumb here. So I put them in manually.

Is this what we should be seeing:
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input dst-port=53 in-interface-list=!WAN protocol=udp
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=500,1701,4500 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=22,443,8291 protocol=tcp src-address-list=allowed
add action=drop chain=input
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface-list=!WAN out-interface-list=WAN
add action=accept chain=forward dst-address-list=primary-subnets src-address-list=primary-subnets
add action=drop chain=forward
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 7:47 pm

Yes. In the /export, you should see the rules in exactly the same form and order in which they appear in the script.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 7:58 pm

Yes. In the /export, you should see the rules in exactly the same form in which they appear in the script.
The "chain" component of the script wasn't working on my Winbox or Putty. When I did it line by line manually it asked me every time which chain this rule belongs to, I assumed "input" for the first 6 then "forward" for the last 4.

Unfortunately I seem to be able to ping across segregated networks now, so from 20.20.20.xx to a local machine on 172.16.105.xxx.

There must be something really simple I am doing wrong. If I run it as a script, it fails after the creation of Rule 1, basically at the same place it expects a "Chain" input.
script1.JPG
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 8:17 pm

OK, so the stupidity was at my end, sorry for that. I should not do serious things in the evening.

I've always placed the chain=something only to the first rule in each chain.
And as you've added "input" to all rules, it could not work properly for forwarding.

So a corrected version is here:
/system backup save name=before-change

/ip firewall address-list
add list=primary-subnets address=172.16.105.0/24
add list=primary-subnets address=172.16.110.0/24

/interface list
add name=WAN

/interface list member
add list=WAN interface=ISP-Virgin
add list=WAN interface=ISP-BT

/ip firewall filter
set [find] comment=the-old-rules

add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=udp dst-port=53 in-interface-list=!WAN
add action=accept chain=input protocol=icmp
add action=accept chain=input protocol=udp dst-port=500,1701,4500 in-interface-list=WAN
add action=accept chain=input protocol=tcp dst-port=22,443,8291 src-address-list=allowed
add action=drop chain=input

add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface-list=!WAN out-interface-list=WAN
add action=accept chain=forward src-address-list=primary-subnets dst-address-list=primary-subnets
add action=drop chain=forward

/ip firewall filter remove [find comment~"the-old-rules"]
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
AJSG
newbie
Topic Author
Posts: 27
Joined: Wed Apr 13, 2016 6:43 pm

Re: Unable to update CCR

Wed May 20, 2020 9:03 pm

I should not do serious things in the evening.
Please! You've been an enormous help!
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input dst-port=53 in-interface-list=!WAN protocol=udp
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=500,1701,4500 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=22,443,8291 protocol=tcp src-address-list=allowed
add action=drop chain=input
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface-list=!WAN out-interface-list=WAN
add action=accept chain=forward dst-address-list=primary-subnets src-address-list=primary-subnets
add action=drop chain=forward
This is what I have now and can confirm that you cannot ping across networks. Brilliant! Now all I need to try and sort out is the encryption on the L2TP connection to Tinos.

Thanks,

Andrew.
 
sindy
Forum Guru
Forum Guru
Posts: 5099
Joined: Mon Dec 04, 2017 9:19 pm

Re: Unable to update CCR

Wed May 20, 2020 11:53 pm

I can confirm that you cannot ping across networks.
...
Now all I need to try and sort out is the encryption on the L2TP connection to Tinos.
First I'd like to know that the SIP devices are doing fine with these rules at Malford.

Then, I need to have a look at Tinos firewall rules. To do that, I'd like to understand why you prefer that the Tinos site devices access internet via the VPN tunnel through Malford but you admit direct internet access if both tunnels eventually fail.

Regarding the VPN, are both WAN addresses at Malford stable or does the contract allow the ISPs to change them freely?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: Bing [Bot], Maggiore81, td32 and 83 guests