Questions tagged with Gateway Load Balancer
Content language: English
Sort by most recent
Browse through the questions and answers listed below or filter and sort to narrow down your results.
Hello, we have a setup of Gateway Load Balancer fronting a couple of firewall appliances in a central VPC to inspect all the traffic from all the spoke VPCs as well as several on-prem remote locations connected through S2S VPN.
We have noticed that some clients are not able to reach Microsoft Office365 endpoint https://www.office.com which resolves to (13.107.6.156)
Also we have checked and our clients are able to reach resources in spoke VPCs though and no issues on that.
We have consulted our firewall vendor and they have confirmed that the firewall can see the packets egressing to the internet and not being blocked.
In an effort to comprehend the cause of this, we have turned on VPC flow logs, however, we couldn't establish a relation between the clients that are able to reach Office365 and the ones that are not.
Our setup is:
Remote Offices <....> S2S VPN <....> Transit Gateway <....> Gateway Load Balancer <....> Firewalls <....> Internet
On a side note, we had a similar issue in the past for some random clients in the spoke VPCs but that was resolved by enabling Transit Gateway Appliance mode. We are not sure though if it's related to the current issue or not as we tried disabling it again but that didn't change anything.
Any hint would be appreciated.
I'm writing a custom config rule to determine if there's an network firewall in the VPC. In order to confirm it's being used I was informed I needed to check the route tables.
There's one issue I'm having. When I make a describe_route_tables call it returns the Routes, in the routes it has the "GatewayId:": "Vpce-<number>). The Vpce-<number> is my network firewall attached as a vpcendpoitn in the route table. Indicating that the route is going to my vpcendpoint/network firewall, which is good.
However, it doesn't actually indicate this is a network firewall. If the config rule checks and confirms there's a network firewall in the VPC, it then goes on to check that the network firewall is being used, this could potential return a false positive. In the case where a Network Firewall is attached to the VPC and then there's another endpoint that is NOT a network firewall that also has the prefix vpce.
Is there a way to identify the vpce(network firewall) by the actual eni? Opposed to gateway id? I was thinking if I can call a describe_vpc_endpoints and then return the vpc endpoint Id and see if that matches the gateway id. I'm not sure if this is an option.
Is there any solutions anyone has in mind for this problem?
I have the following scenario:
1 Security VPC and 1 Transit Gateway. Inside the security VPC, there are 3 AZs and 1 Gateway Load Balancer. In each AZ there is an endpoint GWLBE to redirect the traffic to the GWLB. The transit gateway attachment is configured in appliance mode. The target group of the load balancer has 3 instances: 1 VM series Palo Alto NGFW and 2 Linux machines to simulate unhealthy VM machines in each one of the AZs. The Palo Alto machine responds to the TCP 80 probes, while the other Linux machines time-out.
The target group is configured with the new failover feature to redirect existing flows to healthy instances.
Testing:
I am doing pings between 2 machines in 2 different VPCs. (I have also tested ssh traffic). I have found out that I have to send 2 to 4 times the ping command for the target machine to respond. After checking the flow logs, I found that the GWLB sends traffic to machines that are unhealthy, thus I only get the pings responses only when the GWLB send the traffic to the healthy Palo Alto.
Why is the TG sending traffic to unhealthy machines?
Hello,
ELB team is happy to announce that we just launched a new Target Failover feature that provides an option to define flow handling behavior for AWS Gateway Load Balancer. Using this option, customers can now rebalance existing flows to a healthy target, when the target fails or deregisters. This helps reduce failover time when a target becomes unhealthy, and also allows customers to gracefully patch or upgrade the appliances during maintenance windows.
Launch Details:
* This feature uses the existing ELB API/Console and provides new attributes to specify the flow handling behavior. You can use the existing modify-target-group-attributes API to define flow handling behavior using the two new attributes target_failover.on_unhealthy and target_failover.on_deregistration.
* This feature does not change the default behavior and existing GWLBs are not affected.
* The feature is available using API and AWS Console.
* The feature is available in all commercial, GovCloud, and China regions. It will be deployed in ADC regions at a later date based on demand.
* Customers should evaluate the effect of enabling this feature on availability and check with their third-party appliance provider documentation.
* AWS appliance partners should consider taking following actions - (a) Partners should validate whether rebalancing existing flows to healthy target has implications on their appliance as it will start receiving the flow midway, i.e. without getting the TCP SYN. (b) Update public documentation on how this feature will affect their appliance. (c) Partner may use this capability to improve stateful flow handling on their appliances.
Launch Materials:
* Launch Blog - https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-target-failover-for-existing-flows/
* Feature Documentation - https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/target-groups.html#target-failover
* Attribute Documentation - https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/target-groups.html#target-group-attributes
Thank you!
I am trying to enable the applicance mode with the following CLI command as per the online documentation:
C:\Users\Pablo>aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-0b6cb80499a53XXXX --options ApplianceModeSupport=enable
Parameter validation failed:
Unknown parameter in Options: "ApplianceModeSupport", must be one of: DnsSupport, Ipv6Support
I tried changing the DnsSupport option to make sure I'm in the right region and transit gateway attach and works:
C:\Users\Pablo>aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-0b6cb80499a5383e9 --options DnsSupport=disable
{
"TransitGatewayVpcAttachment": {
"TransitGatewayAttachmentId": "tgw-attach-0b6cb80499a53XXXX",
"TransitGatewayId": "tgw-01e5ee317cd46YYY3",
"VpcId": "vpc-02e3c21f4d7dacZZZ",
"VpcOwnerId": "95107885XXXX",
"State": "modifying",
"SubnetIds": [
"subnet-0c24bb7aae4deeXXX",
"subnet-064acc2ad5667aXXX",
"subnet-03b6351363cd1cXXX"
],
"CreationTime": "2022-09-27T18:09:59+00:00",
"Options": {
"DnsSupport": "disable",
"Ipv6Support": "disable"
}
}
}
It looks like this transit gateway attachment does not have this option. What am I doing wrong?
Amazon Web Services (AWS) Gateway Load Balancer (GWLB) is a new member of Elastic Load Balancing (ELB) product suite to help you easily deploy, scale, and manage your third-party virtual appliances. GWLB now supports configurable flow stickiness, enabling you to configure the hashing used to maintain stickiness of flows to a specific target appliance. You can modify the target group of your GWLB to maintain stickiness of flows using 3-tuple (source IP, destination IP, transport protocol) or 2-tuple (source IP, destination IP) in addition to the default method of 5-tuple. The configuration applies to all traffic using the target group.
The configurable flow stickiness is intended for customers who need to support applications, such as IDS/IPS that identify flows using 3- or 2-tuple, or applications, such as FTP, Microsoft RDP, Windows RPC, and SSL VPN that use separate streams or dynamic port numbers but require to map all traffic from the same client to the same target, using GWLB. The configuration applies to all traffic using the same target group and requires you to drain existing flows to avoid disruption. Configurable flow stickiness doesn’t work if you are using GWLB with transit gateway (TGW) and TGW Appliance Mode is enabled. Please visit Gateway Load Balancer Documentation (https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/target-groups.html#flow-stickiness) to learn more.
asked 7 months ago
What configuration are needed on the security appliance(lets say using Palo Alto) while using GWLB(Gateway Load Balancer)? Obviously we will configure zone, policy associated with zone. What about routing? Will the appliance pass the traffic to GWLB --> GWLBe without any routing entries on the security appliance("Palo Alto") (or) any any routing entries required. If routing entries requires, which IP should be the next hop ip on the security appliance?
Hi,
I understand from [this article](https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/) that GWLB supports overlapping CIDRs through the GENEVE protocol. However, does this also work with TGW?
Thanks
I am creating a CDK app to deploy a NGFW behind a GWLB with all of the routing in place. When I launch the cdk app, the VPCEndpoints always fail to create if I register the EC2 Instance (NGFW) in same template. I've tried to add dependson conditions but nothing seems to happen. Simply including the instance targets causes the VPC endpoints to fail.
This config does not impact the vpce creation
```
gwlbtarget:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
HealthCheckPort: "443"
HealthCheckProtocol: TCP
Name: gwlb-targetgroup
Port: 6081
Protocol: GENEVE
VpcId:
Ref: firewallvpc63A6EE9C
Metadata:
aws:cdk:path: GwlbExampleStack/gwlb-target
```
This causes vpce endpoint to fail with error: "VPC Endpoint vpce-xxxxx did not stabilize. Current state: failed"
```
gwlbtarget:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
HealthCheckPort: "443"
HealthCheckProtocol: TCP
Name: gwlb-targetgroup
Port: 6081
Protocol: GENEVE
Targets:
- Id:
Ref: ngfw
VpcId:
Ref: firewallvpc63A6EE9C
Metadata:
aws:cdk:path: GwlbFirewallStack/gwlb-target
I have some questions about the "AWS Application Load Balancer" in regard to http2 persistent connections:
Does the "AWS Application Load Balancer" itself maintain its own internal http2-connection-pool? (or nah?)
If the load balancer does indeed maintain its own http2-connection-pool for persistent http2 connections I have these follow-up questions:
1. I can't find anything in the AWS docs explaining how the size(s) of the http2-connection-pools (maintained by ALB) are configured (if at all).
Can it maintain for example 2 million http2 connections open at the same time (for the sake of ultra low latency). At what cost (are there scaling costs)? Any links that elaborate on these aspects?
2. Does the ALB, by default, maintain a fixed-size http2-connection-pool between itself and the browsers (clients) or are these connection-pools dynamically sized? If they are fixed-size how big are they by default? If they are dynamic what rules govern their expansion/contraction and what's the max amount of persistent http2-connections that they can hold? 30k? 40k? 5million?
3. Let's assume we have 20k http2-clients that run single-page-applications (SPAs) with sessions lasting up to 30mins. These clients need to enjoy ultra-low latency for their semi-frequent http2-requests through AWS ALB (say 1 request per 4secs which translates to about 5k requests/second landing on the ALB):Does it make sense to configure the ALB to have a hefty http2-connection-pool so as to ensure that all these 20k http2-connections from our clients will indeed be kept alive throughout the lifetime of the client-session?Reasoning: In this way no http2-connection will be closed and reopened (guarantees lower jitter because reestablishing a new http2-connection involves some extra latency - at least that's my intuition about this and I'd be happy to stand corrected if I miss something)
Hello AWS,
I have a custom domain (registered via Route53) and created API Gateway resources for this custom domain yesterday.
After deleting ALL (!!!) API Gateway resources and even doing an "aws-nuke" on my account, I still have API Gateway load balancers associated with my ACM certificate.
The ARNs for the load balancer resources look like this: "arn:aws:elasticloadbalancing:eu-central-1:<some-aws-account-id>:loadbalancer/app/prod-fra-1-az1-1-31/<some-mores-stuff>"
This is annoying as I cannot delete the certificate as long as these association hold.
Can anybody help me with this?
Best,
David