providing some more details of what your test is and what the behavior/error is would be helpful.
Fundamentally, if you are launching your Lambda in a VPC, into a subnet that you have already confirmed has access to the on-premise resource, this should work.
It shouldn't matter if the lambda is in a public or a private subnet (using a IGW or NAT), but in either case, a route MUST be in that subnet for the on-premise ip address range.
Additionally, you need to make sure the security group that the lambda function is using is correctly allowing the ports you want to access.
Finally, you should rule out if there are any DNS resolution issues: Out-of-the-box, resources in a VPC will not resolve to your on-premise DNS. You should first rule this out by trying to hit the on-premise resource using an IP address instead of DNS.
Hope that helps. If it doesn't, try to submit details, which will help dig in further.
Thank you for the quick response.
I'm using the same security group for ec2 instance and lambda, so I would expect that it is not the security group settings.
I don't use DNS, I'm trying to reach the service with ip address. I have even tried to access the router webservice by ip address, but it doesn't work via lambda as well.
The same VPC is being used for EC2 and lambda, so I would expect that an ip address from the same subnet will be assigned to both ec2 and lambdas, am I wrong?
Is there any way to use ping in lambda to be able to test that the on-premise ip addresses can be accessed?
Is there any way to find out ip addresses assigned to a lambda for all network interfaces?
Could you please elaborate which details I should provide for the troubleshooting?
this really seems like it may be something in your lambda code.
Are you running the EXACT same test on your EC2 as in your lambda?
Can you provide the code (you can obfuscate the ip address), and the output from the lambda function.
I would suggest doing a telnet test using tcp instead of a ping, assuming you are trying to hit something via tcp on premise..e.g. in Python 3.6:
def lambda_handler (event,context):
Thank you for supporting me in this fight.
So I was wrong, I could not access the server via EC2. I can ping the server, but I can't telnet to the server:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=8.78 ms
telnet 192.168.1.1 80
telnet: Unable to connect to remote host: Connection timed out
If I do it from a local server I can access it:
telnet 192.168.1.1 80
Connected to 192.168.1.1.
The same happens when I run the code in python.
is there any way to figure out where the connection is being blocked?
I can see from the flowlogs that it seems that it is going through:
13:46:07 2 xxx eni-xxxxxxxxxxxx x.x.x.x 192.168.1.1 60912 80 6 6 360 1559533567 1559533569 ACCEPT OK
The problem that the router on-site doesn't have any logging, so I can't tell what is wrong on the on-premise side.
Edited by: igorau on Jun 2, 2019 10:55 PM
First of all, while you are running an active ping from the EC2 to on premise, run a netstat -an on your on premise systems and confirm you are seeing the IP of the ec2 in that list. That will confirm you are indeed routing back there.
Are you definitely running a web service on port 80 on the on premise server? Netstat would also show you if the server is listening on 80.
Rule you that you don't have NACLS in place on your EC2 subnets. I'm guessing it's allowing all inbound and outbound, which would be the case if you accepted the defaults, but that should be ruled out. You also need to confirm that the security group of the EC2 instance is allowing outbound, port 80 (guessing that's allowing all outbound).
Check the local server firewall (e.g. iptables), and firewall logs, to see if any rules are in place and if anything is being blocked. If you aren't sure how to read the configs, you should provide text or a screenshot.
You need to review the ACLs of the on-premise firewall. By default, it likely wouldn't allow port 80 traffic in from an outside network. Given what you are describing, this is probably the most likely source of the problem, although it could be others. Again if you aren't sure what you are looking at, you should provide the detail here to assist in troubleshooting.
Seems a little odd that the on-site router doesn't have any logging: That would be the first place I would go to review this, and it will likely provide very useful information. Do you mean you don't have access to them?
cloudbutton: thanks very much for your help. You suggestions helped me to analyze/dig deeper. And after a lot of retries and when I reset the router to factory settings and re-configured it again, it started to work! So potentially, there was some issue with the router. Now it is all working, appreciate your help!
- Accepted Answerasked 7 months ago
- asked 9 months ago
- Accepted Answerasked a year ago
- asked 4 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 months ago
- How do I troubleshoot connection timeout errors from Lambda when trying to access an Amazon RDS DB instance?AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 8 months ago
- EXPERTpublished 3 months ago