I tried to set up a network load balancer on google cloud but the heath check always returns unhealthy.
I give you the steps that i did follow
I created two windows servers 2012 R2 instances
I checked that the port 80 is open to public over both instances
I created the forwarding rules and Google Cloud gave me a External IP
I set up the external IP in a Network loopback interface on both server instances
I created a Network Route that forwarding the traffic on both instances (route menu)
I created another Network Route for the 169.254.169.254/32 (Source of Network load balancer traffic) and Pointing to both windows instances server
I created the same site (example.com) on IIS 8 in both instances server and the site is running correctly.
The DNS settings of the domain example.com is pointing to the external IP google cloud that I using for Network load balancer
I configured the health check
PATH : /
Protocol : HTTP
HOST: example.com
Session Afinity : Client IP
I created a Target Pool and I added both server instances and heath check
I Asigned the target pool to forwarding rule
When I select the Target Pool option, both instances marked as Unhealthy for the external IP that Google cloud gave me and I don't know why this happens.
I see the web page is switching the server instances randomly all the time.
Your Help is apreciated!, thank you!
You don't need to add any GCE Network Route.
The GCE agent is taking care of adding the load balancer IP to the VM's network configuration. There is no need to do it manually. https://github.com/GoogleCloudPlatform/compute-image-windows
IIS must respond to requests on the LB IP:
Check the IIS bindings from IIS manager. Reset IIS.
Confirm from netstat that IIS is listening on 0.0.0.0 or the load balanced IP.
Access the LB IP from one of the servers. It should work.
The GCE firewall must allow traffic from the clients' IPs and also from the metadata server (169.254.169.254). The metadata server is used for healthchecks.
Network Load Balancing tutorial. https://cloud.google.com/compute/docs/load-balancing/network/example
Related
We are moving a workflow of our business to Azure. I currently have two VMs as an HA pair behind an internal load balancer in the North Central US Region as my production environment. I have mirrored this architecture in the South Central US Region for disaster recovery purposes. A vendor recommended I place an Azure Traffic Manager in front of the ILBs for automatic failover, but it appears that I cannot spec ILBs as endpoints for ATM. (For clarity, all connections to these ILBs are through VPNs.)
Our current plan is to put the IPs for both ILBs in a custom-built appliance placed on-prem, and the failover would happen on that appliance. However, it would greatly simplify things if we could present a single IP to that appliance, and let the failover happen in Azure instead.
Is there an Azure product or service, or perhaps more appropriate architecture that would allow for a single IP to be presented to the customer, but allow for automatic failover across regions?
It seems that you could configure an application gateway with an internal load balancer (ILB) endpoint. In this case, you will have a private frontend IP configuration for an Application Gateway. The APPGW will be deployed in a dedicated subnet, it will exist on the same VNet with your internal backend VMs. Please note in this case you can directly add the private VMs as the backends instead of internal load balancer frontend IP address because of private APPGW itself is an internal load balancer.
Moreover, APPGW also could configure a public frontend IP configuration, if so, you can configure the APPGW public frontend IP as the endpoints of the Azure traffic manager.
Hope this could help you.
I have created VM instance on google cloud platform in which I have installed NiFi. There are two types of Ip addresses:
1) Internal IP
2) External IP
Now, when I start NiFi services it is hosting its services on Internal IP but when I try to access external IP via local browser I am unable to access it since its a private IP. I tried creating a firewall rule with Ingress option and which will listen to all IP's and port number 8080 but of no use.
So where am I going wrong?? I tried searching for relevant solutions but no luck.
Attaching screenshot of the firewall config:
Please help me with some links / solutions.
Your issue is a misunderstanding of how ip works in google cloud.
You have two types of ip as you stated, internal ip is for communication between the computes instances and services inside the google cloud vpc. The important part is that it works only in google cloud on your project and that is the internal ip of your instance.
External ip is an optional ip that is attributed to the instance to allow external communication, so not from google cloud, as from your browser for example. But this external IP is not really known to your instance, that's what confused you, but don't worry, if you try to access your 8080 port on the external ip you won't have any errors and should see your app.
I solved my problem in below ways:
1) I edited my VM and unchecked allow https traffic option.
2) I changed my NiFi listener port from 8080 to 80 since 8080 is blocked in my organization.
No firewalls added. Atleast it worked for me
I have a single ec2 instance running a website behind an elastic load balancer in aws. Mainly because I want to use Amazon's new and free ssl for https.
my challenge is, I need to whitelist my IP address in the security groups so that I am the only person that can see this website (and I can selectively add people as needed).
I've successfully whitelisted my IP address without a load balancer. my challenge is white listing my IP address with the load balancer proxy between my IP address and my ec2 instance.
it appears as if my ec2 instance will not register with the load balancer because the security group for my ec2 does not allow incoming traffic from any IP address except for my own.
I am looking for a way for my load balancer to be able to health check my ec2, yet only allow specific whitelisted ips actually see the website.
If you are using a VPC (which you really should be) then you will have a Security Group attached to the load balancer. That's where you will whitelist IP addresses. The EC2 server just needs to whitelist the Load Balancer's security group.
You can visualize it like this:
Your IP -> Security Group 1 -> Load Balancer -> Security Group 2 -> EC2 Instance(s)
Security Group 1 verifies the IP address is on the whitelist, and allows the traffic through to the load balancer. The Load Balancer sends the traffic along to one of the instances in the pool. Security Group 2 verifies that the traffic is coming from something that belongs to Security Group 1 (the load balancer), which has been whitelisted, and allows it to pass through to the EC2 instance.
I was able to solve the issue, by changing the security group of the EC2 to allow incoming http connections on port 80 from the security group assigned to my load balancer.
and then my load balancer itself allows incoming HTTP traffic on port 80 from anywhere.
so I guess the trick here is, you can allow incoming connections from an IP or a security group.
I'm unable to join an EC2 instance to my Directory Services Simple AD in Amazon Web Services manually, per Amazon's documentation.
I have a Security Group attached to my instance which allows HTTP and RDP only from my IP address.
I'm entering the FQDN foo.bar.com.
I've verified that the Simple AD and the EC2 instance are in the same (public, for the moment) subnet.
DNS appears to be working (because tracert to my IP gives my company's domain name).
I cannot tracert to the Simple AD's IP address (it doesn't even hit the first hop)
I cannot tracert to anything on the Internets (same as above).
arp -a shows the IP of the Simple AD, so it appears my instance has received traffic from the Simple AD.
This is the error message I'm receiving:
The following error occurred when DNS was queried for the service
location (SRV) resource record used to locate an Active Directory
Domain Controller (AD DC) for domain "aws.bar.com":
The error was: "This operation returned because the timeout period
expired." (error code 0x000005B4 ERROR_TIMEOUT)
The query was for the SRV record for _ldap._tcp.dc._msdcs.aws.bar.com
The DNS servers used by this computer for name resolution are not
responding. This computer is configured to use DNS servers with the
following IP addresses:
10.0.1.34
Verify that this computer is connected to the network, that these are
the correct DNS server IP addresses, and that at least one of the DNS
servers is running.
The problem is the Security Group rules as currently constructed are blocking the AD traffic. Here's the key concepts:
Security Groups are whitelists, so any traffic that's not explicitly allowed is disallowed.
Security Groups are attached to each EC2 instance. Think of Security Group membership like having a copy of an identical firewall in front of each node in the group. (In contrast, Network ACLs are attached to subnets. With a Network ACL you would not have to specify allowing traffic within the subnet because traffic within the subnet does not cross the Network ACL.)
Add a rule to your Security Group which allows all traffic to flow within the subnet's CIDR block and that will fix the problem.
The question marked as the answer is incorrect.
Both of my AWS EC2 instances are in same VPC, same subnet, with same security group.
I have the same issue. Here are my inbound rules on my security group:
Here is the outbound rules:
I can also ping from the between the dc and the other host, bi-directional with replies on both side.
I also have the DC IP address set as the primary and only DNS server on the other EC2 instance.
AWS has some weird sorcery preventing a secondary EC2 instance from joining the EC2 domain controller, unless using their managed AD services which I am NOT using.
The other EC2 instance has the DC IP address set as primary DNS. And bundled with the fact I can ping each host from each other, I should have ZERO problems joining to domain.
I had a very similar problem, where at first LDAP over UDP (and before that, DNS) was failing to connect, even though the port tests were fine, resulting in the same kind of error (in network traces, communication between standalone server EC2 instance and the DC instance stopped at "CLDAP 201 searchRequest(4) "" baseObject", with nothing being returned). Did all sorts of building and rebuilding, only to find out that I was inadvertently blocking UDP traffic, which AWS needs for both LDAP and DNS. I had allowed TCP only, and the "All Open" test SG I was using was also TCP only.
D'oh!!!
I have tried everything, I can get to my application using the ec2-x-x-x-x.compute-1.amazonaws.com, I cannot ping the address.
However, when I do ping the amazon DNS, it identifies with the IP address of but does not respond to ping.
When I put the IP address in the browser, it times out and gives me the Chrome "Oops", I have went through the Security vgroup several times.
I have checked the server, including the IPtables and the ports that Apache is listening to.
I don't have a lot of knowledge in this area, But I tried everything in the forum and more.
I even created another Elastic IP and associated it with the instance.
Please help.
By default, you cannot ping an EC2 instance, since it is blocked by the firewall (see why can't I ping my instance):
Ping uses ICMP ECHO, which by default is blocked by your firewall.
You'll need to grant ICMP access to your instances by updating the
firewall restrictions that are tied to your security group.
ec2-authorize default -P icmp -t -1:-1 -s 0.0.0.0/0
Check out the latest developer guide for details.
Section: Instance Addressing and Network Security -> Network Security
-> Examples
As for HTTP requests - your instance is available and looks fine (I suggest you remove the real DNS name from your post though)...
For ec2 best options is
1) open port 5060 and 10000-20000 udp on firewall(security group)
2) order and attach elastic IP.
3) in sip.conf add
externhost=elastic_ip_her
localnet=10.0.0.0/255.0.0.0
Every time you start/stop that instance attach same elastic IP.
For web access you also need open port 80 in security group