I am unable to ping external-ips of my Google-Compute-Engines, from within the GCE machine.
But when trying from outside network (from my laptop), its able to ping.
From within GCE vm :
rharoon002#es-01-client-01:/$ wget http://ipinfo.io/ip -qO -
130.211.147.88
rharoon002#es-01-client-01:/$ ping 130.211.147.88
PING 130.211.147.88 (130.211.147.88) 56(84) bytes of data.
....... (hangs for ever)
From local system (laptop):
rharoon002#RHAROON00235 C:\Users\rharoon002
> ping 130.211.147.88
Pinging 130.211.147.88 with 32 bytes of data:
Reply from 130.211.147.88: bytes=32 time=238ms TTL=43
Reply from 130.211.147.88: bytes=32 time=236ms TTL=43
Reply from 130.211.147.88: bytes=32 time=237ms TTL=43
Reply from 130.211.147.88: bytes=32 time=238ms TTL=43
Ping statistics for 130.211.147.88:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 236ms, Maximum = 238ms, Average = 237ms
Its probably because of firewall settings. You may need to add a firewall rule. I found this similar question: https://stackoverflow.com/a/17904142/4743540.
Related
I recently updated from fedora 34 to fedora 35. Since then, I can connect to ocserv with my account but I cannot access the Internet because of this error
ping google.gr
PING google.gr(sof02s44-in-x03.1e100.net (2a00:1450:4017:80d::2003)) 56 data bytes
From 2001:648::1 (2001:648::1) icmp_seq=1 Destination unreachable: Administratively prohibited
From 2001:648::1 (2001:648::1) icmp_seq=2 Destination unreachable: Administratively prohibited
From 2001:648::1 (2001:648::1) icmp_seq=3 Destination unreachable: Administratively prohibited
From 2001:648::1 (2001:648::1) icmp_seq=4 Destination unreachable: Administratively prohibited
^C
--- google.gr ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3001ms
This happens with every address I try. I tried to uninstall and reinstall the ocserv server (and obviously restarting it...) and to reset the config file. Also, I viewed the firewall rules and the masquerade option is there.
I cannot reliably trigger this, although if I spin up many vms at a time and then attempt to connect to some of them, I run into this condition:
$ ping 192.168.122.135
PING 192.168.122.135 (192.168.122.135) 56(84) bytes of data.
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
From 192.168.122.1 icmp_seq=2 Destination Host Unreachable
From 192.168.122.1 icmp_seq=3 Destination Host Unreachable
Note that this does not happen for all VMs that I create and start, only a handful of them (randomly).
The vm that has obtained the ip 192.168.122.135 has the following for its network in its domain xml:
<interface type='network'>
<mac address='52:54:00:3d:72:ab'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</interface>
And the default network is defined as (and yes, 22 vms are currently running):
<network connections='22'>
<name>default</name>
<uuid>69674b8b-f067-4513-b594-3e52360f391b</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
The output from ifconfig for vnet0 (referenced by the VM's network domain xml) and virbr0 (used by the default network as shown above):
$ sudo ifconfig vnet0
vnet0 Link encap:Ethernet HWaddr fe:54:00:3d:72:ab
inet6 addr: fe80::fc54:ff:fe3d:72ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425 errors:0 dropped:0 overruns:0 frame:0
TX packets:1304 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:57503 (57.5 KB) TX bytes:67257 (67.2 KB)
and
$ sudo ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr fe:54:00:08:e9:a4
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:882508 errors:0 dropped:0 overruns:0 frame:0
TX packets:2527165 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:93980992 (93.9 MB) TX bytes:3047773583 (3.0 GB)
Below is the partial output from ip route list:
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
The route output above makes me think that it should be working. BUT ITS NOT. and it only fails sometimes, and works most of the time.
Why can't I connect to the guest (192.168.122.135) from the host??
I was originally using filters, but removing the filters from the VM's domain xml has no effect on this condition randomly showing up. If I spin up many VMs at the same time I can get it to happen to a lot of them. Some of the VMs work just fine though and allow me to connect.
Also, I am using ubuntu 14.04.3:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
With kernel 3.19.0-30-generic.
More info - virsh version:
$ virsh --version
1.2.2
libvirtd version:
$ libvirtd --version
libvirtd (libvirt) 1.2.2
I don't have enough reputation to comment... But I have a few suggestions on things you could try to further explore the problem.
Question: Does assigning an IP address in the 192.168.122.X subnet on vnet0 do anything? The route that is configured seems to suggest that your traffic will go to virbr0 since it has the 192.168.122.1 IP address. If you can't ping any other devices in that subnet, then I suspect that's the issue.
If that doesn't get you anywhere...
Packet trace on host / VM
Try doing a packet dump on virbr0 and on the internal VM interface when this occurs. Ping the VM, and see what kind of traffic you see.
sudo tcpdump -n -i virbr0 -v "icmp or arp"
Depending on what you see there, will help narrow down the source of the problem. If you're not even getting your pings on that interface, then it's a routing issue on the host. If pings are going in, but the VM isn't seeing them, then it's a network/routing issue with the libvirt network.
I recommend also doing the above with a working VM, so you have a reference to compare the traffic against.
Check ARP Cache
Check your ARP cache on the host when this occurs. Does the mac address exist in the cache? Maybe it's getting mangled...
To dump the arp cache:
# arp
Check your libvirt logs
If configured, libvirt will log to syslog using the 'libvirtd' tag. Check your configuration to be sure this is enabled. It seems unlikely it's a libvirt issue, but it wouldn't hurt to turn on the logging.
To enable this setting
# vi /etc/libvirt/libvirtd.conf
Add the line
log_outputs_"1:syslog:libvirtd"
Restart libvirt
# service libvirt-bin restart
I had similar issue. I just tried following command to check whether machine is installed properly or not.
lsmod | grep kvm
If it is showing kvm details then machine is installed properly.
After that to restart the services
service libvirtd restart
Also check gateway using the below command
netstat -rn
I have the same network setting, and similar problem in a CentOS 7 host. Eventually, it turned out that the problem was guest VM's firewall setting blocked echo request and other external connection. After changing the firewall setting, the problem is solved.
My case, I've a hardware server where Libvirt is installed.
On this server I create VM in where install libvirt and after that I've get random network interruption and ping response with 192.168.122.1:
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
I've fixed this be deleting default libvirt network on hardware server like this:
virsh net-destroy default
virsh net-undefine default
As a stop-gap until Google supports native IPv6 on Google Compute Engine, I'd like to configure a 6in4 (IP protocol 41) tunnel.
I added a firewall rule to allow protocol 41 on my VM's network:
Name Source tag / IP range Allowed protocols / ports Target tags
allow-6in4 216.66.xxx.xxx 41 Apply to all targets
And configured the tunnel in /etc/network/interfaces:
auto 6in4
iface 6in4 inet6 v4tunnel
address 2001:470:xxxx:xxxx::2
netmask 64
endpoint 216.66.xxx.xxx
gateway 2001:470:xxxx:xxxx::1
ttl 64
up ip link set mtu 1280 dev $IFACE
And ping6 2001:470:xxxx:xxxx::1 and verified that 6in4 traffic was outbound:
$ sudo tcpdump -pni eth0 host 216.66.xxx.xxx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:52:03.732841 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 1, length 64
22:52:04.740726 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 2, length 64
22:52:05.748690 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 3, length 64
I changed the endpoint temporarily to an address where I can run tcpdump, and confirmed that packets are not arriving at the destination. I even tried NAT myself in case GCE wasn't doing this for 6in4 packets, but no luck (iptables -t nat -A POSTROUTING -p ipv6 -j SNAT --to-source 130.211.xxx.xxx).
Has anyone gotten a 6in4 tunnel to work on a GCE VM? Is there some magic setting I missed somewhere?
TL;DR: You can't.
Per Networking and Firewalls:
Traffic that uses a protocol other than TCP, UDP, and ICMP is blocked, unless explicitly allowed through Protocol Forwarding.
Per Protocol Forwarding:
Google Compute Engine supports protocol forwarding for the following
protocols:
AH: Specifies the IP Authentication Header protocol.
ESP: Specifies the IP Encapsulating Security Payload protocol.
SCTP: Specifies the Stream Control Transmission Protocol.
TCP: Specifies the Transmission Control Protocol.
UDP: Specifies the User Datagram Protocol.
Hence, a Protocol Forwarding rule needs to be for one of the following IP protocol numbers:
51 (AH)
50 (ESP)
132 (SCTP)
6 (TCP)
17 (UDP)
The Protocol Forwarding page makes it clear that other protocol numbers, such as 41 (6in4) are not supported:
Note: This is an exhaustive list of supported protocols. Only protocols that appear here are supported for protocol forwarding.
How can i use tcpdump to capture Ethernet frames and display any frame sent or received by the local PC with one of the UDP, ARP, and ICMP protocols.
I was trying this command:
sudo tcpdump -e udp or arp or icmp
but, i thinks it's wrong.
I can give you an example, how you can capture enthernet frame from your localhost.
sudo tcpdump -i lo -nnvvvexxXXKS -s0
for capturing the frame we used "exxXX"
Do use tcpdump -e. Here's an example of the output:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:36:02.408697 02:42:ac:11:00:02 (oui Unknown) > 02:42:ac:11:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 74: client.60546 > yahoo.com.80: Flags [S], seq 1673384407, win 64240, options [mss 1460,sackOK,TS val 2181456358 ecr 0,nop,wscale 7], length 0
In this example, you can see frame fields such as the MAC addresses (e.g. 02:42:ac:11:00:03) and the frame type (e.g. ethertype IPv4 0x0800).
From the manpage:
If the '-e' option is given, the link level header is printed out. On Ethernets, the source and destination addresses, protocol, and packet length are printed.
On FDDI networks, the '-e' option causes tcpdump to print the `frame control' field, the source and destination addresses, and the packet length. (The `frame control' field governs the interpretation of the rest of the packet. Normal packets (such as those containing IP datagrams) are `async' packets, with a priority value between 0 and 7; for example, `async4'. Such packets are assumed to contain an 802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-called SNAP packet.
On Token Ring networks, the '-e' option causes tcpdump to print the `access control' and `frame control' fields, the source and destination addresses, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet. Regardless of whether the '-e' option is specified or not, the source routing information is printed for source-routed packets.
On 802.11 networks, the '-e' option causes tcpdump to print the `frame control' fields, all of the addresses in the 802.11 header, and the packet length. As on FDDI netâworks, packets are assumed to contain an LLC packet.
First of all, you are interested in packets, not frames. Frames are a layer below packets and only chip manufacturers are concerned with them. Second, you must specify your interface with the -i switch or promiscuous mode won't be even activated for you to see everything - if that's what you want.
How should I check if my ISP blocks port 25?
cmd> telnet <some well known email provider IP> 25
to determine which exactly host (subdomain) is listening port 25:
nslookup -q=MX <top-level domain>
For example:
cmd> nslookup -q=MX gmail.com
gmail.com MX preference = 50, mail exchanger = gsmtp147.google.com
gmail.com MX preference = 50, mail exchanger = gsmtp183.google.com
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt2.gmail-smtp-in.l.google.com
gsmtp147.google.com internet address = 209.85.147.27
gsmtp183.google.com internet address = 64.233.183.27
gmail-smtp-in.l.google.com internet address = 64.233.183.114
cmd> telnet gsmtp147.google.com 25
220 mx.google.com ESMTP l27si12759488waf.25
On Linux, you can 'dig', I guess.
http://www.canyouseeme.org/
telnet host 25
Just select a host that you know is listening on port 25.
You could call them and ask.
Probing a server that listens on your desired port is of course the best option, as abatishchev has shown.
In the case where you can't find an "echo" service on your desired port or you want to know who is blocking you on the path you can resort to firewalking. Firewalking probes the path by starting with a Time-To-Live (TTL) set to zero and then icrementing it by one each iteration. When you stop getting "ICMP TTL Exceeded" messages that means the next hop in the chain is filtering your packets.
You can use hping3 to do this:
:~$ hping3 -z -T -p 25 server.com
or use Firewalk which was created for exactly this.
Edit: Any NAT devices on the route will silently destroy your results since the TTL is reset to whatever sane value the router sees fit.