By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Network Load Balancer (NLB) doesn't accept on-prem client requests (vpn site-to-site)

0

Dear all,

I connected on-prem LANs to a VPC using an EC2 istance that operates as VPN gateway (I'm not using AWS VPN site-to-site service).

I enabled and configured a Network Load Balancer instance (internal type), but NLB listener doesn't reply to clients request from on-prem lans. I soppose due to an NLB routing issue or due to NLB security policies.

DNS resolution works good, it resolves NLB private IPs.

Is this expected behavior? If yes, is there a workaround to solve my issue?

thanks in advance. Andrea

  • Hrushi_G EXPERT
    2 years ago

    did you check security group configuration to allow on-premises IP on the NLB's target group instances?

  • Assice
    2 years ago

    That's the solution! Many thanks. I hadn't really thought about enabling the client IPs on the backend instances (target groups), because I thought the connection would come with the IP address of the NLB instance. But how does it work that way? Maybe security group checks and it's able to verify proxy protocol attributes?

  • Steve Kinsman EXPERT
    2 years ago

    NLB preserves Source IP (except for IP Address targets), whereas servers behind CLB & ALB see load balancer IPs as Source IPs in client requests and rely on x-forwarded-for header to indicate true source.

Topics
Networking & Content Delivery
Tags
Network Load BalancerAWS Virtual Private Network (VPN)
Language
English
Assice
asked 2 years ago1.1K views
1 Answer
0

I guess you want the NLB because you're intending to have more than one EC2 instance running your Software VPN in the future?

I'm not sure why that wouldn't work, but the options I've seen for managing horizontal scaling / load balancing don't include NLB:

  • A simplistic method is to put 2 routes in your VPC route table so traffic targeting the bottom half of the on-prem network goes to one EC2 instance, and top half to the other.
  • Or base it on source - have different route table entries in different subnets where some route to one EC2 instance and some the other.
  • But more even distribution with less management can be done by recognising that it's the encrypt/decrypt that's limiting, not routing processing. So decouple the two, with multiple instances running tunnels, front-ended in the VPC by a single instance that route tables target. The front-end will need to do stateful "sticky" load-balancing. Or, with more setup, GRE tunnels between front and back ends.
EXPERT
Steve Kinsman
answered 2 years ago
  • Assice
    2 years ago

    We chose NLB to expose and manage both HTTP and TCP/UDP backend applications hosted by an EKS cluster.

    On-prem corporate users reach the NLB cluster through a vpn site-to-site. Connections follow that chain:

    users->vpn_site_to_site->nlb->reverse_proxy->application

    both reverse proxy and backend application reside within the EKS cluster.

    The issue is that NLB doesn't answer to client requests (TCP SYN timeout) I suppose because source IPs are not part of VPC IP addressing.

    I workarounded the issue source-natting client requests on VPN gateway (at AWS side), but I'd rather use a cleaner solution.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content