Why I Can't make SNAT using IPTables in EC2?
I've made a SNAT translation in my EC2 to receive traffic destinated to 172.31.30.102, and translate the source IP to 172.31.30.103, in TCP Dump, I see the translation happening, the original IP of my instance is 19.0.96.6.
IPTables command for SNAT that I used:
sudo iptables -t nat -A POSTROUTING -p tcp -d 172.31.30.102/32 -j SNAT --to-source 172.31.30.103
TCP Dump to analyse:
sudo tcpdump src net 172.31.30.103
But in the flow logs in my ENI, the source address doesn't appear, just the original one(19.0.96.6).
I've took kernel IP Forward on.
- Newest
- Most votes
- Most comments
What happens on the EC2 with iptables will not be seen in the flow flogs. The flow logs will always show the original packet before any manipulation on the EC2.
Again I maybe missing something in your question but this is my understanding of what your expecting to see.
Ok, but, my VPN allows the AWS side 172.31.30.103 to communicate over the VPN, but why the packets changed from source 19.0.96.6 to 172.31.30.103 are not being able to traversing the VPN?
Whats the CIDR block on the Subnet that your EC2 is on? What routes do you have on your Subnet to send traffic over the VPN?
My EC2 is on 19.0.96.0/27 I have a route in this subnet to 172.31.30.102/32 through VGW. I expect the packets with the source IP changed to 172.31.30.103, go out to the VPN through the 172.31.30.102/32 route. Because the customer that I have connected with the VPN only allows the 172.31.30.103 IP to communicate inside it's network, but I'm not being able to thanslate the source IP of 19.0.96.6 to 172.31.30.103.
I have the following output in my tcpdump: IP 172.31.30.103.11088 > 172.31.30.102.8078: Flags [S], seq 2208114893, win 62727, options [mss 8961,sackOK,TS val 2497077807 ecr 0,nop,wscale 7], length 0 The source IP 19.0.96.6 are being changed to 172.31.30.103, but the route table doesn't route to my NGW. Does AWS Network support SNAT?
Looking at your screenshot and information the 3 way tcp hand shake is failing. All I see is syn.
I would check the routes on the vpn and also your customer/client has a route back to the vpn
Yes, the connections is failing because the SNAT is not working, my client made a route just to receive connections from 172.31.30.103, as my NAT instance has the private IP 19.0.96.6, and not SNATing to 172.31.30.103, not even my traffic go out from my VPC, because my VPN side just allows 172.31.30.103/32 to go out. My NAT instance with a SNAT rule has a crucial work to make this communication happen.
Relevant content
- asked a year ago
AWS OFFICIALUpdated 9 months ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
What’s 19.0.96.6? What’s the private ip of the ec2? What’s the ENI ip address
I’m struggling a little to understand your question a little. What’s missing? What behaviour do you expect? Thanks. Sorry.
19.0.96.6 is the private IP of my NAT instance. The NAT instance is configured to change the source IP address of packets with destination 172.31.30.102, to 172.31.30.103. In my TCP Dump above, I see the source address being changed to 172.31.30.103, but, in cloudwatch I just see the original IP of my NAT instance, not being tranlated. I need this rule to change the source address to 172.31.30.103 in case the network's destination matches with 172.31.30.102.