vNode Mainnet Crashes with Certain VPN

I have done extensive testing on this problem and need some help to resolve it, probably from someone on the technical side of the house.

If I am connected to a certain VPN provider and then start the ETH mainnet and the Incognito mainnet, the ETH starts and runs just fine, but the Incognito mainnet crashes instantly. This occurs when using the most up-to-date Docker image.

Doesn’t work: Connect server to “problem” VPN, start inc/eth mainnets, inc_mainnet crash/restart.
Does work: Start inc/eth mainnets using different VPN, switch server to “problem” VPN, both mainnets work and are actively using the “problem” VPN IP (which means it’s not really the problem).

Testing Observations:

  • Other non-VPN IPs and other VPN providers do not cause this problem.
  • All tested IPs from this one VPN provider cause issues.
  • It is not a network configuration issue on the server machine (see following points).
  • Same results occur whether the server is being routed through a VPN-connected router or the VPN client is being run locally on the server.
  • Allowing the inc_mainnet to start and then switching to the VPN allows it to keep running while connected to the VPN.
  • I confirmed the inc_mainnet was using the VPN IP, even when switching to the VPN after starting inc_mainnet, so there is not a problem with the VPN. I can even connect to the inc_mainnet server VPN IP:port successfully.

Moving Forward:

  • Is there any way to enable or view logging from the container that might explain why it’s crashing?
  • Can someone help me comb through the source code to find what might be causing the issue? I glanced at the source code (, but I don’t have nearly enough time to do this cold. I need someone already familiar with it. Since it only happens with this VPN provider, I suspect it’s an issue with DNS or something, or it’s calling out to a service that is blocking this VPN. I need to find out what exactly.

Thanks @int1. I hope our core member will help to look into it.
@khanhj Please advise.


Hey @int1,

  1. What “problem” VPN Service Provider you are using?
  2. We are no longer support gETH, please use Infura instead. Check this thread to setup How to host a Virtual Node
  3. Here is the path of log file:

Thanks, @khanhj ! That problem has now been resolved. I am now able to connect to the vNode externally/from the app. My next question is about the Infura ports. I saw on a different thread you discussing which ports to forward. I have the inc RPC and Node ports forwarded, of course, but I’m still unclear on the eth ports. I’ve read many places that the 8545 port should not be accessible by public internet (i.e. do not port forward) for security reasons. So do I need to forward the eth_mainnet ports 8545 and/or 30303 for my inc_mainnet to work properly?

Again, thanks for the help on where the logfile was for the last issue!

Hey @int1,
Sorry for late reply, I’m not active on forum recently.

With infura setup, you don’t need to open 8545 or 30303 port.
As you can see in this command:

docker run --restart=always --net inc_net -p $node_port:$node_port -p $rpc_port:$rpc_port -e NODE_PORT=$node_port -e RPC_PORT=$rpc_port -e BOOTNODE_IP=$bootnode -e -e GETH_PROTOCOL=https -e GETH_PORT= -e MININGKEY=${validator_key1} -e TESTNET=false -v $PWD/${data_dir}:/data1 -d --name inc_mainnet1 incognitochain/incognito-mainnet:${latest_tag}

we set port to null -e GETH_PORT=

1 Like

Hi @khanhj, And what about the script provide by incognito on

Do we actually need to open 8545 and 30303?

Thank you

Hi @Stradimarius you still need to open 8545 and 30303 with the current script on


Ok so the question still remains if I need to port forward the 8545 and 30303 ports to the server running it from the script. And why does that need it but not the command @khanhj posted? Is it because his uses GETH instead of Parity? Or what? Is it possible to run the two separate Docker containers in the script (inc_mainnet and eth_mainnet) without any ETH-related port-forwarding?

@int1 there are 2 different scripts here.
With the default (, it is using GETH so you need to open 8545 and 30303.


If you are using the script from @khanhj provided, it was routed to Infura (not using GETH anymore) so you don’t need to open 8545 & 30303.

No, if you run ETH docker, you have to open ETH-related port-forwarding.

Uhhh… somthing is wrong here. Maybe it’s my brain. The default does NOT use GETH (Go). It uses Parity (Rust). Or am I just blind? I’ve read the whole thing myself and modified parts. I’m familiar with it. You even quoted it, and it literally showed that GETH is commented out, and it uses Parity. So I’m more confused now than I was before. I’m going to take a guess at what you were trying to say, and maybe you can clarify from there. Did you mean that the default script uses an actual client (like Parity or GETH), and Khanj’s implementation uses Infura v3 ( directly (which they can be using GETH or or Parity, by the way)? So if you use GETH OR PARITY, you MUST port-forward, but if you are running it through Infura’s hosting, obviously no forwarding needed there. Is that right?

Hi @int1 sorry for the confusing.
GETH, Parity, and Infura are 3 different services to get Ethereum block. So, this sentence is correct:

If you are running it through Infura’s hosting, no forwarding needed there.

1 Like