I am playing with the NLB. One feature is that it can preserve the client source IP. I tested it and it works. However, has anybody been wondering how it works?
Let's say that my home PC is the client for the HTTP request and it is behind the public IP 1.1.1.1
The NLB has an IP of 2.2.2.2 on the public side. The real webserver in the target group is an instance with private IP 192.168.0.10. The instance is also in the public subnet and it has an elastic IP of 2.2.2.10.
I confirmed with my packet capture (tcpdump) on the server that I see requests coming in from 1.1.1.1. I see the response going back to 1.1.1.1 as well. However, my home PC's Wireshark would show traffic to and from 2.2.2.2, and not 2.2.2.10... How's that possible?
From the routing perspective, the server would receive the request from 1.1.1.1 and will send a response back to it. The response would traverse through the IGW, instead of the NLB, and therefore will have 2.2.2.10 when on the Internet. The connection would be rejected by my PC because the response came back from a different IP (2.2.2.10) rather than the original one (2.2.2.2).
Is the NLB somehow tied to the IGW and in this case, the IGW would know to SNAT the response to 2.2.2.2 instead of 2.2.2.10?
Thanks,
Difan
Related
I have a network in GCP with configured firewall rules. I have couple of instances and two of them are as below.
instance 1 - with network tag "kube-master"
instance 2 - with network tag "kube-minion"
And I want to ping from kube-master to kube-minion So, I set up a firewall rule (master-to-node) for icmp as below.
But the problem is I can't still ping from kube-master to kube-minion. I logged into instance 1 (kube-master) and tried to ping the public ip address of instance 2 (kube-minion) but it doesn't ping
As above image, am I restricting this behaviour? But I have setup the priority as 2 so it will take the precedence.
When I set source as 0.0.0.0/0 instead of giving kube-master it works, but I need to only do this (send traffic to kube-minion) only from kube-master
Can someone tell me where am I doing the mistake? Thank you!
As you can see in the documentation
Thus, the network tags are still only meaningful in the network to which the instance's network interface is attached.
Therefore, if you access to the VM with the Public IP, you are going out of your network to reach it, and the tag information is lost. Use the private IP of the VM and it will work as expected.
Add 0.0.0.0/0 as source, or the public IP of the master in /32 (better) if you want to continue to use the instance 2 public IP
Source tags only apply to traffic sent from the network interface of another applicable instance in your VPC network. A source tag cannot control packets whose sources are external IP addresses, even if the external IP addresses belong to instances.
When you ping from instance-1 the external IP address of instance-2, the ICMP request is translated and therefore on the receiving side, the request appears to come from an IP address(external IP of instance-1) that is not associated with the network tag kube-master.
Edit:
I am spinning up my first ever AWS EC2 server.
In my security groups I added a new group called inbound and allowed http and https traffic but still not working:
Ping works on ICMP protocol.
When you ping any server, ICMP protocol is used to send a ICMP type 8 - Ping Request message. The server replies back with a ICMP type 0 - Ping Reply message.
When you ping a server, say google.com from your EC2 instance, the server would send ping reply packets back to the instance. In order to accept those packets, you have to add a Custom ICMP rule with Type 0 message in the inbound rules of the security group attached to the instance.
Simply attaching the security group shown in the screenshot to the instance would not help. Also, it is in no way connected to port 80/443 and Apache at all!
Hope this helps!
I followed the AWS instructions for allowing HTTPS and HTTP and created a new security group.
What i failed to do was add the new security group to the instance that I was running.
To do this select your instance then click Actions->networking-CHange Security Groups
I have a domain that I own. I will say is example.com. I added SSO.example.com as a Type A record on GoDaddy with a value of 37.89.245.2(example).
The IP address is a elastic IP on a Windows AWS server.
I can ping the IP address but I can't ping the URL. Do I need to do something with the IP address on the AWS Windows server to be able to ping the URL?
This is pretty much one of my first web based projects so any help would be appreciated!
Ping is not a reliable test method in AWS because most security groups do not permit inbound ICMP protocol, which is used by Ping. So, if you really want to test connectivity, do it on a port that you actually need your application to support, such as HTTP (80) or trying an SSH/RDP connection.
Another common use for a Ping is to resolve the domain name to an IP address, since it displays the result on-screen. This can be a good way to check that your Amazon Route 53 configuration is correct. (Same as a dnslookup.)
I was jumping the gun a bit and the new NameServers I was using had not replicated completely yet. After replication completed everything was able to be pinged successfully.
I have created a VPC with public and private subnets on AWS. All app servers are in private subnets and all outbound requests have to be through an internet-facing NAT instance.
At the moment, our project requires the app servers to access a ftp server provided by a service provider.
I have tried several ways to manage that, but all no luck. What I have done was to open a port range, let's say (40000 - 60000) on both NAT and APP security groups, also standard ftp ports 20 - 21 as well.
The user authentication can be passed, but I could not list contents from app servers.
I am able to access the ftp server from NAT, not problem at all.
So what should I do to make it work?
#JohnRotenstein is absolutely correct that you should use Passive FTP if you can. If, like me, you're stuck with a client who insists that you use Active FTP because their FTP site that they want you to connect to has been running since 1990 and changing it now is completely unreasonable, then read on.
AWS's NAT servers don't support a machine in a private subnet connecting using Active FTP. Full stop. If you ask me, it's a bug, but if you ask AWS support they say it's an unsupported feature.
The solution we finally came up with (and it works) is to:
Add an Elastic Network Interface (ENI) in a public subnet on to your EC2 instance in the private subnet
So now your EC2 instance has 2 network adapters, 2 internal IPs, etc.
Let's call this new ENI your "public ENI"
Attach a dedicated elastic IP to your new public ENI
Let's assume you get 54.54.54.54 and the new public ENI's internal IP address is 10.1.1.10
Add a route in your operating system's networking configuration to only use the new public ENI
In windows, the command will look like this, assuming the evil active ftp server you're trying to connect to is at 8.1.1.1:
route add 8.1.1.1 mask 255.255.255.254 10.1.1.1 metric 2
This adds a route for all traffic to the FTP server at 8.1.1.1 using subnet mask 255.255.255.254 (ie. this IP and only this IP) should go to the internet gateway 10.1.1.1 using ethernet adapter 2 (your second NIC)
Fed up yet? Yeah, me too, but now comes the hard part. The OS doesn't know it's public IP address for the public EIN. So you need to teach your FTP client to send the PORT command with the public IP. For example if using CURL, use the --ftp-port command like so:
curl -v --ftp-port 54.54.54.54 ftp://8.1.1.1 --user myusername:mypass
And voila! You can now connect to a nightmare active FTP site from an EC2 machine that is (almost entirely) in a private subnet.
Try using Passive (PASV) mode on FTP.
From Slacksite: Active FTP vs. Passive FTP, a Definitive Explanation:
In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.
Thus, the traffic is trying to communicate on an additional port that is not passed through the NAT. Passive mode, instead, creates an outbound connection, which will then be permitted through the NAT
There is a web service (in an Intranet environment) what checks the client IP and if it is not a valid IP then refuses the request. Is there any opportunity to cheat at this web service with the IP?
Thank you in advance.
It is prefectly possible to send IP packets with fake IP addresses. However, you won't get a reply because the reply will be directed at the fake IP address. This means that you can't establish TCP connections (upon which HTTP(S) depends) because they require two-way IP traffic.