IP Range for Agent?

We have gotten this question in all shapes and sizes from our vendors, but some get more hung up on the response than others. I know the IMP makes outbound connections only, but client is very concerned about the IP address they are connecting to outside their network. Here’s their specific questions if it helps–we could really use some clarity on how to best answer these.

  1.   Firewall ports can only be opened if there are specific source and destination IP addresses built into the rule. We are not opening up ports 31314 and 993 to any IP address on the internet.

[Can you provide an IP address or even a range for agent.electricimp.com? I know it’s variable…]

  1.   Inbound access should be avoided. But if unavoidable we need to understand:

[Is all this irrelevant because the connection is outbound only?]

a. Lock down from a specific source IP address only.

b. What is the landing interface for the remote management; Command prompt in clear text, or secure webservice or other?

c. Who manages the remote admin account details : Us or vendors

d. What level of access does the vendor have? Admin or user or custom

e. What logging is enabled to understand who logs in, when, and what they are doing?


  1. Devices don’t connect to agent.electricimp.com - that’s agent traffic only. We do not have a fixed IP range or fixed IPs in general for device connectivity, because this is awful for resiliency (and one of the reasons DNS exists!).

The first option is for the customer to offer a HTTP proxy on their local network, which all imp devices will connect to and then ask for their outbound connection. This allows local network administrators to have clear visibility of all the imp sessions. As long as the HTTP proxy on the network doesn’t go down, this does not impact resiliency as devices can still load balance between servers and deal with failures.

The second option is to route all traffic through a single external IP. If a customer is happy that in the event that this specific IP address is not reachable, their devices will go down, then we can provide some solutions that can work. Please file a support ticket and we can give details.

  1. There is no inbound access, so 2a/b/c/d/e are not applicable.

Thanks Hugo, very helpful. I’ll let you know if we need further ammo to help explain this to them.

Client appreciated your reply Hugo, thank you again. They had one further question:

"If the Electric Imp connects with an outbound connection to a URL, why do you choose non-standard ports? There is no detail on whether this outbound traffic is encrypted over these non-standard ports.

If the devices connect to a URL, you should use standard port 443 and encrypt this traffic."

Any color on how you chose your ports would be helpful.


The device doesn’t use HTTP, which means it doesn’t connect “with an outbound connection to a URL”.

Hence the non-standard ports, because there’s no standard to follow. We prefer port 31314 (followed by 993 or 443 to get around simple firewalls).

Traffic from the imp to the imp server is sent over a TLS-secured channel, using certificates for mutual identification (i.e. we also require client certificates). The certificates are currently 2048-bit and use sha256WithRSAEncryption as the signature algorithm. Imps running release 34.x or newer use ECDHE-RSA-AES128-SHA256 as the cipher suite.

One of the benefits of being able to do OTA OS upgrades is that we can choose stronger key lengths or ciphers in future.

Incidentally, the OS upgrade files are also signed, so they can’t be tampered with.

I suspect that Hugo’s comment: “The first option is for the customer to offer a HTTP proxy on their local network” might imply that the imp uses HTTP.

It doesn’t, but (since 33.x) it can use an HTTP proxy that supports the “CONNECT” verb to negotiate its way past a firewall. This can be configured as part of BlinkUp, or through imp.setproxy() in your squirrel code.

Thanks Roger, very helpful. I’ll let you know if they need additional clarification.