0
I saw many posts about the subject, but none of the suggested solutions seem to address my problem.
I am using simple echo client-server programs test connectivity to Amazon EC2 instance running Ubuntu 12 64 bit. (Java EchoServer ; Java EchoClient )
Here are the facts:
I created a rule in the security group enabling Inbound TCP on port 22000
TCP Port (Service) 22000-22001 Source 0.0.0.0/0Ubuntu firewall is disabled
sudo ufw disable- When I try
EchoClient [amazon-instance-dns-addr] 22000from another Amazon EC2 instance it works fine as expected - When I ping
[amazon-instance-dns-addr]from external machine I get responses (I enabled the ICMP rule in the security group, too). - When I try
EchoClient [amazon-instance-dns-addr] 22000from external machine it fails to connect. - In wireshark running on the external machine I see that the remote side replies with RST to my port 22000 SYN.
So bullet #5 is the problem. I do not see what I am missing. I would appreciate some help here.
Update: iptables -L output.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ufw-before-logging-forward all -- anywhere anywhere
ufw-before-forward all -- anywhere anywhere
ufw-after-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-reject-forward all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-output all -- anywhere anywhere
ufw-before-output all -- anywhere anywhere
ufw-after-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
ufw-reject-output all -- anywhere anywhere
ufw-track-output all -- anywhere anywhere
Chain ufw-after-forward (1 references)
target prot opt source destination
Chain ufw-after-input (1 references)
target prot opt source destination
Chain ufw-after-logging-forward (1 references)
target prot opt source destination
Chain ufw-after-logging-input (1 references)
target prot opt source destination
Chain ufw-after-logging-output (1 references)
target prot opt source destination
Chain ufw-after-output (1 references)
target prot opt source destination
Chain ufw-before-forward (1 references)
target prot opt source destination
Chain ufw-before-input (1 references)
target prot opt source destination
Chain ufw-before-logging-forward (1 references)
target prot opt source destination
Chain ufw-before-logging-input (1 references)
target prot opt source destination
Chain ufw-before-logging-output (1 references)
target prot opt source destination
Chain ufw-before-output (1 references)
target prot opt source destination
Chain ufw-reject-forward (1 references)
target prot opt source destination
Chain ufw-reject-input (1 references)
target prot opt source destination
Chain ufw-reject-output (1 references)
target prot opt source destination
Chain ufw-track-input (1 references)
target prot opt source destination
Chain ufw-track-output (1 references)
target prot opt source destination
glagolig
Posted 2014-02-22T00:09:51.790
Reputation: 101
1Disabling the ufw service that manages the firewall doesn't disable the firewall itself, which is part of the kernel. Did you check that there are no firewall rules blocking the traffic? – David Schwartz – 2014-02-22T00:18:56.270
@David Schwartz not 100% sure; iptables -L outputs a lot of stuff but no explicit port/address rules, nothing that would explain difference between #3 and #5 – glagolig – 2014-02-22T01:05:53.523
If
iptables -Loutputs a lot of stuff, then you have firewall rules, likely these are the issue. – David Schwartz – 2014-02-22T01:08:47.087@David Schwartz I updated the question with iptables -L output – glagolig – 2014-02-22T01:19:29.277