It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Made the exception in my firewall + Portforward TCP/TDP ports 6112-6119. I no longer get the red warning screen of having a blocked port. Awesome.

I made sure that I'm running Diablo "Classic"


Now I'm stuck on 'Connecting to fastest server."

After about 10 seconds, it tells me I have no internet.

What's my next step?
Attachments:
Post edited March 10, 2019 by calcem
No posts in this topic were marked as the solution yet. If you can help, add your reply
скажите пожалуйста, какой у вас шлюз показывает при подключении к battle.net
avatar
sifaaa: скажите пожалуйста, какой у вас шлюз показывает при подключении к battle.net
There's only 1 gateway: Global.
Attachments:
gateway.bmp (309 Kb)
It worked for me yesterday but it's not working now
I'm having this exact same problem, so it's not just you
Post edited March 11, 2019 by freakishspleen
Thursday march 7th:
I downloaded the game, got it to work in a few seconds, joined the old Battle net and started playing with people! So much fun.

Saturday march 9, and sunday march 10, Battle net not working (port 6112 error) . I did EVERYTHING possible, and my router and firewall are fine (it worked on thursday anyway...)


What the hell?
Port forwarding was never a thing people needed to do. Routers automatically open up ports necessary for games to connect through. If your computer is running it, then it has automatic access. 6+ months ago I torrented Diablo, and connected to Bnet without any problems. Even the above poster here had a smooth experience on day 1.

What happened between March 7th and now? Many people still can't connect. A dev answer would be much appreciated. I'm trying to get out there and help my fellow players.
avatar
Martin518: Thursday march 7th:
I downloaded the game, got it to work in a few seconds, joined the old Battle net and started playing with people! So much fun.

Saturday march 9, and sunday march 10, Battle net not working (port 6112 error) . I did EVERYTHING possible, and my router and firewall are fine (it worked on thursday anyway...)

What the hell?
I'm having the same issue. I opened all of the ports and still get the port 6112 error.
avatar
Martin518: Thursday march 7th:
I downloaded the game, got it to work in a few seconds, joined the old Battle net and started playing with people! So much fun.

Saturday march 9, and sunday march 10, Battle net not working (port 6112 error) . I did EVERYTHING possible, and my router and firewall are fine (it worked on thursday anyway...)

What the hell?
avatar
bostedjustin: I'm having the same issue. I opened all of the ports and still get the port 6112 error.
Same boat.


Was able to play last night fine for a couples. Been trying off/on since about 1PM and still not able to connect now.
avatar
bostedjustin: I'm having the same issue. I opened all of the ports and still get the port 6112 error.
avatar
Uzur9: Same boat.

Was able to play last night fine for a couples. Been trying off/on since about 1PM and still not able to connect now.
And same here. Could play Wednesday and Thursday but not today. Funny part is my roommate is playing right now while I cannot connect. I am no network engineer, but does it have anything to do with that? Only one user can directly go through the port (or whatever) Hopefully it's just a temp glitch, but I am worried seeing as this game is old, the prioritizing is downgraded or just flat out ignored :)
avatar
Uzur9: Same boat.

Was able to play last night fine for a couples. Been trying off/on since about 1PM and still not able to connect now.
avatar
Arq73: And same here. Could play Wednesday and Thursday but not today. Funny part is my roommate is playing right now while I cannot connect. I am no network engineer, but does it have anything to do with that? Only one user can directly go through the port (or whatever) Hopefully it's just a temp glitch, but I am worried seeing as this game is old, the prioritizing is downgraded or just flat out ignored :)
Yes if your roommate is playing and you are sharing the same router, then you cannot play at the same time. Port forwarding means, that the router just sends every packet that gets to port 6112 to the configured forward.

Other than that I am experiencing the same problems as OP
avatar
karlyan17: Yes if your roommate is playing and you are sharing the same router, then you cannot play at the same time. Port forwarding means, that the router just sends every packet that gets to port 6112 to the configured forward.
This is partly true, but incomplete. It's perfectly possible to have multiple people behind a single router playing at the same time. It does however require configuring the router with individual forwardings for each player. Low end consumer home routers may not be flexible enough to let you do the right thing, even if you know exactly what you want to do. More advanced ones (including devices built on Linux if the device exposes the underlying firewall capabilities) can do the right thing.

The rest of this post is a rough description of how to do it on a Linux-based router. You will probably need to read your router's documentation or other online advice to map it to something that works for you, but it should give you a starting point for research. You can also ask here for further help, but I cannot guarantee anyone here will know how to (or even if you can) configure any given router.

You need, for each internal computer:

- A nat rule to remap incoming traffic to the appropriate internal system. In iptables syntax, this would be iptables -t nat -A PREROUTING -d $MY_INTERNET_IP_ADDRESS -p udp -m udp --dport $PLAYER_EXTERNAL_PORT -j DNAT --to-destination $PLAYER_INTERNAL_IP:6112
- A filter rule to permit the incoming traffic to be delivered. (Otherwise, a default-deny policy will block the traffic.) In iptables syntax, this would be iptables -t filter -A FORWARD -d $PLAYER_INTERNAL_IP -p udp -m udp --dport 6112. Yes, we want a literal 6112 here, because that is what Diablo (and Starcraft, and Warcraft 2) use. The nat rule above rewrote whatever external port to be a literal 6112.
- A nat rule to remap outgoing traffic, as a mirror of the above. On simple setups (only one person playing), an implicit rule can do the right thing. Here, we want to control exactly what happens so that we can guarantee this rule cooperates with the above nat rule. In iptables syntax, this would be: iptables -t nat -A POSTROUTING -s $PLAYER_INTERNAL_IP -p udp -m udp --sport 6112 -j SNAT --to-source $MY_INTERNET_IP_ADDRESS:$PLAYER_EXTERNAL_PORT. This takes outgoing traffic and gives it the correct public IP (easy, and automatic in the simple case) and more importantly, fixes up the port so that it mirrors the rule for incoming traffic. This ensures that unsolicited traffic (people trying to join your game) contact you on the correct port.

$MY_INTERNET_IP_ADDRESS: your public IP address. Your router knows this address. If you're lucky, it even has a syntactic shortcut to insert that in the rules without requiring you to look up the actual value. You probably should not post this, unless you don't care about privacy.
$PLAYER_EXTERNAL_PORT: the public UDP port you want your traffic to appear to have, as seen by battle.net and the rest of the world outside your home network. Each player needs a separate value here. For simplicity, give player #1 port 6112, player #2 port 6113, etc. Assign one port to every computer you might want to use, whether or not any given pair of them ever play online at the same time.
$PLAYER_INTERNAL_IP: the internal (usually, but not always, 192.168.0.x) address of that player's computer. Get it from ipconfig at a Windows command prompt. If you're lucky, your router always assigns the same address to the same computer. Common values are 192.168.x.y, 172.16.x.y, or 10.0.0.x. You can safely post these addresses; they are only meaningful to your router and the systems on your home network.
avatar
karlyan17: Yes if your roommate is playing and you are sharing the same router, then you cannot play at the same time. Port forwarding means, that the router just sends every packet that gets to port 6112 to the configured forward.
avatar
advowson: This is partly true, but incomplete. It's perfectly possible to have multiple people behind a single router playing at the same time. It does however require configuring the router with individual forwardings for each player. Low end consumer home routers may not be flexible enough to let you do the right thing, even if you know exactly what you want to do. More advanced ones (including devices built on Linux if the device exposes the underlying firewall capabilities) can do the right thing.

The rest of this post is a rough description of how to do it on a Linux-based router. You will probably need to read your router's documentation or other online advice to map it to something that works for you, but it should give you a starting point for research. You can also ask here for further help, but I cannot guarantee anyone here will know how to (or even if you can) configure any given router.

You need, for each internal computer:

- A nat rule to remap incoming traffic to the appropriate internal system. In iptables syntax, this would be iptables -t nat -A PREROUTING -d $MY_INTERNET_IP_ADDRESS -p udp -m udp --dport $PLAYER_EXTERNAL_PORT -j DNAT --to-destination $PLAYER_INTERNAL_IP:6112
- A filter rule to permit the incoming traffic to be delivered. (Otherwise, a default-deny policy will block the traffic.) In iptables syntax, this would be iptables -t filter -A FORWARD -d $PLAYER_INTERNAL_IP -p udp -m udp --dport 6112. Yes, we want a literal 6112 here, because that is what Diablo (and Starcraft, and Warcraft 2) use. The nat rule above rewrote whatever external port to be a literal 6112.
- A nat rule to remap outgoing traffic, as a mirror of the above. On simple setups (only one person playing), an implicit rule can do the right thing. Here, we want to control exactly what happens so that we can guarantee this rule cooperates with the above nat rule. In iptables syntax, this would be: iptables -t nat -A POSTROUTING -s $PLAYER_INTERNAL_IP -p udp -m udp --sport 6112 -j SNAT --to-source $MY_INTERNET_IP_ADDRESS:$PLAYER_EXTERNAL_PORT. This takes outgoing traffic and gives it the correct public IP (easy, and automatic in the simple case) and more importantly, fixes up the port so that it mirrors the rule for incoming traffic. This ensures that unsolicited traffic (people trying to join your game) contact you on the correct port.

$MY_INTERNET_IP_ADDRESS: your public IP address. Your router knows this address. If you're lucky, it even has a syntactic shortcut to insert that in the rules without requiring you to look up the actual value. You probably should not post this, unless you don't care about privacy.
$PLAYER_EXTERNAL_PORT: the public UDP port you want your traffic to appear to have, as seen by battle.net and the rest of the world outside your home network. Each player needs a separate value here. For simplicity, give player #1 port 6112, player #2 port 6113, etc. Assign one port to every computer you might want to use, whether or not any given pair of them ever play online at the same time.
$PLAYER_INTERNAL_IP: the internal (usually, but not always, 192.168.0.x) address of that player's computer. Get it from ipconfig at a Windows command prompt. If you're lucky, your router always assigns the same address to the same computer. Common values are 192.168.x.y, 172.16.x.y, or 10.0.0.x. You can safely post these addresses; they are only meaningful to your router and the systems on your home network.
Hey advowson,

awesome write up thanks :D
It helped me to solve my problem.
I had my configuration already as you described (with a vpn server serving as the router in my case, but details...).
For the POSTROUTING chain I have MASQUERADE instead of SNAT which seems to work fine (i guess if not specified, the same sport is the same?).

The problem was, that I configured forwarding for both tcp and udp and somehow that did not work? I don't understand why this should be a problem, but that's what did it for me. Do you know why that is by any chance?

EDIT: grammar
Post edited March 17, 2019 by karlyan17
avatar
Martin518: Thursday march 7th:
I downloaded the game, got it to work in a few seconds, joined the old Battle net and started playing with people! So much fun.

Saturday march 9, and sunday march 10, Battle net not working (port 6112 error) . I did EVERYTHING possible, and my router and firewall are fine (it worked on thursday anyway...)

What the hell?
Same problem. Blizzard doesn't want to do maintenance on a dusty old b.net server.
avatar
karlyan17: awesome write up thanks :D
It helped me to solve my problem.
Good to hear.
avatar
karlyan17: For the POSTROUTING chain I have MASQUERADE instead of SNAT which seems to work fine (i guess if not specified, the same sport is the same?).
Yes, mostly. They try to keep the same port if possible. That may not work for you if you use DNAT to rewrite the Internet-side view of player's UDP ports to fixed values, but let MASQUERADE/SNAT guess what to use. If your configuration works, let it be. If it breaks, that mismatch is where I would start investigating.
avatar
karlyan17: The problem was, that I configured forwarding for both tcp and udp and somehow that did not work? I don't understand why this should be a problem, but that's what did it for me. Do you know why that is by any chance?
I don't. Diablo uses TCP/6112 to talk to battle.net for logon/chat/matchmaking, but only UDP/6112 to talk to other players. (It also uses UDP/6112 to battle.net, but that's mostly just for latency measurement and the early warning that your firewall might not let others join. If not for the client locking out the create/join buttons when you fail to use UDP to battle.net, you wouldn't need UDP to battle.net to work at all.) If your tcp forwarding somehow misrouted traffic so that attempts to talk to battle.net were sent elsewhere, that would break affected users' ability to get on battle.net, but I would not expect any other consequences. What exactly went wrong when your bad tcp rule was present? Can you reproduce the failure at will by restoring the bad rule?