Some google compute engine ports are closed - google-compute-engine

I've been trying to open a port using both the gcloud interface and the UI for Google Compute engine. There are other ports I've opened successfully a while ago, but now nothing new seems to take. According to gcloud describe, my instance has these tags assigned
tags:
items:
- http-server
- https-server
- push-server
- redis-server
- redis-server-prod
and these firewall rules are correctly set both in gc an UI
push-server default 0.0.0.0/0 tcp:3000 push-server
redis-server default 0.0.0.0/0 tcp:6395 redis-server
redis-server-prod default 0.0.0.0/0 tcp:6391 redis-server-prod
Both 6395 and 6391 are open, but 3000 is not. It's nothing specific to 3000, because no other ports work either. I'd appreciate any tips on how to troubleshoot this as I'm completely out of ideas.

After an hour this mysteriously became unblocked. I was using the same port tester each time.
http://www.yougetsignal.com/tools/open-ports/
There must be some kind of delay between setting the firewall and it taking effect.

Related

connect to remote mysql server from google cloud

I have a google cloud machine which has an ubuntu Os, I have MySQL database on another server, I opened the remote connection on my SQL server, and I connect to my database from any machine else from my google cloud machine I can not, it taking long time then I have a timeout connection problem.
I think the problem is from firewall rules, so I applied this command to create rule that allow 3306 port
cloud compute firewall-rules create "mysql-remote-access" --allow tcp:3306 --source-tags "mysql-client" --target-tags "mysql-server"
but still, I can not connect to a remote MySQL server
from where can I enable it, thank you
I think your firewall rules is not correct. This one should solve the issue
gcloud compute firewall-rules create "mysql-remote-access" \
--direction=EGRESS --action=ALLOW --rules=tcp:3306 \
--destination-ranges=xxx.xxx.xxx.xxx/32 --target-tags=mysql-client
Short description: You allow the EGRESS traffic on port 3306 to the destination xxx.xxx.xxx.xxx for the traffic coming from the VM with the tag "mysql-client"
By default all the outgoing communication are allowed, but you might have a rule with higher priority that prevents this
Implied allow egress rule. An egress rule whose action is allow, destination is 0.0.0.0/0, and priority is the lowest possible (65535) lets any instance send traffic to any destination, except for traffic blocked by Google Cloud.
It the rule doesn't work, share all your existing firewall rules.

Nginix crashes while using -SSL Passthrough

I have deployed a nginx ingress controller which works fine when there is no firewall. With the firewall (all egress blocked) the nginx controller seems to be struck. It immediately starts working when the firewall is removed. Not able to find any useful logs on the pod. my ingress config :-
- --default-backend-service=kube-system/nginx-ingress-default-backend
- --election-id=ingress-controller-leader-apps
- --enable-ssl-passthrough
- --ingress-class=nginx-apps
- --configmap=kube-system/nginx-ingress-controller
It's working as designed, when you create a firewall rule blocking all egress connections you are preventing everything that is behind it to talk with the outside world.
To achieve what you want you need to use priority on your firewall rules By using it you can create a rule to allow traffic to specific ports and block everything else.
Here you can find a document describing how to achieve that.

Load Balancer not able to connect with backend

I have deployed the Spring boot app on the OCI compute and its comping up nicely. Compute is created with public ip and have the security list updated to allow connections from internet. But, I wasn't able to hit the end point from internet. For that reason, I thought of configuring the load balancer.
Created load balancer in a separate subnet(10.0.1.0/24), routing table and security list. Configured the LB's security list to send all protocol packets to compute's CIDR(10.0.0.0/24) and configured compute's security list to accept the packets from LB. I was expecting LB to make connection with back end. But, its not.
I am able to hit the LB from internet :-
Lb's routing table with all ips routed through internet gateway. There is no routing defined for compute's CIDR as its in the VCN.
LB has its own security list, which has allowed out going packets to compute and incoming from internet as below:
Compute's security list accepting packet's from LB:
Let me know, if I am missing something here.
My internet gateway :-
My backend set connection configuration from LB:
LB fails to make connection with backend, there seems to be no logging info available :
App is working fine , if I access from the compute node :
The LB has a health check that tests the connection to your service. If it fails, the LB will keep your backend out of rotation and give you the critical health like you're seeing.
You can get to it by looking at the backend set and clicking the Update Health Check button.
Edit:
Ultimately I figured it out, you should run the following commands on your backend:
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
Use the port that you configured your app to listen on.
I used httpd instead of spring, but I also did the following
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -F -R -v /var/www/html
I'm not really too familiar with selinux but you may need to do something similar for your application.
Additionally, setting up a second host in the same subnet to login to and test connecting to the other host will help troubleshooting, since it will verify if your app is accessible at all outside the host that it's on. Once it is, the LB should come up fine.
TL;DR In my case it helped to switch the Security List rules from stateful to stateless on the 2 relevant subnets (where the loadbalancer was hosted and where the backends were located).
In our deployment I had a loadbalancer with public IP located on one subnet, while the backend to this loadbalancer was on another subnet. Both subnets had one ingress and one egress rule - to allow everything (i.e. 0.0.0.0/0 and all ports allowed). The backends were still not reachable from the loadbalancer and the healthchecks were failing.
Even despite the fact that in my case as per the documentation switching between stateful and stateless should not have an effect, it solved my issue.

issue to access multiple applications with IP and port on Google Compute Engine

I am new to Google Cloud. Instance has been created with Ubuntu16.04 image on Compute Engine. Three applications has been installed on it. One is running on nginx on port 80 [say A], second is on 8001[say B] and other one is on 8080 [say C].
I can able to access application A directly when click on external IP [or if give port 80 along with IP]. This application internally access application B on port 8001. Configuration of two applications has been updated for. There is inbound firewall rule for 8001. This application can not be accessible when we try to access with IP and port.
Same case with application C. That application is running on port 8080 in tomcat. Inbound Firewall rule has been created for this port too. This application is not accessible with IP and port. Server.xml for this application is updated to 0.0.0.0 instead of localhost [as mentioned not able to access port(11444 & 5072 ) externally(using Ubuntu on Google compute Engine)
I am not sure about the issue. Can anyone help me out?
I searched around but did not find anything for multiple applications. And most of the time example has given for port 80 only.
This application internally access application B on port 8001
Same case with application C.
It sounds like you don't actually want 8001 or 8080 to be accessible; in this case, leave the firewall rules alone (don't permit traffic to them from the outside) and configure them to listen only on localhost (which is not firewalled anyway).
In case you do want these to be accessible, then post a screenshot of your firewall configuration and we'll take a look.

Google Compute Engine: How can I disable the firewall of VM instance?

I have used firewall rules but I still cannot receive traffic on vm instance. I want to allow http server incoming connection. By default google compute engine does not allow incoming traffic outside the network, so you have to create firewall rules. In google cloud platform documentation it suggests to disable operating system firewall. To disable it I need my user password, which I never created. So what to do now? I need password for my user, I am the creator of vm instance. Any help?
These are my firewall settings:
saad_hussain#saad:~$ gcloud compute firewall-rules list
NAME NETWORK SRC_RANGES RULES SRC_TAGS TARGET_TAGS
default-allow-http default 0.0.0.0/0 tcp:80 http-server
default-allow-https default 0.0.0.0/0 tcp:443 https-server
default-allow-icmp default 0.0.0.0/0 icmp
default-allow-internal default 10.128.0.0/9 tcp:0-65535,udp:0-65535,icmp
default-allow-rdp default 0.0.0.0/0 tcp:3389
default-allow-ssh default 0.0.0.0/0 tcp:22
http default 0.0.0.0/0 tcp:80
https default 0.0.0.0/0 tcp:80
Open Google Cloud Platform and log in.
Click Console at the top-right
Click Computer Engine from the left menu.
Than click VM instances from the left menu.
Click the virtual machine instance's three-dot menu(...) which you want to allow the port connection.
Select "View network details". (Now you can see rules about firewall)
Click "Firewall Rules" from left menu.
Click "CREATE FIREWALL RULE" button at the top of page.
At here you can allow any ip to connect to your vm instance or allow any port to connection. Now you can adjust firewall for vm instance good luck.
Here is some advice to troubleshoot similar issues. Have a look to:
a) Google Firewall. As per the comments and the output provided, port 80 is already opened but will only apply to instances that hold the tag ¨http-server¨.
b) Making sure that a firewall inside the VM is not filtering packets. As also mentioned in the comments most of the public images provided by Google allow the traffic by default.
c) Making sure that the service is not only listening on localhost and it is using an IPv4 address
Using nmap can help to determine if the issue is being caused by a firewall or the server not listening in the appropiate port. The lastest can also be verified using ¨netstat --listen¨