Hello
I have a COAP client that sends a request to an AWS NLB, which then forwards the request to a COAP server by target group of type IP.
The server sends a response back to the client via a NAT Gateway, but the client is not receiving the response.
-
I have confirmed from logs that the COAP server is receiving the request and sending the response back to the correct IP address and port number. I have also verified that the NAT Gateway is configured correctly and that it is forwarding the response back to the client.
-
I have checked the security group settings for the NLB, UDP server, and NAT Gateway, and they all appear to be correct. I have also checked the network ACL settings and made sure that they are not blocking any traffic.
-
I have checked the COAP client, and see that he receives response when the server is hosted in my laptop.
-
I need to use the NAT gateway because I have to make some request from server to the internet
Details :
Assuming that the IP addresses are :
Coap client :
public : 123.123.123.123
NLB :
private : 1.1.1.1
ec2 Instance were server is running :
private : 2.2.2.2
Nat gateway :
private : 3.3.3.3
Logs in coap server when sending health request :
CoapAssistanceResource - health request , exchange.getSourceAddress() is : /123.123.123.123
CoapAssistanceResource - health request , exchange.getSourceSocketAddress() is : /123.123.123.123:40945
CoapAssistanceResource - health request , exchange.getSourcePort() is : 40945
CoapAssistanceResource - health request , exchange.getRequestCode() is : GET
CoapAssistanceResource - health request , response is : 2.03
Vpc flow logs with are :
${dstaddr} | ${dstport} | ${srcaddr} | ${srcport} | ${protocol} | ${action} | ${log-status} | ${type} | ${pkt-dstaddr} | ${pkt-srcaddr} | ${flow-direction} | ${traffic-path} |
---|
2.2.2.2 | 5683 | 123.123.123.123 | 40945 | 17 | ACCEPT | OK | IPv4 | 2.2.2.2 | 123.123.123.123 | ingress | - |
123.123.123.123 | 40945 | 2.2.2.2 | 5683 | 17 | ACCEPT | OK | IPv4 | 123.123.123.123 | 2.2.2.2 | egress | 1 |
1.1.1.1 | 5683 | 123.123.123.123 | 40945 | 17 | ACCEPT | OK | IPv4 | 1.1.1.1 | 123.123.123.123 | ingress | - |
123.123.123.123 | 40945 | 3.3.3.3 | 43099 | 17 | ACCEPT | OK | IPv4 | 123.123.123.123 | 3.3.3.3 | egress | 8 |
I am not sure what else to check or how to troubleshoot this issue further. Any help or guidance would be greatly appreciated.
Thank you!
Thanks for the answer. I verified the client network, he accept all UDP inbound packets. About the ports, they are the same ( client port inbound = client port outbound ). In VPC flow logs, we only have the requests below logged : client -> nlb nlb -> server client -> server server -> nat gateway nat gateway -> client
I don't see a request : nat gateway -> internet gateway
Maybe the client didn't recognize the response to the the request he made to server, because its coming from a nat gateway. I'm using the NAT gateway because I have to communicate with internet in other use cases , but how to prevent the coap response from going through the nat gateway ? ( go via nlb instead )
Is it because of the route table associated to the subnet of the ec2 task ?
Is in coap traffic from the nlb to server we lose the nlb IP address to preserve the source IP address ?
You're correct - what you should be doing is replying to the client request via the NLB. Note that it is much simpler if you're not using an IP target; but even if you are sending the response back via the NLB means that the client is much more likely to receive it. And as above, if you have a NAT Gateway then the server can still access other resources external to the VPC.
Hello Brettski, I've also encountered similar issues, and I'm interested in following your suggested approach to resolve the matter. I greatly appreciate your assistance in this regard. Could you please provide some guidance on how to implement the steps you mentioned
Replying via the NLB will happen automatically unless you are specifically creating a new UDP socket in your application code to send the reply back to the client - you don't need to do anything to make that work. If you are creating a new socket I'd suggest (as above) that you don't do that.