Bitcoin-Core P2P Client Has UPnP.

I use a Bitcoin client, which is called “Bitcoin Core“. This is a version of Bitcoin, based on Peer-To-Peer protocols. This version of the wallet-program should not be confused with the Android version, which some people have on their phones, and which is Not P2P.

Several people who use the P2P version of this wallet-program, which builds our local copy, of the global block-chain, on a zero-trust basis, have observed that they leave their client running 24/7, yet that they do not seem to be functioning as a full peer. As a full peer, their computer can act to facilitate Bitcoin transfers. Even when not being used as a full peer, this version of the program will connect with up to 8 other peers – using outbound connections – and will use these connections to keep its internal version of the block-chain – and therefore their wallet – synced with the rest of the network.

So after some time, what people may simply ask is, ‘Why don’t I receive incoming connections, from other wallets, expecting me to help complete their transactions?’ This would be a reasonable question, yet gurus elsewhere have given a wrong answer.

In general, this P2P Node needs to listen on TCP Port 8333. Therefore, what some people expect, is that they need to establish a port-forwarding rule on their router, which forwards TCP Port 8333 to whichever machine on the LAN is running Bitcoin Core. The advice has sometimes been given, that if you forward this port, you will start receiving massive numbers of inbound connections, and will become useful to the network.

There’s a slight problem with this version of an explanation. Bitcoin Core has the ability to use ‘UPnP’, which is also known as “Universal Plug-And-Play”. What UPnP does, is allow individual clients of our LAN to open a required port on the WAN-side of the router, such as TCP Port 8333 if need be. Because some users believe that enabling UPnP on their routers, makes their routers ineffective as a firewall, they disable this feature. This would be, because those users cannot even trust their LAN-clients, in which case the LAN-clients could trivially request forwarding rules, which the operators of such a LAN did not authorize.

The problem I see, is that I, personally, have UPnP enabled on my router, because I believe my actual LAN-clients to be secure, so that according to me, if they want a WAN port number, they can have it. Also, I have UPnP enabled on my Bitcoin Core P2P / wallet-program. Therefore, the LAN-client in question is requesting this Port 8333, and is obtaining it. Yet, I still don’t see a wealth of inbound connections asking for my CPU time.


There could be several reasons for this, one of which might have been, that a software-firewall on the client-machine in question could be blocking Port 8333. But I, personally have checked my software-firewall. It tells me that it is allowing all connections to and from my Bitcoin Core client a-okay. Maybe the firewall of some other participant is not?

Answer: The Windows computer my Bitcoin Core client is running on, had the LAN connection set to Public. According to Windows firewall rules, access to this program on the host machine is only granted when the network would be Private. This is to allow quick access to Public networks, which are not trusted, without reconfiguring the computer, while setting up a more-liberal set of rules for Private networks. Changing the network-type to Private seems to have solved this problem.

With certainty, my Bitcoin Core client will not show me any transactions it has facilitated, because those transactions do not affect my wallet. Bitcoin is designed to be anonymous, so that I will only see transactions which affect my own balance.



Possible Explanation for Recent Router Crash

Just yesterday my router crashed, and I documented this event Here. At the time, the cause for that event did not seem obvious to me, but by now, I have a possible explanation in mind.

The fact should be understood, that with TCP protocol, there exist two basic types of packets: SYN Packets, and session-specific, Data Packets. For example, in the case of an HTTP server which is ‘always’ listening on Port 80, the actual packets which get sent to that port by browsers are likely to be SYN packets, which request a new session. The function of these packets to the client, are to request a dedicated Data Port on the server to be opened, so that the client and server can exchange data on this additional port. Such a port can then also correspond to one session.

A type of Web-attack is possible, in which a maximum possible number of SYN Packets is sent to Port 80 in this case, thus causing a huge number of session-ports to open on the server, for which the client may not even be arranging to have any kind of session. In fact, doing so not even requires that a bogus log-in attempt to any service be made, nor that a password be guessed at, for which reason such a situation may not get logged – as real hacking attempts – in any of the security logs the server keeps. So where, then is the danger of this to the server?

The situation can arise, that indeed thousands of session-ports, if not tens of thousands, have been opened on the server, all waiting for a new session.

The router mirrors all these ports on the WAN, and tries to map them back to a specific machine on the LAN, that they belong to. This is called Port-Triggering. Hence, if ?50,000? session-ports have been opened on the one server, on the LAN, the request exists implicitly to the router, to keep 50,000 ports open on the WAN as well.

The problem with this can be, that at some point the router runs out of memory to map that many ports. This can cause a router to crash, especially in the case of a domestic router, which is not really designed as solidly as commercial, big-time server-switches are designed.

The problem is less likely in my case, that the server runs out of resources, simply because mine is a 64-bit machine.

But in order to protect myself against such an attack, my server config files need to be such, that not only the speed of incoming SYN Packets is throttled, but also so that any session-ports close automatically, if they are idle for some period of time.

Presumably, the WAN ports will close again on the router, whenever the corresponding ports on the LAN-based server are closed.

While this might sound very far-fetched to some readers, I am aware that this type of an attack takes place often against my machine, coming from robots who-knows-where. I have ways of knowing this, that also display which IP addresses such things come from. But for the most part this does not spur me to start blocking an inordinate number of IP address ranges – arbitrarily, in a world where IP addresses often change. Instead, I focus on closing the vulnerability where I can, in the client keep-alive settings of various servers and applications, that all run on this host.

In general, my HTTP and HTTPS servers are configured correctly, by Debian package maintainers, to thwart such an attack. But I have discovered another service running on my host, and listening for incoming connections on the WAN, which was not configured to be bulletproof in this regard.

Quite possibly, one of those robots discovered the same vulnerability on September 10. If this did happen, it would adequately explain why the router crashed. As of now, that additional service running on my host, has a new configuration, designed to make my router less vulnerable.

If this explanation is true, then users may have experienced problems retrieving my URLs, earlier than 13h05 yesterday. If this was your experience, I apologize again.

If the router crashes again any time soon, then I will need to start looking for other explanations.