Thanks to everyone in advance -
I have an ec2 instance with the following network config:
eth0 - internal-ipaddressA
eth1 - internal-ipaddressB
public-elastic-ipddressA associated with internal-ipaddressA
public-elastic-ipddressB associated with internal-ipaddressB
I configured sshd to listen on both these addresses explicitly:
internal-ipaddressA
internal-ipaddressB
I can ssh to public-elastic-ipddressA and then ssh to internal-ipaddressA AND internal-ipaddressB, just to make sure sshd is working correctly on both addresses.
All that said, I am unable to ssh to public-elastic-ipddressB if it is associated with any other network interface besides the primary, which was created by default when the instance was started.
Am I missing some sort of special routing or ACL/security configurations here?
Thanks!
Sam
The sshd process is probably bond to the first adress.
You should look at /etc/ssh/sshd_config. The ListenAddress propeties contains the adress it listen to (man page).
The adress is probably first set by Cloutint.
It's a routing problem. You need to put each network interface of the instance in a different subnet of the VPC or the packets won't be routed back from the instance to the destination.
Other solution is to assign two internal IPs to the same network interface, and then configure them in the OS as eth0 and eth0:1, but this won't achieve your objective.
Related
I have one VPC with two Subnets (SubnetA and SubnetB).
My team wants to have multiple IPs assigned to the Instance, each from one subnet.
The Instance already have one Private IP (from SubnetA, Primary one) when I launched it, then I attached another Private IP from another SubnetB via the Console Attach network Interface option.
I can see both of the IPs in the console under Managed IP Address option.
I rebooted the Instance, and I was expecting to see both of the IPs when I do ifconfig, but I can see only the Primary one.
To cross-check if the Private IP is actually attached to the Instance, I queried Instance Metadata using the following commands :
curl -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:14:46:91:bc:34/local-ipv4s
curl -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:1d:2a:75:ax:04/local-ipv4s
I can see both of the IPs in the output for the above two commands respectively.
I checked the status of NETWORKMANAGER systemctl status NetworkManager
It was stopped
I started the Service and enabled NetworkManager automatically at boot time, using following commands:
systemctl start NetworkManager
systemctl enable NetworkManager
Then I checked the output of ifconfig
This time it showed me both of the MAC addresses, with the only difference for the second one I was not able to see the IP address. So basically the interface is up, so the underlying device is found. There is no IP address associated with this interface.
So I tried both of the options to associate IP:
Assign an IP address manually:
sudo ifconfig ens6 w.x.y.z
Or contact the DHCP server, if it exists, and let it provides an IP address for the interface:
sudo dhclient -v ens6
Both of them worked and I can see both of the IPs under inet.
The last problem was I have to do this every time I reboot the Instance.
So I was trying to add a permanent route using the following command:
sudo /sbin/route add default gw 1xx.xx.2xx.193
Here the IP is the second IP from the SubnetB, but I am getting the error :
SIOCADDRT: Network is unreachable
To solve the above problem what I did is, I was already having a file with
/etc/sysconfig/network-scripts/ifcfg-ens5 with details for Primary IP, I added one more file
/etc/sysconfig/network-scripts/ifcfg-ens6 with the necessary details for secondary IP
This is what I referred.
Rebooted and it is working.
But I am not able to ping the secondary IP.
I think I have to add one more Gateway from the second subnet but not sure about this.
What else needs to be done so that I can route traffic, ping, ssh using the Secondary IP.
Please refer to my VPC Subnet CIDRS:
Subnet A: 1.7.2.128/26
Subnet B: 1.7.2.192/26
Output of ip route:
Update:
Today when I started the server I am able to ping the Secondary IP(200), but not the Primary one(136), from one of my test Instances. Also, ssh is done using Primary IP.
ip route add default via 1XX.XX.XXX.X9X dev ens6 table 2000;
ip route add 1XX.7X.2XX.X9X dev ens6 table 2000;
ip rule add from 1XX.7X.2XX.1XX lookup 2000;
The above command helps me to resolve this issue and I am able to ping my secondary IP.
To make this configuration persist after reboots, the same commands, I have added into rc.local
In the first line, the IP is the Gateway IP (Second IP in the Subnet Range)
The IP mentioned in the second and third lines in the command is the actual Secondary IP of my Server.
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:
Every EC2 comes with a default network ETH0 and if we associate an elastic IP address to the default network interface, the IP is reachable.
Now, I disassociated the elastic IP to the default ETH0. Created a new network interface (ETH1) and associated the elastic ip. Attached the new network interface (ETH1) to the instance. But the elastic ip is not reachable or pingable.
Any idea why?
While AWS does allocate a secondary IP address for your instance, I don't think DHCP can be used to automatically configure the IP address on your Ubuntu instance.
You will need to add the secondary IP address to your system configuration. I found a few resources that suggest ways to do this.
From How to assign a second IP address on AWS Plesk for Ubuntu?:
Connect to the instance via SSH and edit the /etc/network/interfaces.d/50-cloud-init.cfg file. Add the following lines at the bottom:
auto eth0:1 iface eth0:1 inet static address 172.31.16.199 << Your actual address
Execute the following command to apply the changes:
systemctl restart networking
Other similar pages:
ubuntu - adding 2nd private IP on AWS EC2 instance - Server Fault
14.04 - add additional ipv4 addressess to the interface - Ask Ubuntu
networking - Add second IP-address to interface in 17.10 - Ask Ubuntu
Created an AWS AMI instance.
I can telnet from the instance itself
telnet [Pv4 Public IP] 9200
But not from my pc.
This is my security group
What am I doing wrong?
You can check your Network ACL configurations.
It looks like there is some other firewall in between your PC and server which is blocking you on 9200.
If you can access port 80 via telnet or you're able to SSH in it's likely you have a network ACL in place. If you can not access port 80 via telnet but you can via a browser it's like a local config - maybe AV or a firewall.
EC2 instances use security groups for their firewall
Another test to narrow down the the issue would to see if you could telnet from another instances in the same subenet in the same AZ. Being in the same subnet you should not be affected by a network ACL.
You can have a look at this telnet-to a cloud instance from outside
The solution to problem was "Open the services and make the telnet manual and right click on it and chose start"
As well make sure that the instance is residing in a public VPC
Based on what you've described, there isn't really much else to work with. Your ability to telnet the public IP from the instance implies the server is listening on the external interface and your security group is already set to have the port open to all incoming connections.
Aside from the trivial overlooking of not actually having the instance under the listed security group, the only possibility I can think of now is an active firewall on the instance. In the case of iptables or ufw (which is an interface to iptables), it's trivial to verify whether they are indeed getting in the way:
// List iptables access rules
sudo iptables -L -v
// List access rules via ufw
sudo ufw status
You said: "This is my SG", but...which way? Inbound or outbound?
It can simply be that your host can't reply to your PC.
Try to add a rule which adds outbound TCP ranging from ports 32768 to 65535 (ephemeral ports), so that the telnet server response packets can travel back to your PC.
Otherwise, like the others said, look at one level up, VPC-level (network ACL).
You might have your acceptor process running on 127.0.0.1:9000 which means only local clients can connect. This is not related to your Security Group which could be wide open.
Run lsof -i:9000 if on unix.
If you see something like this under NAME then host IP used to start your acceptor will needs to change from 127.0.0.1 to 0.0.0.0 (and secure via SG/FW).
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 2777 ubuntu 148u IPv6 26856 0t0 TCP localhost:afs3-callback (LISTEN)
A Telnet service is not installed by default on an Amazon Linux AMI.
If you wish to use it, you will need to install it yourself, eg: Install and Setup Telnet on EC2 Amazon Linux or CentOS.
However, these days it is recommended to use ssh instead of telnet because it is more secure. See: Telnet on wikipedia
Just a thought, check firewall of your PC.
Need to ensure your SSH key you generated via IAM and attached to the EC2 at launch is added to the login:
ssh-add -K <yourkeyname>.pem
ssh ubuntu#<yourdns or ip>.com == or == ssh ec2-user#<yourdns or ip>
When I spin up an Amazon EC2 CentOS 7 server in, say, availability zone us-east-1a, the server is automatically assigned a primary private IP address on eth0, such as 172.31.8.244/20 and a gateway of 172.31.0.1. If I then attach a second interface on eth1, I can specify the address, which needs to be within the 172.31.0.0/20 subnet (or one will be assigned to me automatically within that subnet). Eth1 will have the same gateway as eth0. Let's say I am assigned 172.31.12.121/20. I use the same security group on both eth0 and eth1, which allows SSH only in and everything out.
The problem is that when I try to SSH to eth0 from a different server, it works fine. But when I try to SSH to eth1 I get a timeout. ip addr and ip route show that both interfaces are up and have the correct routes. I can even SSH locally to eth1 and the /var/log/secure log shows the correct entries as when I SSH to eth0 bound to eth1. What do I need to do to be able to SSH to either interface from a different server?
The problem is asymmetric routing. A request to eth1 comes in eth1 and goes out eth0. The reply coming out on eth0 has a different IP address than in the request, and so it is dropped on the client side. The solution is to set up rules that allow responses to route through eth1.
First, make sure you have created an AMI of your server, because if you enter the wrong thing in following steps, you may lose all connectivity to the server and be unable to do anything but reboot it from the Amazon console web page.
Start off by setting the default route for each interface in separate tables:
ip route add default via 172.31.0.1 dev eth0 tab 1
ip route add default via 172.31.0.1 dev eth1 tab 2
To check those were properly added use:
ip route show table 1
ip route show table 2
Now you need to add rules that say to use the different tables depending on the source IP address:
ip rule add from 172.31.8.244/32 tab 1
ip rule add from 172.31.12.121/32 tab 2
You can check all of the rules with:
ip rule
You should now be able to connect to either IP address from a client machine. You can also use the bind option of SSH to connect from either interface on this server to a client machine:
ssh centos#client_ip_address -i mykey.pem (uses the default, eth0)
ssh -b 172.31.12.121 centos#client_ip_address -i mykey.pem (uses eth1)
ssh -b 172.31.8.244 centos#client_ip_address -i mykey.pem (uses eth0)
You can use both interfaces to connect to other EC2 servers in the same availability zone and for any interface that has a Public IP assigned to it, you can connect to the outside world or to other EC2 servers in the same VPC, even if they are in different availability zones.
But what if you want to connect to other EC2 servers that are in the same VPC but different availability zones? In other words, servers in the same data center. The problem is that the Private IP address is masked at 20 bits, which confines you to one availability zone. So for datacenter us-east-1 you have:
us-east-1a: 172.31.0.0/20
us-east-1b: 172.31.16.0/20
us-east-1d: 172.31.48.0/20
us-east-1e: 172.31.32.0/20
To connect across availability zones in one VPC and in one datacenter you need a 16-bit mask. ip addr will show:
inet 172.31.12.121/20 brd 172.31.31.255 scope dynamic eth1
If losf -n | egrep 172.31.12.121 shows you that this address is not in use you can add the new mask and delete the old. Note that the broadcast address has to change at the same time the mask changes:
ip addr add 172.31.12.121/16 dev eth1 brd 172.31.255.255
ip addr del 172.31.12.121/20 dev eth1
Now you should be able to connect from an EC2 server in availability zone A to another host in availability zone B, so long as they are in the same VPC, even if they do not have Public IP addresses.
Troubleshooting:
If you are having problems, try resetting both interfaces, which will remove any manual twiddling you have done. First copy /etc/sysconfig/network-scripts/ifcfg-eth0 to /etc/sysconfig/network-scripts/ifcfg-eth1, editing the second file to change the DEVICE from eth0 to eth1. Then add a line to /etc/sysconfig/network which says GATEWAYDEV=eth0. Finally, run /etc/init.d/network restart (no, it should not disconnect you). Then start over with the above commands.