I've created an Oracle Cloud infrastructure compute instance running Ubuntu 20.04. I am trying to open port 19132.
As per another question I found
Opening port 80 on Oracle Cloud Infrastructure Compute node
I've created a public subnet which has an internet gateway and added ingress rules for port 19132 (in the security lists)
netstat looks good
netstat -tulpn
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:19132 0.0.0.0:* 1007/./bedrock_serv
I installed ufw and added rules to allow 19132 but I still can't connect to it from the outside world. Can anyone point out where I am going wrong?
I got the same issue on the Oracle cloud.
Here is what works for me;
First, install firewalld
sudo apt install firewalld
Then open the port in public zone;
sudo firewall-cmd --zone=public --permanent --add-port=19132/tcp
Finally, reload firewalld
sudo firewall-cmd --reload
Looks like you need to have a Public IP configured on that VM for it to be reachable from the internet.
Please look at
https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingpublicIPs.htm
For an instance to communicate directly with the internet, all of the following are required:
The instance must be in a public subnet.
The instance must have a public IP address.
The instance's VCN must have an internet gateway.
The public subnet must have route tables and security lists configured accordingly.
You haven't mentioned anything about the route table. If missing add to it a route with destination=0.0.0.0/0 and target=the Internet Gateway.
Two questions come to mind:
You have specified two rules, one for TCP and one for UDP.
Your netstat shows that something is listening for UDP traffic. Is
there also something listening on TCP or are you using UDP only for
the test?
Can you tell us anything about the traffic characteristics
on this port? I'm asking because if it is UDP traffic the only way
for connection tracking to work is to track the source/dest IP and
port. Since the port will not be present in fragments, the traffic
will be dropped. This could be happening on the ingress or egress
side. To verify, you could create test ingress/egress rules for all
UDP traffic to/from your test IP.
Since your ingress rules are stateful, the egress rules shouldn't matter but it wouldn't hurt to double check them. If none of these things work, you might try a tool like echoping to get more insight into whether or not the traffic is having trouble on the ingress or egress side.
Please check the order of your IPtables rules. Could you post the following command's output for Input chain.
sudo iptables -S INPUT
I have seen Iptables rules as the single prominent reason for these issues.
Regards
Muthu
I think you have to allow user or add user who can connect like this:
create user 'user'#'publicIP' identified by 'password';
grant all privileges on *.* to 'user'#'publicIP' with grant option;
flush privileges;
Here publicIP can be '0.0.0.0' or your system IP address.
Don't use '0.0.0.0' as it is open to all, I have faced various breaches on my GCP machine which leads to account block.
Related
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.
I have a regular MySQL server running with XAMPP at port 3306 and accessible by my internet ip aswell my local ip (127.0.0.1), the ports are forwarded in my router. An account set up to be accessed from any IP, Everything works fine.
I'm trying to make this same server be accessible by AirVPN DNS address. So I've followed AirVPN instructions to remove the forwarded ports in my router and forward a new port at their VPN with a random number (lets go with 1111) with local port as 3306 and DNS named as xxx.airdns.org
So I open MySQL with XAMPP under port 3306, nothing changed in config file. I run the AirVPN port checker over 1111 and it signals as open. I also try at other sites that checks ports and signals open at xxx.airdns.org:1111
Though when I try to make a connection as usual it returns error (10060): Can't connect to MySQL server on 'xxx.airdns.org' (10060)
Resolutions I've tried:
Switch port values in MySQL config files matching with the ports open in AirVPN
bound address to VPN adapter bind-address="10.6.114.48"
repeated the options above in all different kind of port combinations and addresses
Disabled Firewall on Ethernet adapter of VPN as described here
I couldn't achieve success in this task. I'm looking for some enlightment so I can understand the process.
EDIT:
The connection is set only to TCP protocol. A port check done through airVPN and is registered at XAMPP & FIREWALL logs as accepted connections. Though trying to connect from a client I got no log from Xampp or Firewall, it gets timed out.
Sorry for "answer" type not just comment, but i dont have enough reputation here :)
Maybe the protocol ( TCP/UDP ) is your issue.
If you use UDP on your airVPN better check forwarding on your router - most of them
by default sets TCP only. Otherwise maybe change to TCP on your airVPN.
ISP provider often filter this protocol.
Issue: Consider that you can't connect to a service running "behind" some VPN server from a machine that's connected to that very same VPN service.
Solution: Connect from another machine to test your service properly.
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.
I am trying to follow this tutorial. You do not have to read whole tutorial, my small goal is to create firewall rule on Google Compute engine and connect to using telnet.
I did create firewall rule:
But when type telnet X.X.X.X 5901, I get back
Connecting To X.X.X.X...Could not open connection to the host, on port 5901: Connect failed
I replaced actual ip with X.X.X.X in the above.
Any suggestions how I can troubleshoot it?
That should work!
I suspect vncserver isn't running (correctly) on the instance.
Or you're using the internal IP rather than the external IP address.
Did you confirm the server is running before you tried access it remotely? The tutorial suggests:
nc localhost 5901
But, you could also try:
ss --tcp --listening | grep 5901
and should see something similar to
LISTEN 0 5 *:5901
you need to tag the one GCE instance with vnc-server, in order to apply the rule. setting IP ranges to the home network might be tighter than permitting range 0.0.0.0. think one can use Stackdriver to log whenever a firewall rule applies. the host firewall might also prevent the access (eg. when Stackdriver logs, but it still not works).
So I'm hoping someone can give me some insight in my problem.
Been googling, reading blogs/articles, checking the documentation, but can't really figure it out...
So, if I want to deploy Openshift/OKD to a VPS, doesn't matter if it's the all-in-one deployment or not: how do I secure the web console?
I was expecting that it would be possible to e.g. execute an "oc cluster up" with public-master equal to my local-ip or public ip. Then, use iptables to block access to this port publicly and use ssh port forwarding (in putty) to access the webconsole. However, apparently accessing the web-console executes some form of forwarding, which basically makes ssh port forwarding for accessing it fail. I tried with ssh port forwarding by both setting the public master to my localhost ip and my public ip of the vps: same issue, ssh port forwarding doesn't work.
What I definitely do NOT want to do, is just expose the web-console to everyone with just a username and password combination.
So what options are there to actually secure the web console for openshift for public access over the internet?
There are a lot of articles to be found online on how to deploy it, but basically they all just seem to expose the web console publicly to everyone...
had the same problem, that is, ssh port forwarding didn't work due to web-console forwarding and redirects.
Solved it by forwarding to the same port, which seems to work:
ssh -L 8443:localhost:8443 -f -N user#host
Forwarding to different port didn't work:
ssh -L 1443:localhost:8443 -f -N user#host