Apr 08 2022 09:11 AM
Hi,
we establish S2S VPN connection between our environment in Azure and on-premises with our customer.
On Azure we create a new vnet with address space 10.10.0.0/16. That network has:
- GatewaySubnet (10.10.0.0/27)
- environmentSubnet (10.10.8.0/21 > 10.10.8.1-10.10.15.254)
Then we have Azure Kubernetes cluster (2 nodes) and internal loadbalancer (with static IP) for services inside k8s cluster.
So each service has its own IP address from subnet environmentSubnet (10.10.8.0/24). For example:
- kubernetesService01: 10.10.15.5 (port 8080)
- kubernetesService03: 10.10.15.6 (port 8080)
- kubernetesService04: 10.10.15.7 (port 8080)
We can access all on-prmeises services from Azure - through VPN tunnel. The problem is in the opposite direction.
From the on-premises to the Azure they can ping all the Kubernetes endpoints of service, they can ping Kubernetes infrastructure (both scale-sets/nodes), testing VM (which is in the same network like Kubernetes cluster) etc.
But they can't reach our services inside Kubernetes, for example kubernetesService01/kubernetesService02/kubernetesService03 by specific port. So if they run telnet/curl on 10.10.15.5:8080, they dont get any response.
We also configured NSG for Virtual machine scale set with rule - allow everything from everywhere.
We tested connection between testing VM (which is in the same subnet like Kubernetes services, with IP 10.10.8.105) and Kubernetes services and telnet/curl works fine. I suppose that this means that the connection between vnet and Kubernetes services works? Routing form the VM to the service and then to the Kubernete endpoint must work fine.
But for the difference of the Kubernetes services, they can telnet testing VM (telnet 10.10.8.105 22) from on-premises through VPN tunnel.
Any idea what we can check or how we can monitor the traffic coming from the VPN tunnel?
How to find out why they can ping pods within Kubernetes but can't access Kubernetes services on specific ports?
Thank you!
Apr 26 2022 07:36 AM
@KVLEE900I have the same issue as you. Did you find a solution in the meantime to have a working connection between the customer and the internal AKS load balancer/service?