I am able to successfully trace the route from my PC to neverssl.com via traceroute's ICMP function:
traceroute -I neverssl.com
which takes about 20 hops (I have not included the output due to the personal IP addresses displayed etc).
However, when using traceroute's TCP function:
traceroute -T neverssl.com
I get the result in the attached picture. This happens with any website I try.
Is there any reason why I am seeing only the gateway and destination? I have replicated the same results with the "tcptraceroute" package. I am on Ubuntu if it helps.
Related
I spent hours on this but with no success, I am trying to ping: 172.23.67.188 (Router B external ip) from A-Host.
So in A-Host terminal I typed:
ping 172.23.67.188 -c 3
But ping fails with 100% loss, so I ran it again with tcpdump and got the following output:
Why I don't see arp request like this:
arp who was 172.23.67.188 tell 192.168.11.188
What is causing this ping to fail? (Note A host can ping itself, Router A both internal and external ip)
Here is a diagram:
Please Note: x=187, y=188
You won't see an ARP request like "arp who was 172.23.67.188 tell 192.168.11.188" because 172.23.67.188 and 192.168.11.188 are on different networks, so the ARP should be for the router 192.168.11.188 uses to reach 172.23.67.188. Also note that both these addresses are not globally routable since they are in the private address space.
Our Company has a VPN connection provided by the ISP in our country , I can Traceroute to a Remote host on another site connected to the VPN but I cant ping to it. The ping command works to hosts on remote site only for a short while right after I do the traceroute to the particular host. Why is it that the ping command only successful right after the tracert command is excueted??
At a guess, this sounds like its potentially Proxy ARP? I would check to see whether or not the Traceroute is temporarily populating your ARP table, allowing the ping to work. Just because you can't ping a device right off the bat doesn't mean its not reachable.
I have two machines:
Ubuntu 16.04 server VM (172.18.6.10)
Proxmox VE5 station (192.168.6.30)
they are communicating through a third machine that forwards packets between the two. I want to create a gre tunnel between the two machines and to do that and make it persistent I have edited the /etc/network/interfaces and added a gre interface and tunnel to be made on boot up as the following:
After they were created I have tried to ping one machine from the other to check connectivity, pinging the gre interface IP address (10.10.10.1 and 10.10.10.2). The issue is that when I ping the Proxmox machine from Ubuntu I get no feedback, but when I run tcpdump on gre1 on Porxmox I see that the packets are received and there is a ICMP reply outgoing:
When I run the ping the other way around and check it with tcpdump on the Ubuntu machine I get nothing. I understand that the issue is when packets leave Proxmox to Ubuntu via gre1 and get lost or blocked because Ubuntu can clearly send Proxmox packets but the reply never comes back. How can I fix this?
Check if you have packet forwarding enabled for the kernel of the 3rd machine that you user for the communication of the other 2 machines
Check /etc/sysctl.conf and see if you have this:
net.ipv4.ip_forward = 1
if it's commented (#) uncomment it, save the file and issue a:
sysctl -p
Then try again the pings...
my box runs ubuntu 14.04. it is an old 32bit box with 4 ether nics.
what i want to achieve is multicast routing from an upstream interface (eth2.8 - dynamic ip) to a downstream interfcae (eth0.13 - 192.168.40.1).
my laptop attached to above box via eth0.13 can read multicast from 40.1 like a charm.
i verified that by running vlc as a server on 40.1
cvlc -vvv ./POS-Movie-927x521.mov --sout udp:239.255.12.42 --ttl 12
and receiving the stream on my laptop with
vlc udp://#239.255.12.42
that works even the other way round, sending with my laptop and receiving on the serverside.
so why is it not possible to access multicast packages via eth2.8?
joining works. i can verify arriving packages by
sudo tcpdump -i eth2.8 -n multicast
but it seems simply impossible to access these packages without tcpdump!
this exactly describes what i am experiencing, alone the solution is not the same.
here some sysctl parameter:
net.ipv4.conf.eth2/8.rp_filter = 1
net.ipv4.conf.eth2/8.mc_forwarding
= 1
net.ipv4.conf.eth2/8.forwarding = 1
there is no difference between sysctl params of eth2.8 and eth0.13.
and yes, this happens even if the firewall is down!
any hint appreciated, you'll make my week!
/markus
the unicast route to the upstream hosts where missing!
the interface did accept incoming igmp traffic from an ip in its own class c net but refused packets from other hosts.
unluckily the upstream is from some completely diffent network.
a simple "ip route add ip/mask dev eth2.8" finally solved all problems.
I am running a Windows 8 VM inside of vmware Fusion. It runs inside a Mac running OSX 10.10 (Yosemite). The VM has a computer name of "Proud". When I ping the VM from within itself, i.e. ping -a 192.168.0.138 I get a response like:
Pinging Proud [192.168.0.138] with 32 bytes of data:
Reply from 192.168.0.138: bytes=32 time<1ms TTL=128
However whenever I ping Proud from Yosemite, i.e. ping Proud I get a response like:
PING proud (199.101.28.130): 56 data bytes
64 bytes from 199.101.28.130: icmp_seq=0 ttl=46 time=418.646 ms
The VM is using bridged networking.
Why does Proud resolve to that IP address? It is not correct and means I am unable to use the hostname (a necessity) so that I can connect to it from the Mac.
First, test and check with IP_address typed for ping from OSX 10.10 <host> terminal, so as to be independent of any DNS-service, that is responsible for a hostname translation of your <hostname> to a pre-configured IP_adress
Second, You say bridged -- thus check, that the VM has the very same network-part of the IP_address ( boundary is given by non-zero bits in subnet-mask
Check details with ifconfig resp. ipconfig
-------------------------|-----------------------------|||--------|||.|||.|||.|||
VM/w8 connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
RM/OSX connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
EDIT#12014-08-20 15:30 [UTC+0000]:
-------------------------?-----------------------------???--------255.255.255.0
-------------------------|-----------------------------|||
Best to post PrintScreens from {OSX|w8} terminals {ping|ipconfig|ifconfig} and the setup of VMnet
This seems to be a 'feature' of Mac OS. If I attempt to ping any hostname it will return the ping from this IP address - even if the hostname is fictional. I do not know why OS X does this.
This is called DNS hijacking and is done by a lot of ISPs out there to redirect you on incomplete or wrong browser address inputs and show you these custom pages with advertisment 'Hey, we couldn't find your webpage Aple.com but maybe you look for Apple.com?'
Maybe this is whats happening here. Btw, ISPs break RFCs here.
You need to check on your own /etc/host file. See if you might have done any changes to this file, to indicate the machine "Proud" comes as 192.168.0.138 or x.x.x.130? Next thing to ensure (user3666197 is actually right), you need to check on ifconfig to check if you have any connection have the IP address pointing to x.x.x.130 or x.x.x.138.
Last but not least, is there any virtual appliance or instance running of "proud" which might have caused confusion as it is possible for any virtual appliance or instance to get a IP address from the same segment as well, hence having "two" machines on the network?
Hope this helps. Check on your WINS config too...