New Member
•
3 Messages
Custom NAT/Gaming service not working
I have a BGW210-700 running version 2.17.5
I'm outside the house trying to test remotely connecting to Minecraft server running on a linux system.
NAT/Gaming config:
SSH server TCP/UDP: 22
Minecraft TCP/UDP: 25565
Name Global Port Range Protocol Host Port Edit Delete
Minecraft 25565 - 25565 TCP/UDP 25565
Things I've done that do work:
from my laptop I can SSH to Broadband IPv4 Address on port 22
from server I can: telnet 127.0.0.1 25565
from server I can: telnet 192.168.1.*** 25565 (the DHCP assigned address)
from my laptop I use the Minecraft client on "127.0.0.1:7654" if I set up an SSH tunnel with "ssh -L 0.0.0.0:7654:0.0.0.0:25565"
Things that do NOT work:
from server I can NOT: telnet 69.53.***.*** 25565 (Broadband IPv4 Address)
from laptop I can NOT: telnet 69.53.***.*** 25565
from laptop I can NOT use the Minecraft client on 69.53.***.*** 25565
I've also set up remote syslog of the gateway to the linux server and I see plenty of DENY'd traffic from the internet. I can also force DENY result with command "telnet 69.53.***.*** 1234". I only see DENY for 25565 when I do not have the custom NAT rule set.
Jun 28 19:26:30 dsldevice.attlocal.net 2022-06-28T12:26:30.046301-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 CWR ECE SYN URGP=0 OPT (MSS=1360 WSCALE=6 TSTAMP=0x9fbff62200000000 SACKOK )
Jun 28 19:26:31 dsldevice.attlocal.net 2022-06-28T12:26:31.122280-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (MSS=1360 WSCALE=6 TSTAMP=0x9fbffa5300000000 SACKOK )
Jun 28 19:26:32 dsldevice.attlocal.net 2022-06-28T12:26:32.146276-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (MSS=1360 WSCALE=6 TSTAMP=0x9fbffe5300000000 SACKOK )
Jun 28 19:26:33 dsldevice.attlocal.net 2022-06-28T12:26:33.312300-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (MSS=1360 WSCALE=6 TSTAMP=0x9fc002e400000000 SACKOK )
Jun 28 19:26:35 dsldevice.attlocal.net 2022-06-28T12:26:35.656275-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (MSS=1360 SACKOK )
Jun 28 19:26:45 dsldevice.attlocal.net 2022-06-28T12:26:45.002287-07:00 L4 FIREWALL[6513]: nflog_log_fw(), action=DROP reason=POLICY-INPUT-GEN-DISCARD hook=INPUT mark=134217728 IN=br2 OUT= MAC=00:00:00:00:00:00:00:d0:**:**:**:**:**:** SRC=69.53.***.*** DST=99.73.***.*** LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=32778 DPT=1234 SEQ=2787252046 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (MSS=1360 SACKOK )
JefferMC
ACE - Expert
•
33.1K Messages
1 year ago
You should not expect to be able to connect to the public IP address from within your private network. The AT&T Gateway does not support NAT Loopback, so traffic from within your network to that IP will become lost.
One test I don't see anywhere in your list is connecting from your laptop to your internal linux minecraft server (while both are in your local network) using the Private IP, to the minecraft port using telnet or anything else. Did you try that? What happened?
0
0
gilko
New Member
•
3 Messages
1 year ago
I figured the public IP wouldn't work internally but I was just being thorough with testing all the combinations.
I was and currently out of town at the moment. All the tests above from my laptop are out of the house across the public internet.
The closet to testing with the laptop on the local network is using on the linux server itself.
ssh (and telnet to port 22) across the internet works great to the public IP.
minecraft (and telnet to port 25565) does not work to the public IP.
minecraft (and telnet to port 25565) on the linux server to the DHCP assigned IP works.
0
0
JefferMC
ACE - Expert
•
33.1K Messages
1 year ago
Using localhost is a good testing step, and using the host's own private IP from that host is good, but also very similar. Taking one more step away from the linux host will tell us more about the situation.
Do you have the minecraft server running directly on the linux host, or via a container on the linux host?
And I assume you are aware of the perils of having the SSH port directly connected to the Internet and have taken suitable precautions (e.g. a client certificate and/or an extremely complex password).
0
0
gilko
New Member
•
3 Messages
1 year ago
I do have the minecraft server running in a container.
I do understand the security implications and I have only one account with an auto generate long password and client cert authentication set up. I subscribe to security notification and I've already applied the latest update for CVE-2022-2097.
0
0
JefferMC
ACE - Expert
•
33.1K Messages
1 year ago
Okay, so it does look like you've done 1:1 mapping on the same port on the container (a common issue is that the mapping here is not done or not done correctly). I do note that Minecraft normally also requires UDP access on the port and your container information above appears to only pass TCP. This would not affect your testing of TCP port access, but may interfere with the game running properly if you don't also allow UDP. I note in your port forwarding information in your OP that you did include TCP/UDP there.
Other than that, I would like to know if a host other than the linux host within your private network can connect to 25565 using the private IP.
0
0