In the process of trying to setup openvpn on my Linux machine, I ran into a a problem with "No route to host." When I diagnosed this with tcptraceroute I see that the last two entries are duplicate IPs. Is it possible that my ISP is intentionally blocking traffic? Can anyone suggest a workaround or do I need to switch internet providers? Otherwise the Linux computer has no problems with network connectivity.

Here is an anonymized tcptraceroute excerpt:

$ sudo tcptraceroute 189.214.yyy.yyy
...
...
17 177.238.xxx.xxx.cable.dyn.cableonline.com.mx (177.238.xxx.xxx) 95.734 ms 100.253 ms 98.005 ms
18 177.238.xxx.xxx.cable.dyn.cableonline.com.mx (177.238.xxx.xxx) 101.598 ms !X 101.614 ms !X 98.502 ms !X

You're welcome to put up anonymous data if you like, but it greatly affects the quality of answers you get, as none of us can try it for you. Likewise, it's guesswork answering traceroute questions without the output.

That said, each line is a step on the routing table of some random server that you just happened to bump into. In effect, you are asking us why those sysadmins wrote what they did (which you don't show us) in the routing tables, and we can only guess.

Posting my IP addresses here is more than I want to do. I do understand that it limits the advice I might get. Maybe instead of solving my specific problem someone can answer a more generic question for me.

I would like to understand the magic that allows a packet going between the same two endpoints to be routed properly when the connection is initiated in one direction, but fails when the connection is initiated from the other. Are the bad routes ignored with response packets somehow?

End to end is the magic of routing. Each hop gets the next hop from source to destination. Once a connection is established from point A to point B then the reply simply follows the established connection.

However, the same is not necessarily true in the opposite direction. I can easily connect to goggle.com, but google.com cannot connect to my PC since i am behind a router on a private IP and using NAT to communicate to the world. Google.com can reply to a connection that is established from my end, but is unable to initiate the connection from their end.

As far as pings, traceroutes, etc. there are often border connections that block/drop packets of that type. Thus in your earlier question it seems the router you encountered was dropping the packets and you saw repeated attempts with no reply.

I have always thought that NATing of packets only happened at the endpoints of a connection, at the modems that are in our houses. But maybe my network provider has NAT devices before my house. I have control over port forwarding once the packet hits the router in my house, but if there are NAT devices at the network provider before my house, then I simply have to look for another network provider or give up.

Easy to tell.
What is the IP shown on your router on the internet side? If it is a private IP then certainly the ISP is doing NAT for you. If it is a public IP then it is not likely they are doing NAT.

If the result of https://www.whatismyip.com/ matches the IP on your router then it is certain that you have a public IP and the ISP is not doing any form of NAT. In that scenario port forwarding will work. If they are doing NAT then port forwarding is not likely to work.

With NAT the destination address is included in the packet header which the router can map to the internal IP address that it is intended for. When the connection is initiated outside the NAT, the packet does not contain this destination address. That explains how the use of NAT can allow for connections to be originated in only one direction.

You have convinced me that the only NAT is occurring inside my house. So I still don't understand my problem, that routing works correctly when originated in only one direction between the same endpoints.

I guess I don't understand the question.

Routing (always) only works in one direction.
The originating point sends a packet to the destination and each router in the path sees the destination address and forwards it as needed. Each router also maintains a record of the packet and knows how to return the reply when/if received. Nothing complicated or hard to understand there.

Maybe the confusing part is what each router does with the packet depending upon type. Ping and traceroute use ICMP packets and sometimes those packets are deliberately dropped with no reply. TCP and UDP packets are seldom dropped at the router. If TCP & UDP packets are dropped at all then it mostly is done only by firewalls.

Nothing is forwarded by a router to a private IP address unless the router explicitly is told where to route that address. This is part of why port forwarding on your internet facing router is necessary for communications from the internet to your server on the LAN. A packet incoming to the internet facing IP of the router & port has to be forwarded to the private IP & port of your LAN server. Note that in that case the client on the internet only knows the public, internet facing IP of your router and has no information about what is on the LAN behind that router.

Back to the traceroute question. If a trace request times out before it receives a reply your PC repeats the request, and will again get a response from the last point that previously responded if that point sees it as a new request.

Let me try my question again.

I have a host A and a host B. When I initiate an ssh session from A to B it works. SSH is a conversation, packets are being sent in both directions. When I type a letter in my ssh session, a packet goes from A to B. B receives the packet and echoes back the letter to be displayed and that packet is correctly routed from B to A.

When I initiate an ssh session from B to A I receive a "no route to host". I don't understand how echoed packets can get from B to A correctly, but packets that initiate from B are not properly routed to A.

ICMP is not an issue since I always use tcptraceroute. If you look again at my anonymized tcptraceroute report in my first post you will see that the last two reports are duplicate IPs, but seem to be successful when taken individually.

Where are host A and host B? On the same local subnet? At different sites on the internet? One local on your LAN at home and one at work? Where they are and the path needed to connect are important.

One scenario that may cause what you describe is:
Host A on the local LAN at home, with a router having an internet facing WAN public IP and a LAN with a private IP subnet. Host A connects to the internet courtesy of NAT managed by the gateway router.
Host B has an internet public IP.

Host A can always connect to host B since it has a public (routed) IP. Once the connection is established the session is stable and host A sees the echo of commands typed in. This will remain stable until either the connection times out or is manually disconnected.

OTOH, Host B cannot directly connect to host A since host A does not have an internet (routable) IP. Host B can connect to host A using the IP of its router as long as port forwarding is configured on the router and the router redirects the connection to host A using the private LAN IP.
If port forwarding has not been configured on the router host A will not be reachable. It also cannot be seen by any tools using a port other than the ones forwarded by the router.



There are 3 private IP subnets that were defined when the internet was an infant.
10.0.0.0/8
192.168.0.0/16
172.16.0.0/12
These are defined in RFC 1918 and maintained by the IETF as they have been since the beginning. No address within those ranges can be routed anywhere on the internet, but only within local LANs

In my example Host A is in Mexico, Host B is in New Jersey. The last two lines in the tcptraceroute report showed hop 17 and 18. 18 hops for a local subnet would be a lot. :-)

I am only using the public IP addresses of the two routers. I have tried to simplify the question by eliminating the NAT and port forwarding that happens at the endpoints.

I do not understand your use of the word "stable". I had understood that each packet is routed independently of any others in the connection. Is that not true?

Both host A and host B are modem/routers. One is cable and one is fiber optic, but otherwise very similar. In any case, tcptraceroute never reaches the modem.


I believe the problem is a NAT device within my Mexico internet provider's network. When I do the reverse tcptraceroute I get this report:

1 192.168.0.1 3.313 ms 3.768 ms 2.222 ms
2 * * *
3 10.12.1.13 23.506 ms 20.169 ms 40.626 ms

The third hop is a private address. I think that answers my question. Thanks to all for the help.
I hope to solve my problem with an ssh tunnel implemented as a daemon.

True, but I was looking for enough detail to generate a meaningful discussion of the problem.

yes, and no.
The routers in the path know the connection is already established so they do not have to look up the routing but simply pass it to the next one in the chain. Packets for an established connection are not "routed" but simply passed to the next connection in the chain. A new connection must be "routed" because the path has to be looked up before it can be established.

I think you have identified it. Double NAT usually means port forwarding cannot be done unless the ISP is really favorable to the user. It would require double forwarding, once for each private subnet.

A reverse ssh tunnel may work with the connection originating at host A and the daemon on host B so it can be established and maintained.
Establishing a VPN originating from host A (client) and ending at Host B (server) is also a possibility that could work.

Here is my solution as a systemd service. From host_b I then can ssh -p 3822 localhost to get to host_a

[Unit]
Description=Remote SSH Tunnel to host_b
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=rick
ExecStart=/usr/bin/ssh -N -R 3822:localhost:22 host_b

[Install]
WantedBy=multi-user.target

I was experiencing the same thing on my internal network on the same network segment (no route to host). I had just started using qemu-kvm and I initially thought that it was due to some isolation mechanism. Then one day I decided to check to see I even had the sshd server working on the system that was giving me the not route to host message. To my surprise sshd was not even running.

@RickPoleshuck
I think that no matter how it is done (ssh tunnel or VPN) that the connection will have to be established (originated) from the host A end since that is the one behind a double NAT scenario.

Does your solution above work?