Hello all,

here is what I've done in short:

First I wrote to openconnect mailinglist and got an email back, just
recommending to install "vpn-slice" instead.
This was not an answer to my question.

Next, after analyzing openconnect's behaviour, I found out that this one
does nothing about manipulating routing etc. This is solely done by "vpnc-
script", which is directly invoked from openconnect. And, hence, it
inherits all the env variables, which are not visible from outside.

So, I created a new "vpnc-script" file with content

#!/usr/bin/sh
env | sort

and set a symlink, so that openconnect invoked this one now. (Done in
foreground mode, i.e. no -b on commandline).

Watching its output I saw the more than hundred routes which are
transferred to the client via server-side "route push..." command.

They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total number,
i.e. the vector size is stored in $CISCO_SPLIT_EXC.

To prevent openconnect from accepting all that trash, I could easily set
this vector to empty, i.e. include

CISCO_SPLIT_EXC=''

as one the first commands in vpnc-script file, and, that's it!

The reason why Suse's approach, which I took to build my own vpnc rpm
from, and from which vpnc-script is taken from, does not accept all that
routes, is that in this version the whole section is not included.

If you are interested in seeing how they differ, you may have a look at
the vimdiff file I created:

https://www.dipl-ing-kessler.de/tmp/vpnc-script

This afternoon I tested above solution on Raspbian OS and it worked
instantly.

It took me some time to find out, but it was worth every minute :-)

Best regards,

Markus

On Mon, 1 Apr 2024 18:35:49 -0000 (UTC) Markus Robert Kessler wrote:

> Hi all,
>
> I am running several machines for connecting to our company intranet,
> using openconnect VPN.
>
> So far, it works. But:
>
> The debian based systems, i.e. Ubuntu 23.10 and Raspbian OS show up
> hundreds of routes after connect. And it's clear that they are brought
> to my client via server-initiated 'push route ...' command.
>
> Some of these routes are conflicting with machines in my home office
> net.
>
> So, I'd like to skip getting such a huge amount of useless routes. I
> want to set the routing by my own script, instead.
>
> The funny thing is that a Redhat-based OS, Mageia 9 (64 and 32 bit),
> does not behave like this, instead only the default route (10.0.0.0/8)
> is sent through tun0.
>
> So, maybe this is a matter of compilation?
>
> Or something else to look after, to prevent openconnect from doing this?
>
> Maybe someone can give a hint where to download the openconnect sources
> for Ubuntu?
>
> Thanks in advance!
>
> Best regards,
>
> Markus

On 2024-04-09, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
> Hello all,
>
> here is what I've done in short:
....
>
> They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total number,
And ${CISCO_SPLIT_EXC_${i}_MASK } and ${${CISCO_SPLIT_EXC_${i}_MASKLEN}

My problem is that what I get pushed is
CISCO_SPLIT_EXC_0_ADDR=0.0.0.0
CISCO_SPLIT_EXC_0_MASK=255.255.255.255
CISCO_SPLIT_EXC_0_MASKLEN=32
Ie, everything gets routed through tun, which is completely nuts.

I presume that I could just have a file with the list of addresses I
want sent through the tun, and include that in vpnc-script.
The problem is how do I decide what to include if I want to use a number
of different vpns.
Is it reasonably robust to use
CISCO_DEF_DOMAIN=ubc.ca
to decide which routing address file to use

Also, would a mask of 0.0.255.255 be MASKLENGTH of 32 or 16?

What I am thinking of is putting a line
source routes.${CISCO_DEF_DOMAIN}
at the beginning of the vpnc-script file

and have that file be full of the
CISCO_SPLIT_EXC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
CISCO_SPLIT_EXC at the end.
(with a test to make sure that the file exists before sourcing it)

That would seem to be much easier than the massive rewrite you did.

Would openconnect clean up the addresses that go through the tun when it
is stopped?

_

> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>
> To prevent openconnect from accepting all that trash, I could easily set
> this vector to empty, i.e. include
>
> CISCO_SPLIT_EXC=''
>
> as one the first commands in vpnc-script file, and, that's it!
>
> The reason why Suse's approach, which I took to build my own vpnc rpm
> from, and from which vpnc-script is taken from, does not accept all that
> routes, is that in this version the whole section is not included.
>
> If you are interested in seeing how they differ, you may have a look at
> the vimdiff file I created:
>
> https://www.dipl-ing-kessler.de/tmp/vpnc-script

White letters on light green is almost unreadable.
>
> This afternoon I tested above solution on Raspbian OS and it worked
> instantly.
>
> It took me some time to find out, but it was worth every minute :-)
>
> Best regards,
>
> Markus
>

On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:

> On 2024-04-09, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
> wrote:
>> Hello all,
>>
>> here is what I've done in short:
> ...
>>
>> They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total
>> number,
>
> And ${CISCO_SPLIT_EXC_${i}_MASK } and ${${CISCO_SPLIT_EXC_${i}_MASKLEN}
>
>
> My problem is that what I get pushed is CISCO_SPLIT_EXC_0_ADDR=0.0.0.0
> CISCO_SPLIT_EXC_0_MASK=255.255.255.255 CISCO_SPLIT_EXC_0_MASKLEN=32
> Ie, everything gets routed through tun, which is completely nuts.

Routes named as 'EXC' should be EXcluded from being routed through tun.
Don't know why the above behaves like that. Maybe there's another entry
for that reading 'INC'

> I presume that I could just have a file with the list of addresses I
> want sent through the tun, and include that in vpnc-script.

You could set the variables / source the relevant file, and
either overwrite the pushed variables and set new max index,
or append them to the inherited ones and adapt max index / vector size

> The problem is how do I decide what to include if I want to use a number
> of different vpns.

You could copy and create different sections for every vpn.

Or, use vpnc-script as a 'wrapper' file, which calls, for instance,
vpnc-script.ubc.ca for CISCO_DEF_DOMAIN=ubc.ca
and so on. Make sure that all env are available in the target scripts

> Is it reasonably robust to use CISCO_DEF_DOMAIN=ubc.ca to decide which
> routing address file to use
>
> Also, would a mask of 0.0.255.255 be MASKLENGTH of 32 or 16?

32, but this mask hardly makes sense

> What I am thinking of is putting a line source
> routes.${CISCO_DEF_DOMAIN}
> at the beginning of the vpnc-script file
>
> and have that file be full of the
> CISCO_SPLIT_EXC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
> CISCO_SPLIT_EXC at the end.
> (with a test to make sure that the file exists before sourcing it)
>
> That would seem to be much easier than the massive rewrite you did.

No big rewrite from my side. To fit my needs it was enough to just add ONE
line ( CISCO_SPLIT_EXC='' ) It just works for my company network

> Would openconnect clean up the addresses that go through the tun when it
> is stopped?

Openconnect is calling vpnc-script for several reasons, see line

#* reason -- why this script was called, one of:
pre-init connect disconnect reconnect attempt-reconnect

So, when openconnect is cleanly terminating (not kill -9 ...), it will
finally invoke vpnc-script with cause 'disconnect' and the original route
is being restored

> _
>
>
>> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>>
>> To prevent openconnect from accepting all that trash, I could easily
>> set this vector to empty, i.e. include
>>
>> CISCO_SPLIT_EXC=''
>>
>> as one the first commands in vpnc-script file, and, that's it!
>>
>> The reason why Suse's approach, which I took to build my own vpnc rpm
>> from, and from which vpnc-script is taken from, does not accept all
>> that routes, is that in this version the whole section is not included.
>>
>> If you are interested in seeing how they differ, you may have a look at
>> the vimdiff file I created:
>>
>> https://www.dipl-ing-kessler.de/tmp/vpnc-script
>
> White letters on light green is almost unreadable.

Yes, it's never easy to find a colorscheme in vimdiff which displays
everything perfectly. But you can always select the relevant section to
have blue on white text or vice versa

>> This afternoon I tested above solution on Raspbian OS and it worked
>> instantly.
>>
>> It took me some time to find out, but it was worth every minute :-)
>>
>> Best regards,
>>
>> Markus

Best regards,

Markus

On 2024-04-12, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
> On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:
>
>> On 2024-04-09, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
>> wrote:
>>> Hello all,
>>>
>>> here is what I've done in short:
>> ...
>>>
>>> They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total
>>> number,
>>
>> And ${CISCO_SPLIT_EXC_${i}_MASK } and ${${CISCO_SPLIT_EXC_${i}_MASKLEN}
>>
>>
>> My problem is that what I get pushed is CISCO_SPLIT_EXC_0_ADDR=0.0.0.0
>> CISCO_SPLIT_EXC_0_MASK=255.255.255.255 CISCO_SPLIT_EXC_0_MASKLEN=32
>> Ie, everything gets routed through tun, which is completely nuts.
>
> Routes named as 'EXC' should be EXcluded from being routed through tun.
> Don't know why the above behaves like that. Maybe there's another entry
> for that reading 'INC'

Yes, there is a similar set of entries with INC which I should have been
using. It is exactly same as EXC but with INC instead.
>
>> I presume that I could just have a file with the list of addresses I
>> want sent through the tun, and include that in vpnc-script.
>
> You could set the variables / source the relevant file, and
> either overwrite the pushed variables and set new max index,
> or append them to the inherited ones and adapt max index / vector size
>
>> The problem is how do I decide what to include if I want to use a number
>> of different vpns.
>
> You could copy and create different sections for every vpn.
>
> Or, use vpnc-script as a 'wrapper' file, which calls, for instance,
> vpnc-script.ubc.ca for CISCO_DEF_DOMAIN=ubc.ca
> and so on. Make sure that all env are available in the target scripts
>
>> Is it reasonably robust to use CISCO_DEF_DOMAIN=ubc.ca to decide which
>> routing address file to use
>>
>> Also, would a mask of 0.0.255.255 be MASKLENGTH of 32 or 16?
>
> 32, but this mask hardly makes sense
Agreed. I meant
255.255.0.0 Is that 16 or 32 ?

Anyway, it seems to be working.

>
>> What I am thinking of is putting a line source
>> routes.${CISCO_DEF_DOMAIN}
>> at the beginning of the vpnc-script file
>>
>> and have that file be full of the
>> CISCO_SPLIT_EXC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
CISCO_SPLIT_INC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
>> CISCO_SPLIT_EXC at the end.
CISCO_INC_EXC at the end.
>> (with a test to make sure that the file exists before sourcing it)
>>
>> That would seem to be much easier than the massive rewrite you did.
>
> No big rewrite from my side. To fit my needs it was enough to just add ONE
> line ( CISCO_SPLIT_EXC='' ) It just works for my company network
>
>> Would openconnect clean up the addresses that go through the tun when it
>> is stopped?

Yes, and it does work. All the tun routes disappear when I close
openconnect.
Is there some openconnect command that tells the running version to
quit?

>
> Openconnect is calling vpnc-script for several reasons, see line
>
> #* reason -- why this script was called, one of:
> pre-init connect disconnect reconnect attempt-reconnect
>
> So, when openconnect is cleanly terminating (not kill -9 ...), it will
> finally invoke vpnc-script with cause 'disconnect' and the original route
> is being restored
>
>> _
>>
>>
>>> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>>>
>>> To prevent openconnect from accepting all that trash, I could easily
>>> set this vector to empty, i.e. include
>>>
>>> CISCO_SPLIT_EXC=''
>>>
>>> as one the first commands in vpnc-script file, and, that's it!
>>>
>>> The reason why Suse's approach, which I took to build my own vpnc rpm
>>> from, and from which vpnc-script is taken from, does not accept all
>>> that routes, is that in this version the whole section is not included.
>>>
>>> If you are interested in seeing how they differ, you may have a look at
>>> the vimdiff file I created:
>>>
>>> https://www.dipl-ing-kessler.de/tmp/vpnc-script
>>
>> White letters on light green is almost unreadable.
>
> Yes, it's never easy to find a colorscheme in vimdiff which displays
> everything perfectly. But you can always select the relevant section to
> have blue on white text or vice versa
>
>>> This afternoon I tested above solution on Raspbian OS and it worked
>>> instantly.
>>>
>>> It took me some time to find out, but it was worth every minute :-)
>>>
>>> Best regards,
>>>
>>> Markus
>
> Best regards,
>
> Markus

On Fri, 12 Apr 2024 14:52:37 -0400, William Unruh <unruh@invalid.ca> wrote:
<snip>
> Agreed. I meant
> 255.255.0.0 Is that 16 or 32 ?

255.255.255.0 is a /24 meaning only the last 8 bits (octet) of the address changes.
The first 24 bits of the 32 bit address are fixed.

255.255.0.0 is a /16
255.0.0.0 is a /8

A /32 would be written as a netmask of 255.255.255.255, in which case only one
ip address is in the selected range.

That's for an ipv4 network. For ipv6 there are 128 bits instead of 32.

Regards, Dave Hodgins

On Fri, 12 Apr 2024 18:52:37 -0000 (UTC) William Unruh wrote:

> On 2024-04-12, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
> wrote:
>> On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:
>>
>>> On 2024-04-09, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
>>> wrote:
>>>> Hello all,
>>>>
>>>> here is what I've done in short:
>>> ...
>>>>
>>>> They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total
>>>> number,
>>>
>>> And ${CISCO_SPLIT_EXC_${i}_MASK } and
>>> ${${CISCO_SPLIT_EXC_${i}_MASKLEN}
>>>
>>>
>>> My problem is that what I get pushed is CISCO_SPLIT_EXC_0_ADDR=0.0.0.0
>>> CISCO_SPLIT_EXC_0_MASK=255.255.255.255 CISCO_SPLIT_EXC_0_MASKLEN=32
>>> Ie, everything gets routed through tun, which is completely nuts.
>>
>> Routes named as 'EXC' should be EXcluded from being routed through tun.
>> Don't know why the above behaves like that. Maybe there's another entry
>> for that reading 'INC'
>
> Yes, there is a similar set of entries with INC which I should have been
> using. It is exactly same as EXC but with INC instead.
>>
>>> I presume that I could just have a file with the list of addresses I
>>> want sent through the tun, and include that in vpnc-script.
>>
>> You could set the variables / source the relevant file, and either
>> overwrite the pushed variables and set new max index,
>> or append them to the inherited ones and adapt max index / vector size
>>
>>> The problem is how do I decide what to include if I want to use a
>>> number of different vpns.
>>
>> You could copy and create different sections for every vpn.
>>
>> Or, use vpnc-script as a 'wrapper' file, which calls, for instance,
>> vpnc-script.ubc.ca for CISCO_DEF_DOMAIN=ubc.ca and so on. Make sure
>> that all env are available in the target scripts
>>
>>> Is it reasonably robust to use CISCO_DEF_DOMAIN=ubc.ca to decide which
>>> routing address file to use
>>>
>>> Also, would a mask of 0.0.255.255 be MASKLENGTH of 32 or 16?
>>
>> 32, but this mask hardly makes sense
> Agreed. I meant 255.255.0.0 Is that 16 or 32 ?

As Dave already mentioned, this should be 16

> Anyway, it seems to be working.
>
>
>
>>> What I am thinking of is putting a line source
>>> routes.${CISCO_DEF_DOMAIN}
>>> at the beginning of the vpnc-script file
>>>
>>> and have that file be full of the
>>> CISCO_SPLIT_EXC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
> CISCO_SPLIT_INC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
>>> CISCO_SPLIT_EXC at the end.
> CISCO_INC_EXC at the end.
>>> (with a test to make sure that the file exists before sourcing it)
>>>
>>> That would seem to be much easier than the massive rewrite you did.
>>
>> No big rewrite from my side. To fit my needs it was enough to just add
>> ONE line ( CISCO_SPLIT_EXC='' ) It just works for my company network
>>
>>> Would openconnect clean up the addresses that go through the tun when
>>> it is stopped?
>
> Yes, and it does work. All the tun routes disappear when I close
> openconnect.
> Is there some openconnect command that tells the running version to
> quit?

No, not from openconnect's side.

Instead, when openconnect runs in foreground mode ( i.e. not being started
with -b ), it can be terminated cleanly with CTRL-C.

Alternatively, vpnc-disconnect ( out of vpnc package ) can be used, as
long as openconnect writes the same pid file, which vpnc-disconnect takes
the pid number from to ( also cleanly ) terminate the process.

In my case, I start it like so:

sudo openconnect --pid-file /var/run/vpnc.pid -b ...
( on debian based systems the path and filename may differ ),
hence, I can easily end it with vpnc-disconnect.

>
>> Openconnect is calling vpnc-script for several reasons, see line
>>
>> #* reason -- why this script was called, one of:
>> pre-init connect disconnect reconnect attempt-reconnect
>>
>> So, when openconnect is cleanly terminating (not kill -9 ...), it will
>> finally invoke vpnc-script with cause 'disconnect' and the original
>> route is being restored
>>
>>> _
>>>
>>>
>>>> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>>>>
>>>> To prevent openconnect from accepting all that trash, I could easily
>>>> set this vector to empty, i.e. include
>>>>
>>>> CISCO_SPLIT_EXC=''
>>>>
>>>> as one the first commands in vpnc-script file, and, that's it!
>>>>
>>>> The reason why Suse's approach, which I took to build my own vpnc rpm
>>>> from, and from which vpnc-script is taken from, does not accept all
>>>> that routes, is that in this version the whole section is not
>>>> included.
>>>>
>>>> If you are interested in seeing how they differ, you may have a look
>>>> at the vimdiff file I created:
>>>>
>>>> https://www.dipl-ing-kessler.de/tmp/vpnc-script
>>>
>>> White letters on light green is almost unreadable.
>>
>> Yes, it's never easy to find a colorscheme in vimdiff which displays
>> everything perfectly. But you can always select the relevant section to
>> have blue on white text or vice versa
>>
>>>> This afternoon I tested above solution on Raspbian OS and it worked
>>>> instantly.
>>>>
>>>> It took me some time to find out, but it was worth every minute :-)

Best regards,

Markus

On 2024-04-13, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
> On Fri, 12 Apr 2024 18:52:37 -0000 (UTC) William Unruh wrote:
>
>> On 2024-04-12, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
>> wrote:
>>> On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:
>>>
>
> No, not from openconnect's side.
>
> Instead, when openconnect runs in foreground mode ( i.e. not being started
> with -b ), it can be terminated cleanly with CTRL-C.

So I presume that openconnect sends a disconnect to vpnc-script to tear
down the routes through tun.

>
> Alternatively, vpnc-disconnect ( out of vpnc package ) can be used, as
> long as openconnect writes the same pid file, which vpnc-disconnect takes
> the pid number from to ( also cleanly ) terminate the process.
>

OK, that's a good suggestion.

I have now implimented my idea on two different vpns -- one at UBC and
ont at tamu, and it seems to work on both. Of course if a web page in
either links to something outside their address space that I specified
in the altered lines in the vpnc-script, then that goes through the
original connection. If I wanted to view US netflix programs from
Canada, that would not work, since netflix would see the packets as
coming from Canada, rather then the US. So, some way of adding to the
list of the IP addresses that the connections tunnels dynamically would
be good. But I guess I can always use ip commend to add routes to my
systems routing table through tun.

The alternative, that everything gets routed through tun really is not
very good (never mind that all connections I have to any outside
computers get broken when I start the openconnect connection.

Anyway, thanks for pointing me to the way to get this working.
> In my case, I start it like so:
>
> sudo openconnect --pid-file /var/run/vpnc.pid -b ...
> ( on debian based systems the path and filename may differ ),
> hence, I can easily end it with vpnc-disconnect.
>
>>
>>> Openconnect is calling vpnc-script for several reasons, see line
>>>
>>> #* reason -- why this script was called, one of:
>>> pre-init connect disconnect reconnect attempt-reconnect
>>>
>>> So, when openconnect is cleanly terminating (not kill -9 ...), it will
>>> finally invoke vpnc-script with cause 'disconnect' and the original
>>> route is being restored
>>>
>>>> _
>>>>
>>>>
>>>>> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>>>>>
>>>>> To prevent openconnect from accepting all that trash, I could easily
>>>>> set this vector to empty, i.e. include
>>>>>
>>>>> CISCO_SPLIT_EXC=''
>>>>>
>>>>> as one the first commands in vpnc-script file, and, that's it!
>>>>>
>>>>> The reason why Suse's approach, which I took to build my own vpnc rpm
>>>>> from, and from which vpnc-script is taken from, does not accept all
>>>>> that routes, is that in this version the whole section is not
>>>>> included.
>>>>>
>>>>> If you are interested in seeing how they differ, you may have a look
>>>>> at the vimdiff file I created:
>>>>>
>>>>> https://www.dipl-ing-kessler.de/tmp/vpnc-script
>>>>
>>>> White letters on light green is almost unreadable.
>>>
>>> Yes, it's never easy to find a colorscheme in vimdiff which displays
>>> everything perfectly. But you can always select the relevant section to
>>> have blue on white text or vice versa
>>>
>>>>> This afternoon I tested above solution on Raspbian OS and it worked
>>>>> instantly.
>>>>>
>>>>> It took me some time to find out, but it was worth every minute :-)
>
> Best regards,
>
> Markus

In article <uui04k$3f9re$1@dont-email.me>,
William Unruh <unruh@invalid.ca> wrote:
>On 2024-04-02, Scott Alfter <scott@alfter.diespammersdie.us> wrote:
>> In article <uuf01e$2lb63$1@dont-email.me>,
>> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>>>On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
>>>> So, I'd like to skip getting such a huge amount of useless routes. I
>>>> want to set the routing by my own script, instead.
>>>
>>>NetworkManager has an option to ignore routes from the peer.
>>>Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore
>>>automatically obtained routes
>>
>> The Cisco ASA at work pushes some routes to my computer when I connect to
>> it. One of them (for a remote office) uses the same 192.168.1.0/24 subnet
>> as my home network, so I lose access to my file server, printers, etc. at
>> home when I'm connected to the VPN. I'd been considering moving my home
>> network to a different subnet, but this would be easier...will have to look
>> into it.
>
>?? 192.168.x.x is non-routable.

I probably should've explained the situation. At work, the main office uses
172.16.0.0/22. A satellite office a few blocks away uses 192.168.1.0/24; a
static route is added to the handful of desktops that need to talk to hosts
over there. At home, my personal network also uses 192.168.1.0/24.
Connecting to the VPN from home causes my home server, printers, etc. to
become inaccessible as a result, as traffic for 192.168.1.0/24 gets routed
to the satellite office.

The ability to ignore some of the routes provided by the VPN would be nice,
as I don't need to deal with stuff at the satellite office 99% of the time.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

In article <uujalb$3rv5p$2@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 02/04/2024 23:16, William Unruh wrote:
>> ?? 192.168.x.x is non-routable. Ie, unless you are directly connected to
>> the network you cannot access it. Is your home on the same physical net
>> as that remote office? Otherwise I do not see how tht could do anything
>> to your attachment to the home network.
>
>192.168.x.x is routable.
>
>It just isn't something that the Internet routes, by convention.
>It can be routed via a VPN.
>
>It is a good argument for changing his home IP network to something else.

That's also something I've considered. My home router's a Raspberry Pi CM4
on a carrier board that adds a second Ethernet jack, running OpenWRT. I've
thought about downloading the config, changing all occurrences of 192.168.1.
to 192.168.100. (or whatever), and uploading the changed config, but have
been a bit nervous about it (especially since the WAF of a downed network is
pretty low :-) ).

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

scott@alfter.diespammersdie.us (Scott Alfter) writes:

> That's also something I've considered. My home router's a Raspberry Pi CM4
> on a carrier board that adds a second Ethernet jack, running OpenWRT.

Just curious but which carrier board? Is there a case too?