Connecting to remote Geth client from AWS hosted server via web3 needs fix

Question

There is a general problem that is affecting most everyone who tries to initialize AWS hosted servers with a remote Geth instance. It would be great to have documentation to address a fix or at least a workaround.

As demonstration, I have a problem connecting to my ec2 hosted Geth node from my AWS Express server with web3. I think a critical breaking point is security groups setup. I've given lax permissions to geth options on startup geth --rpc --rpcapi eth,web3,personal --fast --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --testnet. This should be ok, assuming only my server IP is whitelisted in the Geth assigned security group. I have no issues testing contract deployment from my Geth client using web3 requests from an Express server on my local machine (my local IP is also whitelisted).

Now, given the assumption that problems connecting to Geth are coming either from the AWS Express server on startup or from Geth instance security rules, here are a list of potential security questions I have that will hopefully lead to a fix.

Specifically regarding ingress rules for the Geth client:

1. Is TCP with the Express server's public IP and port 8545 sufficient to connect?
2. Are UDP and TCP on port 30303 from all IPs a necessary requirement? (Other ports like 30304/30301? Some confusion in forums about legacy ports.)
3. Is ICMP required to be open? (I doubt pinging is necessary to establish an initial connection but I don't know.)
4. Are NAT options required on Geth startup?
5. Also, egress rules are completely open.

Regarding an AWS hosted Node/Express server:

1. Does the instance (or load balancer) have to allow messages from the Geth client? (I've included them in my rules just in case.)
2. An error that many users see on server spinup begins with these lines of code:

Error log-

{Error: EROFS: read-only file system, open '.node-xmlhttprequest-sync-1'
at Error (native)
at Object.fs.openSync (fs.js:641:18)
at Object.fs.writeFileSync (fs.js:1347:33)
at send (/var/task/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:477:10)
at HttpProvider.send (/var/task/node_modules/web3/lib/web3/httpprovider.js:91:13)
...
...}

Perhaps some permissions require modification in the OS.

Here is my standard web3 config:

var Web3 = require('web3');
var web3 = undefined;
var fs = require('fs');

if (typeof web3 !== 'undefined') {
  web3 = new Web3(web3.currentProvider);
} else {
  // set the provider you want from Web3.providers
  web3 = new Web3(new Web3.providers.HttpProvider("http://xx.xxx.xx.xxx:8545")); //Geth node
}

exports.accounts = web3.eth.accounts;

exports.myContract = web3.eth.contract(JSON.parse(fs.readFileSync('./compiled_contracts/myContract.abi', 'utf8')));
exports.myContractCompiled = "0x" + fs.readFileSync('./compiled_contracts/myContract.bin');

exports.web3 = web3;

I'm hoping someone has some clear insight to share here.

Answer 1

1. Is TCP with the Express server's public IP and port 8545 sufficient to connect?

Yes, it does not require any other port open

2. Are UDP and TCP on port 30303 from all IPs a necessary requirement? (Other ports like 30304/30301? Some confusion in forums about legacy ports.)

Yep, as far as I see those ports are not in use anymore.

3. Is ICMP required to be open? (I doubt pinging is necessary to establish an initial connection but I don't know.)

Nop in this case, the handshake is made thought JSON-RPC on port 8545

4. Are NAT options required on Geth startup?

None, I have a server running, although not in AWS, and I did not set up any NAT options to make it work.

As far as I can understand of your issues, it seems to be related to AWS and a filesystem default permissions.

I found this issue from a guy who suffered the same error. He sorted it out by changing the working directory to /tmp at the beginning of the node script as follow:

process.chdir('/tmp'); 

https://nodejs.org/api/process.html#process_process_chdir_directory