GCP SSL firewall rules - google-cloud-platform

RESOLVED: See comments
I am trying to enable SSL from outside the GCP network and have temporarily edited the HTTPS rule to allow all networks and I have applied it to all instances in the network.
However, when I try to telnet (to a Linux VM) from my laptop on 443 it still fails (I can do it on port 22) and on port testing web pages it says the port is closed. what am I missing to implement the rule correctly?
default-allow-https ingress 1000 0.0.0.0/0 allow tcp:443
default-allow-ssh ingress 65534 0.0.0.0/0 allow tcp:22
I've also got the default http, icmp, internal and rdp rules.

Related

Accessing EC2 Instance via Internet Security Rules

I have configured an EC2 instance and I am now trying to install an open source app (Wiki.js). One of the steps (visible here under configuration) requires me to navigate to http://localhost:3000/ but replace localhost with the IP address of my server. I have tried this multiple times and tried different variations of security groups for the EC2 Instance but nothing seems to work. Currently the inbound rules are set to the following:
1)
Type: HTTP
Protocol: TCP
Port Range: 80
Source: 0.0.0.0/0
2)
Type: HTTPS
Protocol: TCP
Port Range: 443
Source: 0.0.0.0/0
3)
Type: SSH
Protocol: TCP
Port Range: 22
Source: 0.0.0.0/0
I'm not sure what the problem could be. Are these security settings wrong? Am I using the wrong IP address? I am coping the address directly from the console under Iv4 Public IP.
EDIT:
Could it have something to do with the route table or subnet? If so it doesn't appear to be possible to edit those via the console. Would I need create a new instance?
Why don't you open port 3000 for the EC2 instance ?
I think the application requires you to access port 3000. But you don't configure that security group.

Fail to open ports on AWS using security groups

Here is my security group attached with EC2 instance :
Aws Security Group
If I launch a service listening on port 80, 8080, 8888 it's working, but fail on 9000, 9042, 9999.
I don't find any documentation with this limitation.
Any ideas ?
Remove existing rule and add below rules to your security group to make it working.(Provided your application is properly serving in these ports)
Rule 1: TCP , 9000, 0.0.0.0/0
Rule 2: TCP , 9042, 0.0.0.0/0
Rule 3: TCP , 9999, 0.0.0.0/0
Possible solution
I am presuming the source is your ip/the ip of your company.
You should always set your security group to be as specific as possible.
In this case you should have the following inbound rules:
8.8.8.8/32 is placeholder for your ip
TCP 80 8.8.8.8/32
TCP 8080 8.8.8.8/32
TCP 8888 8.8.8.8/32
TCP 9000 8.8.8.8/32
TCP 9042 8.8.8.8/32
TCP 9999 8.8.8.8/32
Make sure the instance/application is listening on the needed ports etc.
Also make sure the application(s) on 9000,9042,9999 are not trying to reach anything upon receiving a request and are unable to (either because of sg outbound limitations or connection issues). Try determining what goes wrong based on the error you get when trying to connect (based on ports I am assuming http traffic).
Clarification on your question
There are (as far as i can tell) no limitations on sg's in the context you give. I use groups with the same rule and groups with 20 rules without issues.
There are limitation on the amount of groups and/or rules.

EC2 - accessing instance without elastic IP

Since I don't need to reserve an IP address with Elastic IP (I'm testing for now), I'm just using the Public IP randomly assigned at every startup.
After setting up a game server via SSH and opening the related ports on the Security Group, said server is not reachable.
Testing further I've noticed that the instance is not even answering ping request (yes, I've added relative rules in the Security Group).
So the instance is working only on port 22, can anyone explain why?
Here are the Security Group rules:
Ports Protocol Source
0--1 icmp 0.0.0.0/0, ::/0
22 tcp 0.0.0.0/0, ::/0
7787-7788 udp 0.0.0.0/0, ::/0
27166 tcp 0.0.0.0/0, ::/0
27165-27166 udp 0.0.0.0/0, ::/0
EDIT2 adding ACL inbound rules:
Rule # Type Protocol Port Range Source Allow / Deny
100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
If you are able to SSH to the instance, then the problem is not related to the network configuration.
The NACL configuration you show permits all traffic.
That leaves the instance as the guilty party, so you should concentrate your efforts on-instance rather than elsewhere.
So i found what was wrong: the icmp rule I was setting inbound was for icmp echo reply, i had to use icmp echo request, it took me 8 hours to realize it. no need to configure iptaples, ACL or else.
I'm sorry for the useless thread!

Can't connect to Amazon AWS EC2 with Hansoft Client

I'm trying to connect to my Hansoft server on my AWS server that is running Windows Server.
I've tried opening all inbound traffic to test, but that hasn't worked. I'm able to ping the server so it's there.
Hansoft servers use default port 50256.
What else could I try?
Launch-wizard-1 security group settings below.
Inbound Security rules:
All Traffic, All protocols, All port range, Source 0.0.0.0/0
RDP, TCP Protocol, Port range 3389, Source 0.0.0.0/0
All ICMP, All protocols, Port range N/A, Source 0.0.0.0/0
Outbound Security rules:
All Traffic, All protocols, All port range, Source 0.0.0.0/0
Try the following:
Are you sure 100% the service is running?
While logged into the instance, can you 'telnet localhost 50256' and get a connection? Have you tested it locally and confirms it works?
Disable your local firewall and anti-virus.
Have you checked the local Windows Firewall on that server? That will block you in some configurations, so you need to check that. You may need a new inbound rule there.

deploying flask app to EC2

I installed flask on my AWS EC2 machine.
now, from a local machine, the website is supposed to load with localhost and port 5000 but it is not working similarly with http::5000
I tried to add a rule in Security groups as : All TCP, 0.0.0.0/0 -- I am not sure how to allow in-bound traffic to this box.
any help will be appreciated.
Thanks !
I had trouble with this. Until I tried adding an inbound custom tcp rule to my security group associated with the running instance.
Something like:
Custom TCP Rule, Protocol: TCP, Port Range: 5000, Source: 0.0.0.0/0
Custom TCP Rule, Protocol: TCP, Port Range: 5000, Source: ::/0