Sujet : Re: Where to get the sources (openconnect) ?
De : unruh (at) *nospam* invalid.ca (William Unruh)
Groupes : alt.os.linux.ubuntu comp.sys.raspberry-pi alt.os.linux.mageiaSuivi-à : alt.os.linux.mageiaDate : 04. Apr 2024, 16:43:33
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uumhr4$o1bc$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : slrn/1.0.3 (Linux)
On 2024-04-04, Bud Frede <
frede@mouse-potato.com> wrote:
Marco Moock <mm+usenet-es@dorfdsl.de> writes:
>
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
>
?? 192.168.x.x is non-routable.
>
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
>
I always say that the RFC 1918 addresses are "not normally publicly
routed." :-)
>
As you say, they definitely _are_ routable, or a whole lot of home and
corporate networks would not be functional.
The key word is "publicly". Ie, once you get away from directly attached
networks (or internal routers you have specially set up within your
organization) and some outside router needs to be involved to get the
packet from here to there, then that router has no idea which of the
millions of networks with 192.168. to send the packet to.
In the case in question, there are two networks with the same 192.168.
network addresses. As mentioned the locally attached network should get
the nod. The claim is that it is not. Of course this is going by tun to
remote vpn. So if the local 192.168. addresses are being set up so that
those packets still get delivered through tun, then the "localy attached
network" could well be the remote one. Answer, tell your local machine
to deliver all 192.168 stuff not to tun but to a local router which
knows about your local 192.168.
>
I saw a video not too long ago that pointed out that the use of these
addresses and NAT was made widespread by the Cisco PIX. It was a pretty
interesting look back at something new that now seems commonplace and
ordinary.
>
>