Firstly, apologies if similar questions have been answered before, but the Azure configuration seems to have changes since most of the posts I have seen so far.
I have an application which I have installed on an Azure VM [Windows server 2012].
It's actually wso2 API manager, if anybody has experience of that.
The application fires up Tomcat and listens for SSL traffic on port 9443. Why it's not 443 I'm not sure.
I've set up an Inbound Security rule on my Network Security Group, as follows:
Priority : 1010
Source: Any
Service: Custom
Protocol: Any
Port Range: 9443
Action : Allow
I still have no joy accessing this from a browser though, I get the slightly confusing "This site can't be reached / the connection was reset" error.
I'd welcome any pointers to get this working or to debug!
I recently experienced nearly the same issue that you did. What worked for me:
1) I added my inbound rule prior to any other inbound rule. I noticed your rule is 1010 which means it's being applied after the default RDP rule is. No, this shouldn't make a difference, but it may.
2) When you create your inbound rule, hit the "advanced" button, choose the CIDR option and route the traffic to the internal IP address of the VM.
3) For the destination port range I chose only the port I needed. In your case 9443.
The issue for me was the internal IP address. Once I set that everything started working for me.
Related
does anyone know what i'm doing wrong here? i'm trying to access my windows-server 2019 ec2 node locally so i can successful collect metrics via WMI Exporter and point this at my prometheus instance.I'm trying to access port 9182 for WMI Exporter, and can connect fine via localhost on my remote widows instance, also the IPv4 Address on the same instance.I've also tried to configure the firewall port on the windows host 9182. When I try to access via localhost this returns This site can’t be reached, if i try via public address on both i get Can’t reach this page. Ive opened port 3389 inbound and all traffic ipv4 outbound. Any help would be great. I have also tried adding RDP Ip directly to the inbound security rules, yet still have the same issue. Many Thanks
After installing windows_exporter, the installer will create an inbound rule for windows_exporter itself. However it may be not enough and cause your issue for some reasons. See this similar issue.
Try to add a new inbound rule for the Windows firewall and let any programs can access the listening port (default 9182). That works for me.
We have an EC2 instance on AWS which we deployed our backend services to. We started by using Google Spreadsheets (scripted with Google Apps Script) to present our backend, through a webservice deployed on our server. We have a specific port from which https (uses a self-signed certifiate) protocol is used to serve the webservice encrypted while on flight. We had set up Security Groups (basically a firewall entry group) which include following CIDR ranges for that specific ingress port of our webservice:
64.18.0.0/20
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
173.194.0.0/16
207.126.144.0/20
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19
as described in https://developers.google.com/apps-script/guides/jdbc#setup_for_google_cloud_sql
This setup was working fine until 5 days ago. Then something weird happened. When we run the script behind the spreadsheet from 'Script Editor' code
works fine and requests to our webservice return successfully. But when the exact same code was invoked through a menu item, it was not doing anything. After long frustrating investigation we found out that request was not even reaching our server (there were numerous other quirky symptoms like only last log command was visible on 'Execution Transcript' even though there should have been many others). Then we tried replacing the security group with a rule that accepts from any ip but to specific port everything was working fine again.
Here is a link to seemingly relevant issue in google-apps-script-issues page:
https://code.google.com/p/google-apps-script-issues/issues/detail?id=4679#c8
We ran tcpdump tcp port <port> -i eth0 -vv and observed that when we run the code from 'Script Editor' request was made from 66.102.7.156 (and from similar ips, which are in 66.102.0.0/20), when code is invoked from menu item in spreadsheet the request was made from 72.14.199.55 (and from similar ips, which are in 72.14.192.0/18). This one seems to be the problematic ip range.
My question is, why is it the case that when request sources are correctly included in firewall rules one block of ips don't work and starts to work when ip restriction on the port is lifted (source ip 0.0.0.0/0)? Is it a bug of Security Groups in AWS? Or are we doing something wrong? Also if our approach is not adequate in any way, alternative solutions or suggestions would be much appreciated.
As per the issues you linked to, there was a bug in Apps Script that lead to this behavior. That bug has now been fixed.
So, I am using CloudFlare at the moment for my DNS records. I have my team speak server A-Record at ts.servername.net and pointing to my ip 100.100.100.100, and all my other A-Records are pointing to exactly where they should be and activated.
They were working previously but all of a sudden for the last week or so, we have had to use our IPv4 ts server ip in order to connect instead of our server name, why is it doing this even though everything is setup and was already working?
I would recommend opening a support ticket with specific details & we can help.
Please note that we can only proxy web traffic records going over certain ports like 80 and 443.
I am using IPsec to block all protocoles traffic, and allow some ports.
I want to allow Web Browsing while blocking all of the other traffic.
I tried to add rule to allow the 80 port , port 53 as source and destination port through UDP and TCP protocoles, but still in the browser have a DNS error.
Please can you help me?
I don't know IPsec, but in general you cannot limit the source ports. The source ports will be random, and will not likely be 53 or 80. You should limit only the destination ports (80, 53).
The way IPSec works is that all 'block' rules take priority over 'allow' rules. If we ignore the fact you're not using the recommended methods to do what you want to do, you've not configured IPSec properly.
Unfortunately, using this method will be horrible, since you'll have to configure filters to block everything except HTTP, and there's no way of specifying 'everything except something'. I went down this road briefly a few weeks ago, made the same mistake you did, and aborted the whole plan!
I know this is an old question, but it would good to follow it up with the solution you found.
In Windows Azure role, I cannot ping out
D:\Users\foglight>ping www.google.com
Pinging www.l.google.com [209.85.143.104] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 209.85.143.104:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I google it and found some one suggest run below command, but even after run it, I still can not ping out
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
Please someone tell me the reason and how to walkaround.
I don't believe you can do this. Traffic leaving the data center goes through the load balancer, and the load balancer only routes TCP-based traffic.
I know this question is very old, but I stumbled upon it while facing the same issue and there is an actual solution for it now in Azure.
When setting up your Virtual machine you can assign it an "Instance IP address". Once that has been configured, you can enabled ICMP in and out in the local firewall. You will then be able to ping out of your Azure VM and also use tools like traceroute.
I had a similar problem. Needed to assign public IP to Azure VM in order to enable ICMP. I used set-azurepublicip and update-azurevm and resolved the issue.
I also had problems to do traceroutes from my azure VM and to ping it.
Just wanted to let you know, that after you have a public IP assigned to the VM (which is in many cases the default), you also need to add ICMP Rules to your network security groups (NSG) (if you have any, which you should).
If you have a NSG on the vnet and a NSG on the VM network interface, you should create 4 rules that allow ICMP (vnet-in, vnet-out, vm-in, vm-out).
Selecting "Any" as protocol, will not work.
The default rule for internet access seems to be not sufficient.
You need to select ICMP. "Any" seems to be only UDP+TCP.
I set the source and destination port to "*" (not sure if it even has any effect if ICMP is selected).
After that and a little wait (~1-2 min), I could ping and trace in every direction :)