New instances SFTP not working

Technical Support
1

Note - If you do not fill in every section below, your post won’t be answered - you must provide the steps you have followed so far and the actions you’ve already taken. Make sure to remove this notice from your post too.

OS Name/Version: Ubuntu 22.04.1

Product Name/Version: 2.4.4.0

Problem Description: Any new instances SFTP fails to open ports

Network Error: Connection to domain refused

I appear to have all my new instances SFTP fail to connect. Firewall shows waiting after open port but AMP is not responding to the request.

Success with IP:2223 (AMP Instance)
Success with IP:2227 (Instance 7)
Success with IP:2239 (Instance X)
Fails with IP:2228
Fails with IP:2259 (PFSense shows TIME_WAIT:TIME_WAIT)

My firewall is a PFSense and I have TCP/UDP Ports 2223-2323 Open from all my public IP’s assigned to my AMP server running on Ubuntu

Under AMP Networking my Application port ranges has 2223:2323 as the first entry.

Also as a side note, I have bound about 10+ static IP’s to Ubuntu and assigned several IP’s to Minecraft instances, but it seems like there is firewall rules in Ubuntu restricting access on these additional IP’s. Isn’t AMP creating firewall rules to allow this traffic when I choose these static IP’s?

In order to get access, I have to use the first or second static IP’s. Nothing after the first two seem to work.

2

You’re on an old version of AMP. Please update.

3

Issue persists after update and now I’m dealing with new issues :rofl:

4

Does ampinstmgr ports show that it’s listening?

5

Yes, I see
LISTENING 2259 TCP (FileManagerPlugin.SFTP.SFTPPortNumber)

When I start the SFTP connection from outside, my firewall does show the port open and waiting for the server to reply PFSense shows TIME_WAIT:TIME_WAIT

It looks to me like Ubuntu is blocking the port.

IPtables are fine

6

What happens if you try connecting locally from the server itself?

7

i have same issue doesnt work

8

It does seem I found a pattern when looking at netstat. All the SFTP bindings to the hostname:port do not function as opposed to 0.0.0.0:port all work

Why not bind to the public IP assigned to the instance instead of 0.0.0.0?

So after ssh into my host, this is what I ran to see if it connects.

AMP Instance (Active|Running|SCP:Successful)

scp -P 2223 localhost:userdata.json /home/user
fingerprint is not known, Are you sure you want to connect yes/no

Instance 01 (Suspended|Docker|SCP:Refused)

scp -P 2224 localhost:userdata.json /home/user
ssh: connect to host localhost port 2224 : connection refused

Instance 02 (Active|Running|SCP:Successful)

scp -P 2225 localhost:userdata.json /home/user
fingerprint is not known, Are you sure you want to connect yes/no

Instance 03 (Active|Running|Docker|SCP:Successful)

scp -P 2226 localhost:userdata.json /home/user
fingerprint is not known, Are you sure you want to connect yes/no

Instance 04 (Active|Running|Docker|SCP:Successful)

scp -P 2227 localhost:userdata.json /home/user
fingerprint is not known, Are you sure you want to connect yes/no

Instance 05 (Active|Stopped|Docker|SCP:Refused)

scp -P 2228 localhost:userdata.json /home/user
ssh: connect to host localhost port 2255 : connection refused

Instance 06 (Active|Stopped|Docker|SCP:Refused)

scp -P 2229 localhost:userdata.json /home/user
ssh: connect to host localhost port 2255 : connection refused

Instance 07 (Active|Running|Docker|SCP:Refused)

scp -P 2230 localhost:userdata.json /home/user
ssh: connect to host localhost port 2255 : connection refused

Instance 08 (Offline|Docker|SCP:Refused)

scp -P 2231 localhost:userdata.json /home/user
ssh: connect to host localhost port 2255 : connection refused

Instance 09 (Active|Running|Docker|SCP:Successful)

scp -P 2232 localhost:userdata.json /home/user
fingerprint is not known, Are you sure you want to connect yes/no

Not sure if there is any pattern here. Several Active instances should be accepting SFTP connections. Instances 5, 6, 7 are Active and online yet they are refused connections.

ampinstmgr ports for

Instance 5
[Info] LISTENING 2228 TCP (FileManagerPlugin.DFTP.DFTPPortNumber)
Instance 6
[Info] LISTENING 2229 TCP (FileManagerPlugin.DFTP.DFTPPortNumber)
Instance 7
[Info] LISTENING 2230 TCP (FileManagerPlugin.DFTP.DFTPPortNumber)

IPTables

  42     3456 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2228 /* AMP:Terraria01:FileManagerPlugin.SFTP.SFTPPortNumber */
  18     2483 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2229 /* AMP:FrozenFlame01:FileManagerPlugin.SFTP.SFTPPortNumber */
  18     2483 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2230 /* AMP:MCJava101:FileManagerPlugin.SFTP.SFTPPortNumber */

It does seem I found a pattern when looking at netstat. All the SFTP bindings to the hostname:port do not function as opposed to 0.0.0.0:port all work

Netstat

tcp 0 0 0.0.0.0:2223 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2235 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2232 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2239 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2236 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2237 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2226 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2227 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2225 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2250 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2251 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2248 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2249 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2252 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2242 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2243 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2246 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2244 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2245 0.0.0.0:* LISTEN

tcp 0 0 hvm-cld-amp:2238 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2234 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2233 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2230 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2228 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2229 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2258 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2259 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2256 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2257 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2255 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2247 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2240 0.0.0.0:* LISTEN
tcp 0 0 hvm-cld-amp:2241 0.0.0.0:* LISTEN

9

Use ampinstmgr ports to check for what’s listening instead.

Also if the IP addresses work but the hostnames do not, then it’s a DNS problem. Connection Refused means nothing is listening at the remote endpoint and actively rejected the connection.

10

I already used the command, results were posted in my response.

The issue is a configuration problem on the Ubuntu server. Scping from the localhost to those ports that should be listening shows no response.

Futher evidence of a configuration issue is that sftp service is not binding to 0.0.0.0 for the ports that do not work.

I am unaware of any way to change this behavior as it happens under the hood during instance creation.

11

Does your server have multiple, physical NICs?

12

Its a virtual machine with at least one nic that has several public IPs assigned.

The next time I log in I will check to see if I have another nic, but I think its just the one.

DNS would not be an issue when using localhost in the scp command.

13

Under Configuration → Networking - show me your default network settings for new instances.

14

1000030337
10000303371074×2090 191 KB

15

Your default application IP binding should be 0.0.0.0. That’s why you’re having problems.

16

I have 11 public IPs assigned to Ubuntu. I need to bind default instances to one IP so that different instances of the same game can all use the same port across different IP’s.

Setting to 0.0.0.0 resolves issue for new Instances, but the existing instances still have the issue.

How can I manually adjust the default IP binding of an active instance?

17

AMP is not multi-IP aware at this time and it’s port allocation cannot accommodate this right now.

For games like Minecraft you should use SRV records, but it’s not currently possible to have multiple games use the same port by using different IPs.

Changing it for existing instances is difficult, it’s probably easier to re-build those instances by copying any important data out of them.

18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.