Cloud IPs constantly changing. Impossible to Whitelist

Network Management
#1

So we’re trying to use the Mimosa Cloud to monitor a bunch of our devices. Since our devices are on the “public” internet, we basically whitelist the access to them on the edges of our network (we have several egress points so managing the ACL list is difficult).

It appears that Mimosa is using AWS as their cloud provider “without” using Elastic-IPs for their VPCs. What does this mean? It means that every time they spin up a new gateway or release new software, the gateway IPs change. This plays hell with our Cisco ACL lists as it is impossible to filter on a DNS name…

For instance, As of 21SEP2017 our ACL list looked like:

! Allow Mimosa monitoring point(s)
!
! (as of 21 SEPT 2017)
! ;; ANSWER SECTION:
! connect-all.mimosacloud. co. 9 IN A 52.9.185.0
! connect-all.mimosacloud. co. 9 IN A 52.52.56.19
! connect-all.mimosacloud. co. 9 IN A 54.67.60.122
! connect-all.mimosacloud. co. 9 IN A 54.153.10.154
! connect-all.mimosacloud. co. 9 IN A 54.183.10.170
! connect-all.mimosacloud. co. 9 IN A 54.193.91.49
!
remark Access to the connect-all.mimosacloud. co system (hack)
permit ip host 52.9.185.0 any
permit ip host 52.52.56.19 any
permit ip host 54.67.60.122 any
permit ip host 54.153.10.154 any
permit ip host 54.183.10.170 any
permit ip host 54.193.91.49 any

Here we are only a week later and 2 out of the 6 addresses have already changed. Actually looking this morning its now 3 out 6 have changed. And its playing hell with our monitoring as it keeps saying things are down when in fact they aren’t, just that Mimosa has been checking with a new unplublished IP again.

I’ve dealt with dozens of cloud services and this is the first time I’ve found one in the ISP business that seems to go out of their way to not work well with larger ISPs. If you’re running a simple service or one that you don’t care that the entire internet is constantly scanning your network (and you trust the security of an embedded linux device) then this model is probably ok for you. But our radios are probed at least 3-5 times a minute and based on experience with other vendors, my radio network is the last thing I want exposed.

Any suggestions to mitigate this? Build a proxy communications network? Something else? This direct access bit won’t scale at all if the IPs constantly change (I already have 5 exit point ACLs to update and my access counters zero out every time I have to update the list… These are normally static lists for months if not years, not weekly as is the case now)

Marcos

P.S. The “names” look weird above because the forum software things that they are “links” and refuses to post this as is. Talk about fighting the software…

#2

We ran into the same issue. I did some connection watching and made notes, but they changed from one day to the next so I quickly gave up on that approach. We are only using the Cloud Monitoring to diagnose a weird GPS Issue that we have been having.

Currently we have them NATed with our customers IP Addresses, that seems to work alright and NAT gives us some modicum of protection.

But if you figure out some way around this I would like to know. Sounds like we just have to wait for Mimosa to pay the extra cash to get some static IPs in the AWS system… Or Mimosa releases their Cloud software so we can run our own server inside of our network, but that is probably not gonna happen…

#3

Setting up my first Mimosa backhaul. I’m located on “the wrong side of the tracks”, literally. The link carries traffic from an affordable fiber landing location (one side of the railroad tracks) to an unaffordable location 0.7km away. All I want it to do is pass all the traffic in public IP space to both sides of the track.

It works great - except I can’t figure out a way to get the radios to connect to the Mimosa cloud without exposing the radios to all the bad guys.

Marcos2’s solution was one idea, until I found this thread. If anyone comes up with a solution please post.

#4

Mimosa recommends that firewalls be configured for the hostname, connect-all.mimosacloud.co as opposed to specific IP addresses and allow access on ports 80, 443, 8080, and 8443.

http://cloud.help.mimosa.co/manage-faq-mimosa-cloud-access

#5

So, using Cisco routers as our backbone network, the only things we can do are access-lists which do NOT have access to DNS for lookups nor are dynamic (ie, they are set and then routing tables and filters are formed around them).

If you have suggestions on how to filter out your rotating IPs using Access-Lists, it would be appreciated. We’re not small enough to have “single exit” points where we can use some layer 7 device to do analytical filtering. Since we’re peering with various other ISPs at multiple locations, there is no single choke point other than the last PE-to-CE router which is just an IOS based router that has to do both IPv4/IPv6 dual stacking to our customers.

For instance, a partial listing one of my Access-Lists was:

no ip access-list extended CE-outbound
ip access-list extended CE-outbound
remark Filter on PE routers for Customer Equipment (CE)
!
! Permit Established Connections (TCP only)
permit tcp any any established
! …more filters…
!
remark Access to the connect-all.mimosacloud.co system (hack)
permit ip host 13.57.72.86 any
permit ip host 52.8.201.187 any
permit ip host 54.67.60.122 any
permit ip host 54.153.10.154 any
permit ip host 54.183.10.170 any
permit ip host 54.193.91.49 any
!
! …and lately (a security big hole) we are doing the following basically opening up most of
! AWS across the board to our internal management network
!
! Trying a block to see about opening up AWS… sigh
permit ip 13.57.0.0 0.0.255.255 any
permit ip 52.8.0.0 0.0.255.255 any
permit ip 52.9.0.0 0.0.255.255 any
permit ip 54.52.0.0 0.0.255.255 any
permit ip 54.67.0.0 0.0.255.255 any
permit ip 54.153.0.0 0.0.255.255 any
permit ip 54.183.0.0 0.0.255.255 any
permit ip 54.193.0.0 0.0.255.255 any
permit ip 54.215.0.0 0.0.255.255 any
!
! …more filters…denies, etc…
!
remark Block out any RFC1918 source address space
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any log
deny ip 127.0.0.0 0.255.255.255 any
deny ip 224.0.0.0 31.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
!
! Permit all other traffic
!
remark If we haven’t denied it by now, let it go through
permit ip any any
exit