Mixing public and private IPs on a home LAN

[bob prohaska]

I'm presently using an old Cayman 3546 to support both public
and private hosts on a home network. The Cayman is getting old,
a more modern replacement is likely to be needed before too much
longer; it's been in continuous service since about 2004.

At the moment I have a single 192.168.x.y network, using one-to-one
NAT to map public addresses to the private IPs of the servers.
Routers that offer one-to-one NAT don't seem all that common, so
I'm curious about alternatives.

The service I have is 8 static IPs on an RFC-1483 bridged connection.
An obvious scheme is to connect a switch to a bridged modem, hook the
servers to the switch using their public addresses and connect a router
using one public address to the switch to provide private networking.
That's three boxes, though, and I'm unclear on how to administer the
modem once it's in bridge mode, since its ethernet port will be in the
public address space.

Another alternative is to find a router like the Cayman, with one-to-one
NAT. That feature doesn't seem widely advertised, however.

I'm also unclear on the relative merits of a separate switch and router,
or a combined unit. Here in the USA it seems that all DSL hardware is
getting scarce, so choices are limited, sometimes to used offerings.

Thanks for reading, and any ideas!

bob prohaska

[Grant Taylor]

On 3/5/19 6:26 PM, bob prohaska wrote:
> I'm presently using an old Cayman 3546 to support both public and
> private hosts on a home network. The Cayman is getting old, a more modern
> replacement is likely to be needed before too much longer; it's been in
> continuous service since about 2004.

Is there an actual /need/ to replace the Cayman yet? Or are you just
exploring future options?

A /desire/ to replace it is perfectly fine too. Just call it what it is.

> The service I have is 8 static IPs on an RFC-1483 bridged connection.

Do you have eight random IPs out of a larger network? Or do you have a
subnet that is routed to you via another IP on the outside of your modem?

I've seen both, and it makes a difference from a networking point of view.

Can you use all eight IPs? Or can you only use six of them, one of
which has to be assigned to the modem / router facing the ISP?

> An obvious scheme is to connect a switch to a bridged modem, hook the
> servers to the switch using their public addresses and connect a router
> using one public address to the switch to provide private networking.

You can do that.

> That's three boxes, though, and I'm unclear on how to administer the
> modem once it's in bridge mode, since its ethernet port will be in the
> public address space.

It will depend on the modem.

> Another alternative is to find a router like the Cayman, with one-to-one
> NAT. That feature doesn't seem widely advertised, however.

You might be able to find a router that will allow you to use private
IPs on the inside and host (/32) routes to the public IPs via server's
static IPs on the internal LAN. (You'd bind the public IP as a /32 to a
loopback adapter on the server.)

There's nothing wrong with having the private IPs route across an
unrouted network.

> I'm also unclear on the relative merits of a separate switch and router,
> or a combined unit.

It largely depends on the features of each unit and what you want.

> Here in the USA it seems that all DSL hardware is getting scarce, so
> choices are limited, sometimes to used offerings.

I've not looked at acquiring (contemporary) DSL equipment here in the US
in about a decade.

Anything I've looked at has been older for retro networking across phone
lines hanging off of an internal analog PBX.

> Thanks for reading, and any ideas!

I don't know how familiar you are with Linux. IMHO Linux can do all of
what's in your email and my reply.

Linux can even do something called a "Bridging Router" in that one
""router routes some traffic while bridges other. So your internal
servers could think they are directly connected to the public network
and the private network at the same time via an IP from each. Your
other internal clients would be routed, with NAT, like they are now. An
added bonus is that you can apply firewall rules to the bridged traffic
to your servers.



--
Grant. . . .
unix || die

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/5/19 6:26 PM, bob prohaska wrote:
>> I'm presently using an old Cayman 3546 to support both public and
>> private hosts on a home network. The Cayman is getting old, a more modern
>> replacement is likely to be needed before too much longer; it's been in
>> continuous service since about 2004.
>
> Is there an actual /need/ to replace the Cayman yet? Or are you just
> exploring future options?
>

For now, I'm just exploring future options.

> A /desire/ to replace it is perfectly fine too. Just call it what it is.

The ISP wants me to upgrade to an ADSL2+ modem, saying it'll improve
connection reliability. Reliability isn't terrible, added speed isn't
necessary, but better noise margin couldn't hurt. And, the old modem
has been running 24/7 for fourteen years.

>> The service I have is 8 static IPs on an RFC-1483 bridged connection.
>
> Do you have eight random IPs out of a larger network? Or do you have a
> subnet that is routed to you via another IP on the outside of your modem?

Seems to be 8 sequential IPs out of a larger subnet. The netmask is 255.255.255.0

> I've seen both, and it makes a difference from a networking point of view.
>
> Can you use all eight IPs? Or can you only use six of them, one of
> which has to be assigned to the modem / router facing the ISP?

I can use seven, plus one for the router

>> An obvious scheme is to connect a switch to a bridged modem, hook the
>> servers to the switch using their public addresses and connect a router
>> using one public address to the switch to provide private networking.

> You can do that.

Will it be "better" in some way than one-to-one NAT, apart fron not needing
a router that supports one-to-one NAT (which alone is helpful).

>> That's three boxes, though, and I'm unclear on how to administer the
>> modem once it's in bridge mode, since its ethernet port will be in the
>> public address space.
>
> It will depend on the modem.
>
>> Another alternative is to find a router like the Cayman, with one-to-one
>> NAT. That feature doesn't seem widely advertised, however.
>
> You might be able to find a router that will allow you to use private
> IPs on the inside and host (/32) routes to the public IPs via server's
> static IPs on the internal LAN. (You'd bind the public IP as a /32 to a
> loopback adapter on the server.)

Not sure I understand this; my servers use 127.0.0.1 as a loopback address.
Are you saying they'd use their public IPs for that purpose as well?

> There's nothing wrong with having the private IPs route across an
> unrouted network.
>
>> I'm also unclear on the relative merits of a separate switch and router,
>> or a combined unit.
>
> It largely depends on the features of each unit and what you want.

The goal is to have public servers and private workstations on the
end of one DSL circuit. The servers (web, mail and name) need to be
accessible from the private network as well. The private workstations
likewise need access to both my servers and the rest of the net.

I'd also like to minimize cost and power consumption. The servers are
all Raspberry Pi 2, probably to be replaced by Pi3's as 32 bit fades.
The workstations are a Pi3 and a couple of elderly Macs that are off
when unused. No gaming, no streaming, so speed isn't an issue.

> I've not looked at acquiring (contemporary) DSL equipment here in the US
> in about a decade.

I bought DSL service and equipment from AT&T in 2004. It just worked and I
never explored it carefully, so I'm entering a whole new world

> Anything I've looked at has been older for retro networking across phone
> lines hanging off of an internal analog PBX.

I like the idea of preserving old equipment that's still useful, but time
takes its toll. Sometimes progress happens also 8-)

> I don't know how familiar you are with Linux. IMHO Linux can do all of
> what's in your email and my reply.

That's fully understood. A router using openWRT, or at least one that supports
it, would be welcome. One problem is identifying good candidate hardware.

> Linux can even do something called a "Bridging Router" in that one
> ""router routes some traffic while bridges other. So your internal
> servers could think they are directly connected to the public network
> and the private network at the same time via an IP from each. Your
> other internal clients would be routed, with NAT, like they are now. An
> added bonus is that you can apply firewall rules to the bridged traffic
> to your servers.

That appears to be what the Cayman does now; I can assign a public IP to
one of my servers and it can communicate outside. Meanwhile the other
servers and workstations can use NAT. It seems to have trouble talking
to the private net, but that's likely my fault.

I'd like to stick with commodity hardware. The immediate issue seems to
be the modem, which I gather doesn't exist in an "open source" form.

Thanks for reading and any further thoughts!

bob prohaska

[Grant Taylor]

On 3/7/19 11:16 AM, bob prohaska wrote:
> For now, I'm just exploring future options.

Fair enough.

I think exploration and learning what options exist is always a good thing.

> The ISP wants me to upgrade to an ADSL2+ modem, saying it'll improve
> connection reliability. Reliability isn't terrible, added speed isn't
> necessary, but better noise margin couldn't hurt. And, the old modem
> has been running 24/7 for fourteen years.

Fair. If it was me, I'd upgrade.

But if it's working for you and you're happy.... You decide what you
want to do.

> Seems to be 8 sequential IPs out of a larger subnet. The netmask is
> 255.255.255.0

That makes the networking side of my brain ~twitch~.

Okay.

> I can use seven, plus one for the router

ACK

> Will it be "better" in some way than one-to-one NAT, apart fron not
> needing a router that supports one-to-one NAT (which alone is helpful).

IMHO, no. I think it's actually worse. I say this because the servers
are exposed to the internet without any L3 filtering. I find this to be
a bad idea.

There are options to do L3 filtering on L2. (EBTables comes to mind.)

I generally prefer to have an L3 router / firewall at my edge unless I
have a very specific reason to not do so.

> Not sure I understand this; my servers use 127.0.0.1 as a loopback
> address. Are you saying they'd use their public IPs for that purpose
> as well?

Your servers would use static private IPs. The router would route the
given external IP via said static IP. The server would have said public
IP bound to a network interface.

Said network interface is frequently called a "loopback" but it does not
have to be and is usually different than the ""interface (if there is
one) that holds the 127.0.0.1/8 network.

You can create dummy interfaces in Linux. You can add what are called
"Loopback" interfaces to Windows. These show up as additional network
interfaces.

Note: The last time I looked, Windows didn't actually have an interface
with 127.0.0.1/8 bound to it. Instead it's a software / routing construct.

> The goal is to have public servers and private workstations on the end of
> one DSL circuit. The servers (web, mail and name) need to be accessible
> from the private network as well. The private workstations likewise need
> access to both my servers and the rest of the net.

There are many ways to do that.

> I'd also like to minimize cost and power consumption. The servers are
> all Raspberry Pi 2, probably to be replaced by Pi3's as 32 bit fades.
> The workstations are a Pi3 and a couple of elderly Macs that are off
> when unused. No gaming, no streaming, so speed isn't an issue.

This doesn't make /much/ difference in the networking. About the only
thing it does change is if you are looking for Gig Ether or 100 Meg
Ether. But that's largely immaterial to the network configuration.
Maybe equipment acquisition.

I suspect the biggest difference will be the number of ports in a switch
that's part of the modem. (If you go that route.)

> I bought DSL service and equipment from AT&T in 2004. It just worked
> and I never explored it carefully, so I'm entering a whole new world

Fair enough.

It sounds like you've had good service with what you bought and got your
money's worth out of it.

> I like the idea of preserving old equipment that's still useful, but
> time takes its toll. Sometimes progress happens also 8-)

I'm used to surges destroying equipment in that time frame.
Particularly DSL / Cable modems. Sometimes switches.

> That's fully understood. A router using openWRT, or at least one that
> supports it, would be welcome. One problem is identifying good candidate
> hardware.

How many ports at what speed are you wanting?

Would you prefer the modem also contain the switch? Or do you want
separate?

What do you think your ideal situation is? Why do you think that?

I ask more trying to learn your use case than to question what you're doing.

> That appears to be what the Cayman does now; I can assign a public IP to
> one of my servers and it can communicate outside. Meanwhile the other
> servers and workstations can use NAT. It seems to have trouble talking
> to the private net, but that's likely my fault.

Do your servers also have a private IP? Or do they only have the public IP?

> I'd like to stick with commodity hardware. The immediate issue seems to
> be the modem, which I gather doesn't exist in an "open source" form.

I'm sure there are FCC (et al) restrictions that are applied to modems /
firmware (particularly in the wireless RF space). But I would think
that /something/ would exist /somewhere/. I have no idea what or where.

> Thanks for reading and any further thoughts!

You're welcome.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/7/19 11:16 AM, bob prohaska wrote:
>> For now, I'm just exploring future options.
>
> Fair enough.
>
> I think exploration and learning what options exist is always a good thing.
>
>> The ISP wants me to upgrade to an ADSL2+ modem, saying it'll improve
>> connection reliability. Reliability isn't terrible, added speed isn't
>> necessary, but better noise margin couldn't hurt. And, the old modem
>> has been running 24/7 for fourteen years.
>
> Fair. If it was me, I'd upgrade.

I will upgrade eventually.

> But if it's working for you and you're happy.... You decide what you
> want to do.

I want to know what I'm doing slightly better than I do now 8-)

>> Seems to be 8 sequential IPs out of a larger subnet. The netmask is
>> 255.255.255.0
>
> That makes the networking side of my brain ~twitch~.
>
> Okay.
>
>> I can use seven, plus one for the router
>
> ACK
>

I gather this isn't an ideal setup in your view...is it worth taking
up with my ISP? I think they'll be responsive to well-phrased questions.

[now referring to bridging, as opposed to one-to-one NAT]

>> Will it be "better" in some way than one-to-one NAT, apart fron not
>> needing a router that supports one-to-one NAT (which alone is helpful).
>
> IMHO, no. I think it's actually worse. I say this because the servers
> are exposed to the internet without any L3 filtering. I find this to be
> a bad idea.
>
> There are options to do L3 filtering on L2. (EBTables comes to mind.)
>
> I generally prefer to have an L3 router / firewall at my edge unless I
> have a very specific reason to not do so.
>

It's unclear if my bridge sees all traffic on the entire subnet; I'd expect
the ISP to filter out extraneous packets but I've never asked.

>> Not sure I understand this; my servers use 127.0.0.1 as a loopback
>> address. Are you saying they'd use their public IPs for that purpose
>> as well?
>
> Your servers would use static private IPs. The router would route the
> given external IP via said static IP. The server would have said public
> IP bound to a network interface.
>
> Said network interface is frequently called a "loopback" but it does not
> have to be and is usually different than the ""interface (if there is
> one) that holds the 127.0.0.1/8 network.
>
> You can create dummy interfaces in Linux. You can add what are called
> "Loopback" interfaces to Windows. These show up as additional network
> interfaces.
>
> Note: The last time I looked, Windows didn't actually have an interface
> with 127.0.0.1/8 bound to it. Instead it's a software / routing construct.
>

>> The goal is to have public servers and private workstations on the end of
>> one DSL circuit. The servers (web, mail and name) need to be accessible
>> from the private network as well. The private workstations likewise need
>> access to both my servers and the rest of the net.
>
> There are many ways to do that.

In a sense that's part of my trouble; too many ways to skin the same cat.

>
>> I'd also like to minimize cost and power consumption. The servers are
>> all Raspberry Pi 2, probably to be replaced by Pi3's as 32 bit fades.
>> The workstations are a Pi3 and a couple of elderly Macs that are off
>> when unused. No gaming, no streaming, so speed isn't an issue.
>
> This doesn't make /much/ difference in the networking. About the only
> thing it does change is if you are looking for Gig Ether or 100 Meg
> Ether. But that's largely immaterial to the network configuration.
> Maybe equipment acquisition.

For my purposes, 10 Meg is actually fast enough.

> I suspect the biggest difference will be the number of ports in a switch
> that's part of the modem. (If you go that route.)
>

The modem/routers I've contemplated have four switch ports unless I want
commercial grade equipment, which seems extravagant.

>> I bought DSL service and equipment from AT&T in 2004. It just worked
>> and I never explored it carefully, so I'm entering a whole new world
>
> Fair enough.
>
> It sounds like you've had good service with what you bought and got your
> money's worth out of it.
>

I think so.

>> I like the idea of preserving old equipment that's still useful, but
>> time takes its toll. Sometimes progress happens also 8-)
>
> I'm used to surges destroying equipment in that time frame.
> Particularly DSL / Cable modems. Sometimes switches.
>

Lost one switch to age and heat, but that's all.

>> That's fully understood. A router using openWRT, or at least one that
>> supports it, would be welcome. One problem is identifying good candidate
>> hardware.
>
> How many ports at what speed are you wanting?

Right now I have seven wired Ethernet devices. Whether they are
split between public and private networks, or all private, depends
on how/if NAT is employed.

> Would you prefer the modem also contain the switch? Or do you want
> separate?

In priciple separate seems more flexible. In practice I'm not sure it
matters.

>
> What do you think your ideal situation is? Why do you think that?
>

That's a big part of what I'm trying to figure out. In the original setup
I was happy to have anything that worked. Now that I'm being pushed to
upgrade there's a chance to optimize, but "better is the enemy of good
enough" and I'm wary of that trap.

> I ask more trying to learn your use case than to question what you're doing.
>

Understood. I started the project years ago as an educational hobby and
have come to rely on it. I'd like to avoid internet services that support
themselves by data mining.

>> That appears to be what the Cayman does now; I can assign a public IP to
>> one of my servers and it can communicate outside. Meanwhile the other
>> servers and workstations can use NAT. It seems to have trouble talking
>> to the private net, but that's likely my fault.
>
> Do your servers also have a private IP? Or do they only have the public IP?
>

Right now the servers have private IP and rely on the modem/router to translate
the private IPs to and from the corresponding public ones. I'm in the process of
changing two test hosts to use public IPs that pass directly through the bridged
modem/router to the ISP's default gateway. If that works I can get by without
one-to-one NAT, but I gather that might not be an improvement in your view.

>
> I'm sure there are FCC (et al) restrictions that are applied to modems /
> firmware (particularly in the wireless RF space). But I would think
> that /something/ would exist /somewhere/. I have no idea what or where.

The ISP offers SmartRG modems and routers for a $60 deposit. When I objected
to the paucity of manuals they suggested TP-Link products, which do seem to
have reasonably informative manuals. A commercial modem with a router that
supports either openWRT or DD-wrt looks like a plausible combination.

Thanks again for reading, all thoughts welcome!

bob prohaska

[Grant Taylor]

On 3/8/19 5:52 PM, bob prohaska wrote:
> I will upgrade eventually.

>
> I want to know what I'm doing slightly better than I do now 8-)

*ASCIItumbsUp*

> I gather this isn't an ideal setup in your view...

Eh.... I think it's unclean from a subneting point of view.

There's nothing wrong with it per say. I just don't care for it. As in
personal opinion.

It does complicate things a little bit in that you have to have some
form of layer 2 connectivity between the equipment with the IPs and the
ISP. It's not a traditional routed situation.

So, you are going to need something like bridging / proxy ARP / NATing.

> is it worth taking up with my ISP?

I doubt it.

The ISPs that I've seen either use traditional subneting & routing -or-
what your ISP is going. The two configurations are different and
usually aren't interchangeable.

Sort of like Metric and English bolts aren't interchangeable. They can
both do the job. But tooling / documentation / administrative
interfaces are usually geared towards one or the other and don't like
switching.

You can ask about a routed /29 via the outside of your router. But I
wouldn't hold my breath.

Even then, you'd only have 6 (5) usable IPs (one for the router).

> I think they'll be responsive to well-phrased questions.

I don't even know what question to ask, much less how to phrase it well.

If this is working, I think there are other better things to spend time on.

You might inquire what their current solution is for multiple IPs.
Their preferred solution might have changed since you set things up.

> [now referring to bridging, as opposed to one-to-one NAT]
>

> It's unclear if my bridge sees all traffic on the entire subnet; I'd
> expect the ISP to filter out extraneous packets but I've never asked.

I would not expect that.

Depending on the technology, DSL / Cable Modem / other, your WAN
interface will likely see at least broadcast traffic for other systems.
It will also likely see externally initiated traffic to your IPs,
especially since you have a block used for servers.

I would expect that there is quite a bit of noise / other traffic that
you'd prefer wasn't on the WAN interface.

Much of this noise falls into the broad category of "Internet Background
Radiation".

> In a sense that's part of my trouble; too many ways to skin the same cat.

I understand. I frequently have to play with puzzle pieces, turn them
over, spin them around, find what I like and try putting them together.

> For my purposes, 10 Meg is actually fast enough.

Cool.

So anything that does 10 Mbps or better is acceptable to you. That
means that there are more choices than if you wanted 1 Gbps. But that's
okay.

> The modem/routers I've contemplated have four switch ports unless I
> want commercial grade equipment, which seems extravagant.

ACK

I think I've seen routers, sans modem, that had eight ports for the LAN
and one port for the WAN.

How many devices do you need to connect now? How many spare ports would
you like to have?

Is four enough? Or do you want more?

Can a switch / router / modem combo provide enough ports? Or are you
looking at an external switch anyway?

> I think so.

:-)

> Lost one switch to age and heat, but that's all.

IMHO that's actually quite good.

> Right now I have seven wired Ethernet devices. Whether they are split
> between public and private networks, or all private, depends on how/if
> NAT is employed.

ACK

So a single four port switch is not going to suffice for your current
needs, much less give growth opportunity.

> In priciple separate seems more flexible. In practice I'm not sure
> it matters.

It sounds like eight LAN ports is your minimum. I don't know if a
switch / router / modem exists that has all of that. So you may have to
have an external switch or modem.

Note: My ignorance of such a device does not preclude it from existing.

> That's a big part of what I'm trying to figure out. In the original setup
> I was happy to have anything that worked. Now that I'm being pushed to
> upgrade there's a chance to optimize, but "better is the enemy of good
> enough" and I'm wary of that trap.

Fair.

I often but heads with that.

So let me ask you the question I ask myself / used to ask my clients.

Is there anything you wanted to do but were unable to do with your
current configuration?

Is there anything you have been pondering and would like to do if the
new configuration allowed it?

> Understood. I started the project years ago as an educational hobby
> and have come to rely on it. I'd like to avoid internet services that
> support themselves by data mining.

Fair enough.

> Right now the servers have private IP and rely on the modem/router
> to translate the private IPs to and from the corresponding public
> ones. I'm in the process of changing two test hosts to use public IPs
> that pass directly through the bridged modem/router to the ISP's default
> gateway. If that works I can get by without one-to-one NAT, but I gather
> that might not be an improvement in your view.

It depends on the network topology. I would rather have something to
provide some control over the connections to the IPs.

This is another reason that I like the actual routed subnet. I can more
easily move it elsewhere in my network.

> The ISP offers SmartRG modems and routers for a $60 deposit. When I
> objected to the paucity of manuals they suggested TP-Link products,
> which do seem to have reasonably informative manuals. A commercial
> modem with a router that supports either openWRT or DD-wrt looks like
> a plausible combination.

I've been happy with my TP-Link equipment (switches).

> Thanks again for reading, all thoughts welcome!

[bob prohaska]

[trimmed a little, hopefully for clarity]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/8/19 5:52 PM, bob prohaska wrote:

[on bridging vs subnetting]

>> I gather this isn't an ideal setup in your view...
>
> Eh.... I think it's unclean from a subneting point of view.
>
> There's nothing wrong with it per say. I just don't care for it. As in
> personal opinion.
>
> It does complicate things a little bit in that you have to have some
> form of layer 2 connectivity between the equipment with the IPs and the
> ISP. It's not a traditional routed situation.
>
> So, you are going to need something like bridging / proxy ARP / NATing.
>

I'm thinking that can't be helped....there isn't (yet) an Ethernet jack
in every home 8-)

>> is it worth taking up with my ISP?
>
> I doubt it.
>
> The ISPs that I've seen either use traditional subneting & routing -or-
> what your ISP is going. The two configurations are different and
> usually aren't interchangeable.
>

[snip]

>
> You can ask about a routed /29 via the outside of your router. But I
> wouldn't hold my breath.
>
> Even then, you'd only have 6 (5) usable IPs (one for the router).
>

That is what I had formerly with AT&T: The Cayman was configured with PPPoE,
a login and password. 8 IPs, one for netmask, one for broadcast address,
one for the router, 5 for me.

The new ISP is using something called RFC-1483 bridging. There is no login or
password, all outbound traffic goes to the ISP's gateway. The Cayman occupies
one public address for its internal router and uses that to support a private
network. It will also do static NAT between public and private addresses.

>
> You might inquire what their current solution is for multiple IPs.
> Their preferred solution might have changed since you set things up.
>

Bridging was what they preferred a year ago when I transferred my
service from AT&T. I asked for minimal changes, bridging was what
I got, using eight consecutive IP's. I'd rather not rock the boat
further without good cause.

>> [now referring to bridging, as opposed to one-to-one NAT]
>>
>> It's unclear if my bridge sees all traffic on the entire subnet; I'd
>> expect the ISP to filter out extraneous packets but I've never asked.
>
> I would not expect that.
>
> Depending on the technology, DSL / Cable Modem / other, your WAN
> interface will likely see at least broadcast traffic for other systems.

Ok, that's noise.

> It will also likely see externally initiated traffic to your IPs,
> especially since you have a block used for servers.
>

That I'd call signal.

> I would expect that there is quite a bit of noise / other traffic that
> you'd prefer wasn't on the WAN interface.
>

I've done a preliminary experiment using two hosts set to use public
IPs and default route that points to the ISP's gateway. If I run
arp -a on each of those hosts they don't see each other, only the
ISP's gateway address, their own address and my router's public
address. Each can ping the other and outside, so connectivity is ok,
but I thought they'd report arp entries for every other host on the
visible subnet. This isn't a traffic measurement, but I thought
it might be at least a traffic source count. The sources are few.

Running arp -a on my private net all the hosts show up, which is
what I expected.

>
> So anything that does 10 Mbps or better is acceptable to you. That
> means that there are more choices than if you wanted 1 Gbps. But that's
> okay.
>
>> The modem/routers I've contemplated have four switch ports unless I
>> want commercial grade equipment, which seems extravagant.
>
> ACK
>
> I think I've seen routers, sans modem, that had eight ports for the LAN
> and one port for the WAN.

Industrial, maybe?

[snip]

>
> So a single four port switch is not going to suffice for your current
> needs, much less give growth opportunity.

'fraid so.

>
>> In priciple separate seems more flexible. In practice I'm not sure
>> it matters.
>
> It sounds like eight LAN ports is your minimum. I don't know if a
> switch / router / modem exists that has all of that. So you may have to
> have an external switch or modem.

I certainly haven't seen one at the consumer retail level.

[snip]

>
> So let me ask you the question I ask myself / used to ask my clients.
>
> Is there anything you wanted to do but were unable to do with your
> current configuration?

Not at all. I was happy as a clam until AT&T told me to get U-verse
or get lost. I moved to another telco/ISP, they preferred bridged
connections. Everything seemed ok till I noticed infrequent DSL hangs.
They told me I needed to upgrade the modem. The first domino fell.

> Is there anything you have been pondering and would like to do if the
> new configuration allowed it?
>

I'm just adapting to changing times, at most a minute ahead.
Adding redundant connectivity would be interesting, but it's far
from necessary and for now fairly expensive.

>
[snip]

> It depends on the network topology. I would rather have something to
> provide some control over the connections to the IPs.

I understand the value of being able to interpose a firewall but am
uncertain of the need, at least for host OS's designed for server use.
Workstations, especially older ones, are best kept behind many-to-one NAT.
If one doesn't control what gets plugged into the network, then yes,
a firewall under control makes sense.

> This is another reason that I like the actual routed subnet. I can more
> easily move it elsewhere in my network.

Understood, but my network is rather tiny 8-)

[snip]

>
> I've been happy with my TP-Link equipment (switches).
>

That's a useful insight, are there any brands you avoid?


Thanks once again for reading!

bob prohaska

[Grant Taylor]

On 3/9/19 9:31 PM, bob prohaska wrote:
> [trimmed a little, hopefully for clarity]

;-)

> I'm thinking that can't be helped....there isn't (yet) an Ethernet jack
> in every home 8-)

bridging / proxy ARP / NATing is L2 frame / L3 packet handling
methodology that are independent of the L1 physical network.

> That is what I had formerly with AT&T: The Cayman was configured with
> PPPoE, a login and password. 8 IPs, one for netmask, one for broadcast
> address, one for the router, 5 for me.

ACK

> The new ISP is using something called RFC-1483 bridging. There is no
> login or password, all outbound traffic goes to the ISP's gateway.

RFC-1483 bridging is my preferred method. (I dislike PPPoE.) It
basically bridges Ethernet frames onto the underlying DSL network
technology.

My dislike of PPPoE largely has to do with MTU / MSS complications.

> The Cayman occupies one public address for its internal router and uses
> that to support a private network. It will also do static NAT between
> public and private addresses.

I'm guessing that the Cayman has multiple (eight in this case) IPs on
the outside that come from the ISP's public network and has what ever
configured for the private on the inside. I'm guessing it can likely
DNAT public IPs to specified internal private IPs. Likewise it will
SNAT the specified internal private IPs to the associated public IP.

> Bridging was what they preferred a year ago when I transferred my service
> from AT&T. I asked for minimal changes, bridging was what I got, using
> eight consecutive IP's. I'd rather not rock the boat further without
> good cause.

Agreed.

I'm just suggesting asking a question to make sure that you don't get on
the legacy boat because that's what you currently have. Especially if
the current boat offers more features and / or is cheaper. ;-)

IMHO it never hurts to ask. You can always decide stick with the
original boat.

> Ok, that's noise.

>
> That I'd call signal.

Agreed on both accounts.

> I've done a preliminary experiment using two hosts set to use public IPs
> and default route that points to the ISP's gateway. If I run arp -a on
> each of those hosts they don't see each other, only the ISP's gateway
> address, their own address and my router's public address. Each can ping
> the other and outside, so connectivity is ok, but I thought they'd report
> arp entries for every other host on the visible subnet.

I've never relied on arp -a to show me all hosts in a subnet. My
understanding is that it will show entries in the local ARP cache that
haven't expired. So if the local host hasn't communicated with a host
in the local broadcast domain, chances are good that arp -a won't show it.

You can do things like a ping scan to cause the system to try to
communicate with all local hosts thereby populating the ARP cache.

Also, arp -a will inherently only show you IPs that are in directly
attached subnets. So if you have public IPs without any private IPs,
anything to the private IPs will get routed and pass through the router.
Conversely if you add the private IP, communications may be direct.

> This isn't a traffic measurement, but I thought it might be at least a
> traffic source count. The sources are few.

ACK

It's /a/ measurement. It's important to keep in mind /what/ that
measurement is.

> Running arp -a on my private net all the hosts show up, which is what
> I expected.

Depending on how many hosts you have and how they communicate with each
other, I'm somewhat surprised by that.

> Industrial, maybe?

Na.

I used to install Netgear FVS318 series routers. They had one WAN port
and eight LAN ports. All of which were Ethernet.

I know that I worked with others. I just don't remember make or model.

I always considered the FVC318 to be more professional than residential,
but far from industrial. Industrial implies different things that make
equipment considerably more expensive. Physically hardened, wider
temperature range, more robust power supplies, etc.

> 'fraid so.

Okay.

So that probably removes some lower end devices from your preferred choices.

> I certainly haven't seen one at the consumer retail level.

Don't limit your search scope to what is carried in box stores.

I've found that there are a LOT of things available on line. Retail /
aftermarket / etc.

> Not at all. I was happy as a clam until AT&T told me to get U-verse
> or get lost. I moved to another telco/ISP, they preferred bridged
> connections. Everything seemed ok till I noticed infrequent DSL hangs.
> They told me I needed to upgrade the modem. The first domino fell.

ACK

> I'm just adapting to changing times, at most a minute ahead. Adding
> redundant connectivity would be interesting, but it's far from necessary
> and for now fairly expensive.

Ya.

Redundant connectivity gets expensive and complex fast.

If it's another DSL like, why not use it in parallel. If it's dial up,
that has it's own issues.

Then there's what do you do with the routing of your public IPs when the
primary connection is out.

Yuck. What did I just step in. ;-)

> I understand the value of being able to interpose a firewall but am
> uncertain of the need, at least for host OS's designed for server use.
> Workstations, especially older ones, are best kept behind many-to-one
> NAT. If one doesn't control what gets plugged into the network, then yes,
> a firewall under control makes sense.

To each his / her own.

One advantage of the network edge firewall is that you can more easily
detect malicious activity that crosses systems and take action without
needing to get the host based firewalls to communicate with each other.
If you care about that sort of thing.

> Understood, but my network is rather tiny 8-)

Most of the networks I've worked with are tiny. Seldom more than one
public and one private subnet.

Many had port forwarded services to an internal server.

> That's a useful insight, are there any brands you avoid?

There is one brand. But it's more personal bias than anything. I
always felt like Linksys left me wanting compared to Netgear and D-Link.
It didn't help that I had a Linksys physically fall apart while
unboxing it one day.

I've used and supported all of the following brands (in alphabetical order):

· Asus
· Cisco
· D-Link
· Dynex
· Juniper
· Linksys
· Netgear
· TP-Link
· TrendNet

I know that there are other brands that I've supported. I just can't
remember them.

By far, my favorite thing to do is to repurpose an old workstation into
a Linux router that I have complete control over. Physical interface
requirements are what usually deter me from that.

> Thanks once again for reading!

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/9/19 9:31 PM, bob prohaska wrote:
>> [trimmed a little, hopefully for clarity]
>
> ;-)
>
>> I'm thinking that can't be helped....there isn't (yet) an Ethernet jack
>> in every home 8-)
>
> bridging / proxy ARP / NATing is L2 frame / L3 packet handling
> methodology that are independent of the L1 physical network.
>

Ok, things are beginning to click....along with some grinding and scraping....

>
> I'm just suggesting asking a question to make sure that you don't get on
> the legacy boat because that's what you currently have. Especially if
> the current boat offers more features and / or is cheaper. ;-)
>
> IMHO it never hurts to ask. You can always decide stick with the
> original boat.
>

The boats I know about are DSL over POTS, terrestrial wireless, TV cable
and U-verse. Among them, DSL over POTS seems the least expensive adequate
alternative. Apart from bridged vs routed are there any other boats afloat?
Even in the case of bridged, wouldn't the ISP want to route only my IP
block to my modem, so I can't cause IP conflicts via typing errors?

>
> It's /a/ measurement. It's important to keep in mind /what/ that
> measurement is.
>

Ok, thanks, I didn't appreciate the limitations of arp -a measurement.

>
> I used to install Netgear FVS318 series routers. They had one WAN port
> and eight LAN ports. All of which were Ethernet.
>
>

> I always considered the FVC318 to be more professional than residential,
> but far from industrial. Industrial implies different things that make
> equipment considerably more expensive. Physically hardened, wider
> temperature range, more robust power supplies, etc.
>

Found them on Amazon. If I were running a business I'd be tempted.
For a hobby it seems a bit much (speed, cost, power) but nice.

>
> I've found that there are a LOT of things available on line. Retail /
> aftermarket / etc.
>

On line seems to be the only useful source. DSL modems can't be had
other than online. I've thought about used equipment from surplus
shops, but it seems that older equipment tends to be power-hungry
and at twenty cents per kWh it gets expensive to feed. Also I'm
not sure it ages well, no matter how well-made.

>
> Redundant connectivity gets expensive and complex fast.
>
> If it's another DSL like, why not use it in parallel. If it's dial up,
> that has it's own issues.
>
> Then there's what do you do with the routing of your public IPs when the
> primary connection is out.
>
> Yuck. What did I just step in. ;-)
>

Just to explore the "yuck" notion, there are half a dozen home wifi networks
within range of mine. Is it technically feasible (nothing about politics or
economics) to set up an ad-hoc sharing arrangement where if my broadband goes
down I can shift my traffic over the neighbor's broadband links temporarily?
Obviously there'd have to be reciprocity, so if _their_ links go down I'll
take some of their traffic. Would such a scheme require explicit cooperation
from the ISPs involved? I suspect it's doable, but how difficult?

>
> One advantage of the network edge firewall is that you can more easily
> detect malicious activity that crosses systems and take action without
> needing to get the host based firewalls to communicate with each other.
> If you care about that sort of thing.
>

This looks like one of the features of the FVS318, I can understand the
appeal.

>> That's a useful insight, are there any brands you avoid?
>
> There is one brand. But it's more personal bias than anything. I
> always felt like Linksys left me wanting compared to Netgear and D-Link.
> It didn't help that I had a Linksys physically fall apart while
> unboxing it one day.
>

That is a considerable surprise. I always thought, utterly without basis,
that Linksys was a premier brand.

> I've used and supported all of the following brands (in alphabetical order):
>

> ? Asus
> ? Cisco
> ? D-Link
> ? Dynex
> ? Juniper
> ? Linksys
> ? Netgear
> ? TP-Link
> ? TrendNet
>

I'll keep those names in mind, though Cisco and Juniper seem out of my
league.

>
> By far, my favorite thing to do is to repurpose an old workstation into
> a Linux router that I have complete control over. Physical interface
> requirements are what usually deter me from that.
>

What do you think of projects like openWRT? In principle it seems like
a good idea, but I have no clue about the practice. At least the hardware
is cheap, low power and readily available.


With my thanks!

bob prohaska

[Grant Taylor]

On 3/11/19 8:53 PM, bob prohaska wrote:
> Ok, things are beginning to click....along with some grinding and
> scraping....

Cool!

> The boats I know about are DSL over POTS, terrestrial wireless, TV
> cable and U-verse. Among them, DSL over POTS seems the least expensive
> adequate alternative. Apart from bridged vs routed are there any other
> boats afloat?

Er, perhaps my analogy was a little too broad. I was thinking more
which type of DSL-over-POTS boat might be best. I.e. have a chat with
your preferred ISP and ask what their current solution is. Maybe they
have something you'll like better than what you had. Maybe they won't.
But it might be worth the 5 ~ 15 minutes conversation to find out and
know for sure. ;-)

> Even in the case of bridged, wouldn't the ISP want to route only my IP
> block to my modem, so I can't cause IP conflicts via typing errors?

Conceptually I agree with you. Practically, I have not seen that done.
I think it is technically possible.

I, and my customers, have been victim to such an accident in the past.

It comes down to the RoI for more stringent configurations to help
prevent said accidents.

> Ok, thanks, I didn't appreciate the limitations of arp -a measurement.

:-)

> Found them on Amazon. If I were running a business I'd be tempted.
> For a hobby it seems a bit much (speed, cost, power) but nice.

Fair enough. Another informed decision. :-)

> On line seems to be the only useful source. DSL modems can't be had
> other than online.

Best Buy (and comparable) have usually had basic DSL modems in the two
haunts that I've lived in. But each haunt is different.

> I've thought about used equipment from surplus shops, but it seems that
> older equipment tends to be power-hungry and at twenty cents per kWh
> it gets expensive to feed. Also I'm not sure it ages well, no matter
> how well-made.

Fair enough.

DSL and dial up modems have a habit of being damaged by nearby lightning.

I get the power hungry and desire to not pay / feed the kW monster.
That might be a reason to see what your ISP has on offer. It will
likely be newer and less power hungry. Maybe. Possibly.

> Just to explore the "yuck" notion, there are half a dozen home wifi
> networks within range of mine. Is it technically feasible (nothing about
> politics or economics) to set up an ad-hoc sharing arrangement where
> if my broadband goes down I can shift my traffic over the neighbor's
> broadband links temporarily?> Obviously there'd have to be reciprocity,
> so if _their_ links go down I'll take some of their traffic.

Yes, it is technically quite feasible. Especially if said neighbor is
using a different broadband technology.

Of course, there are a number of other complications in doing so. Not
the least of which is /how/ it's done. (This is an entire sub-set of
things to consider.)

Assuming that you and your friendly neighbor want to do this, another
issue is, do you allow your neighbor to have access to your internal
LAN? Or just your Internet connection.

There are more questions. But this is certainly possible to do. Let's
start a new thread about that if you want to explore it.

> Would such a scheme require explicit cooperation from the ISPs involved?

No, it would not. You and your neighbor(s) can do this completely
independent of your ISP(s).

Note: Some ISPs might start to get cranky if you try to make a profit
by re-selling their service. But cost splitting and sharing of service
is usually okay. It's just a grey line to be aware of.

But it is quite technically feasible to do.

> I suspect it's doable, but how difficult?

It depends.

On the surface, giving your neighbor access to your Internet connection
can be as simple as having them connect to your network.

But it would be for the two of you to have a router that supports
multiple Internet connections. The primary being your ISP and the
secondary being your neighbor's network. - Depending on the router,
you may have to tweak some settings to prefer the primary and only fall
to the secondary when the primary is out.

> This looks like one of the features of the FVS318, I can understand
> the appeal.

It's been at least 10 years since I last looked at the FVS318. I may be
forgetting some things.

> That is a considerable surprise. I always thought, utterly without basis,
> that Linksys was a premier brand.

I know a lot of friends and colleagues that liked Linksys. Many of them
refused to use anything else.

I guess I just had different experience.

> I'll keep those names in mind, though Cisco and Juniper seem out of
> my league.

Traditional Cisco and Juniper are quite pricey. Remember that Cisco
bought Linksys. (I don't know if they still own them or if Linksys is
back out on their own.)

> What do you think of projects like openWRT? In principle it seems like a
> good idea, but I have no clue about the practice. At least the hardware
> is cheap, low power and readily available.

I have used OpenWRT a few times. One of the last times was on the
Linksys WRT54GL. (I tied three of them together via network and
literally with zip ties.)

I'm getting ready to use OpenWRT on the GL.iNet's GL-AR750.

I think that it's probably likely that the GL-AR750 could be used with
it's stock firmware (which is itself a custom OpenWRT) to tie your
network to your neighbors network.

You have the 1st interface towards your Internet connection (external
bridging DSL modem), the 2nd interface towards your LAN (likely with the
wireless), and the 3rd interface towards your neighbor's LAN (via wired
or wireless).

There are a LOT of things that can be done.

> With my thanks!

:-)

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:

[on sharing broadband connections among neighbors]

> There are more questions. But this is certainly possible to do. Let's
> start a new thread about that if you want to explore it.
>
>

I suspect attempting to multi-home my network via the neighbor's
WiFi is a little (lot?) beyond my skill level at this point.
Let's defer that conversation for later 8-)

More immediately, I've re-arranged my setup to eliminate the
use of static NAT: The modem is still in bridge mode, the
public hosts now use public IPs and my private hosts are
on a 192.168.1.x network using the Cayman's internal router.

The diagram looks like

phonejack------dslmodem/router------------privatenet
|
|
switch---------servers

To my surprise, even though the modem's internal switch is
now carrying public IP traffic, the same switch still carries
192.168.1.x traffic and the modem/router can be administered
via the local address. Is this what you meant by putting
unrouted traffic on a routed network?

Placing a single-point firewall between the wilder world and
my servers looks do-able using a second router (with appropriate
software) upstream of the servers. I'm imagining separate
modem, switches and routers in a layout like this:

phonejack-----modem
|
|
switch0---router1-----switch1------privatenet
|
|
router2----switch2----servers

I gather openWRT on the routers would allow me to implement firewall
functions, assuming I can figure out how to write firewall rules 8-)
Does this look like a reasonable setup?

It's kinda surprising what replacing a modem can lead to ......

8-)

bob prohaska

[Grant Taylor]

On 3/13/19 6:40 PM, bob prohaska wrote:
> I suspect attempting to multi-home my network via the neighbor's WiFi
> is a little (lot?) beyond my skill level at this point. Let's defer
> that conversation for later 8-)

Maybe. Maybe not. That's the wonderful thing about skill level. You
can change it if you want to. ;-)

> More immediately, I've re-arranged my setup to eliminate the use of
> static NAT: The modem is still in bridge mode, the public hosts now use
> public IPs and my private hosts are on a 192.168.1.x network using the
> Cayman's internal router.
>
> The diagram looks like
>
> phonejack------dslmodem/router------------privatenet
> |
> |
> switch---------servers
>
> To my surprise, even though the modem's internal switch is now carrying
> public IP traffic, the same switch still carries 192.168.1.x traffic
> and the modem/router can be administered via the local address. Is this
> what you meant by putting unrouted traffic on a routed network?

I don't remember the exact context or what was in my head when I typed that.

That certainly qualifies as putting multiple subnets on the same network
(broadcast domain). One subnet is globally routed and the other subnet
is not globally routed.

So, I'm going to say that yes, that's likely close to what I was thinking.

I wonder what sort of filtering, if any, that your modem / router does.
I'd hate to think that someone else on your same DSL network could get
creative with their network and access your private network across the DSL.

Note: There is likely no separation to prevent one of your servers from
having a private IP added to it and directly talking to your private
network.

> Placing a single-point firewall between the wilder world and my servers
> looks do-able using a second router (with appropriate software) upstream
> of the servers. I'm imagining separate modem, switches and routers in
> a layout like this:
>
> phonejack-----modem
> |
> |
> switch0---router1-----switch1------privatenet
> |
> |
> router2----switch2----servers

Please elaborate on what you mean by "with appropriate software".

Routers generally form a layer 3 /routed/ boundary. Something which I
thought you just did further up in the message.

Maybe "router" is an overly broad term. Perhaps you mean a device to
act as a firewall on layer 2. - Routers can do this, but terminology
gets tricky.

> I gather openWRT on the routers would allow me to implement firewall
> functions, assuming I can figure out how to write firewall rules 8-)

Depending on which router you run OpenWRT on, I think you can get by
with a single router. Use one port 0 (or 3) to connect to the modem,
port 1 to connect to switch 1, and port 2 to connect to switch 2.

Have OpenWRT do basic filtering (likely with EBTables or Bridged
Netfilter) between the modem on port 0 (3) and port 2 where the public
servers are connected. Do standard NAT for traffic leaving the LAN on
port 1.

> Does this look like a reasonable setup?

Yes.

I do wonder if a second router is actually needed.

> It's kinda surprising what replacing a modem can lead to ......

Yep.

> 8-)

;-)

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/13/19 6:40 PM, bob prohaska wrote:
>
>> More immediately, I've re-arranged my setup to eliminate the use of
>> static NAT: The modem is still in bridge mode, the public hosts now use
>> public IPs and my private hosts are on a 192.168.1.x network using the
>> Cayman's internal router.
>>
>> The diagram looks like
>>
>> phonejack------dslmodem/router------------privatenet
>> |
>> |
>> switch---------servers
>>
>> To my surprise, even though the modem's internal switch is now carrying
>> public IP traffic, the same switch still carries 192.168.1.x traffic
>> and the modem/router can be administered via the local address. Is this
>> what you meant by putting unrouted traffic on a routed network?
>
> I don't remember the exact context or what was in my head when I typed that.
>
> That certainly qualifies as putting multiple subnets on the same network
> (broadcast domain). One subnet is globally routed and the other subnet
> is not globally routed.
>
> So, I'm going to say that yes, that's likely close to what I was thinking.
>
> I wonder what sort of filtering, if any, that your modem / router does.

IIUC, in bridge mode the modem presents all traffic offered by the ISP
to the Cayman's internal switch. The switch then sorts traffic by IP/MAC
address among my servers and its own internal router.

> I'd hate to think that someone else on your same DSL network could get
> creative with their network and access your private network across the DSL.
>

By DSL network do you mean the public subnet to which my modem is attached?
I agree that would be bad, but would seem equivalent to breaking the router,
a perennial risk.

> Note: There is likely no separation to prevent one of your servers from
> having a private IP added to it and directly talking to your private
> network.
>

I've wondered about that, and whether it would be a useful way to connect
from my private network to the servers in a way that's not visible to the
public net. I've played a little with ifconfig aliases, but failed to get
simultaneous communications using both public and private IP addresses.
Probably my error. If an intruder were to do it I think he'd have to root
a server, another perennial risk.

>> Placing a single-point firewall between the wilder world and my servers
>> looks do-able using a second router (with appropriate software) upstream
>> of the servers. I'm imagining separate modem, switches and routers in
>> a layout like this:
>>
>> phonejack-----modem
>> |
>> |
>> switch0---router1-----switch1------privatenet
>> |
>> |
>> router2----switch2----servers
>
> Please elaborate on what you mean by "with appropriate software".
>
> Routers generally form a layer 3 /routed/ boundary. Something which I
> thought you just did further up in the message.
>
> Maybe "router" is an overly broad term. Perhaps you mean a device to
> act as a firewall on layer 2. - Routers can do this, but terminology
> gets tricky.

You're right, I'm being sloppy. According to the crab book the term secure
router is probably closer to right. What I'm really alluding to is the use
of a home router that can limit traffic to what's relevant to my servers
and not otherwise objectionable.

>> I gather openWRT on the routers would allow me to implement firewall
>> functions, assuming I can figure out how to write firewall rules 8-)
>
> Depending on which router you run OpenWRT on, I think you can get by
> with a single router. Use one port 0 (or 3) to connect to the modem,
> port 1 to connect to switch 1, and port 2 to connect to switch 2.
>
> Have OpenWRT do basic filtering (likely with EBTables or Bridged
> Netfilter) between the modem on port 0 (3) and port 2 where the public
> servers are connected. Do standard NAT for traffic leaving the LAN on
> port 1.
>

Does there have to be anything special about the router running openWRT
apart from sufficient RAM and flash memory? Any special hardware? I'm
gradually realizing that the switch directs traffic by IP number mapped to
MAC address, so traffic directed to a private address need not be offered
to a device using a public address. I was confusing switches and hubs.

It would be interesting to see how much extraneous traffic is actually
coming across the bridged modem. Would a packet sniffer or protocol analyzer
(wireshark, for example) let me see it? Conversely, could another ISP user
on the same subnet observe traffic among my servers?

This is getting complicated.....

Thanks for your patience!

bob prohaska

[Grant Taylor]

On 3/15/19 12:54 PM, bob prohaska wrote:
> IIUC, in bridge mode the modem presents all traffic offered by the ISP
> to the Cayman's internal switch.

Yes.

Technically many DSL modems use RFC 1483 Bridging to bridge encapsulate
Ethernet frames into ATM cells.

PPPoE has the added complication that the router sends PPP-over-Ethernet
frames out and those Ethernet frames are subsequently 1483 Bridged.

At least that's the case for traditional ATM based DSL networks. There
are older DSL networks that used Frame Relay in place of ATM. I think
there are newer DSL networks that use something in place of ATM.

But that's my understanding of how it works at a high level conceptual
view. Get the Ethernet frame from the router through the xDSL network
to the router at the ISP.

It's my understanding that Cable Modems are conceptually similar at the
10,000 foot view, but have different nuances.

> The switch then sorts traffic by IP/MAC address among my servers and
> its own internal router.

Mostly yes.

Most /switches/ operate on the Layer 2 MAC address.

Most /routers/ operate on the Layer 3 IP address.

I say /most/ because there are layer 3 switches and some routers can
also operate at layer 2.

So, an IP packet will:

1) The DSL modem demodulates the signal and provides ATM cells.
2) ATM cells are decapsulated and provide Ethernet frames.
3) Ethernet frames go to the switch.
4) The switch sends the frame out based on the destination MAC address.
5) The router or server receives the Ethernet frame.
6) Performs any firewalling and / or NAT processing.

This is where the path diverges depending on if the frame is to your
router or one of your servers.

Router:
7) Routes the packet to the proper destination IP.
(ARP happens at this point if needed.)
8) The router sends the new Ethernet frame to the switch.
9) GOTO step 4 above.

Server:
7) Sends the IP packet up the IP stack for processing.

Traffic to / from the private LAN actually passes through the same
switch twice, using different IPs (thanks to NAT) and different MAC
addresses.

This is a conceptual overview and makes a few assumptions. Said
assumptions would alter minutia and IMHO don't largely alter the overview.

> By DSL network do you mean the public subnet to which my modem is
> attached?

Yes, I do.

> I agree that would be bad, but would seem equivalent to breaking the
> router, a perennial risk.

It actually doesn't require breaking anything.

Consider a common switch in step 4 above.

Someone on the same DSL network could conceptually configure one of
their machines with an IP address that matches your private network,
send an Ethernet frame to one of your internal MAC addresses and your
switch would see it come in from the DSL modem and send it directly to
your internal computer, just like it would do with an Ethernet frame
from your router. The switch has very little way to tell the difference.

I say conceptually because the ISP can configure the DSL network in such
a way that this is less likely to happen, and it is possible to teach a
switch to treat things differently. But this requires work and I
wouldn't bet on it happening. As such, I would assume that my internal
machines are directly accessible from other machines on the ISP's DSL
network.

This is where the Layer 2 firewall that I mentioned in a previous
message comes into play. Something to filter and protect the internal
machines.

> I've wondered about that, and whether it would be a useful way to connect
> from my private network to the servers in a way that's not visible to the
> public net.

There is a reasonable chance that something else on the DSL network
would see broadcasts escape from your private network. Thus they would
learn about your internal network. They could use this knowledge to
perpetuate the attack I mentioned above.

> I've played a little with ifconfig aliases, but failed to get simultaneous
> communications using both public and private IP addresses. Probably my
> error.

It should be simple to do.

ip addr add 192.0.2.123/24 dev eth0

Assuming that you are using Test-Net-1 and are connected to eth0.

> If an intruder were to do it I think he'd have to root a server, another
> perennial risk.

Yes, they would need something to give them remote access (any
vulnerable public service will suffice). Then they would likely need a
privilege escalation to go from non-root to root. (Assuming that the
service was running as something other than root.)

This is largely a question of /when/, not /if/. You can make the /when/
longer by keeping things up to date and trying to stay current.

> You're right, I'm being sloppy.

I get the impression that some of this is somewhat new and / or we are
using the terms more precisely than you may have in the past. Sounds
like learning to me. IMHO learning > sloppy. ;-)

> According to the crab book the term secure router is probably closer
> to right.

I'm not familiar with "(the) crab book".

> What I'm really alluding to is the use of a home router that can limit
> traffic to what's relevant to my servers and not otherwise objectionable.

I am getting hung up on "router" as in a device that forwards traffic
from one IP subnet to a different IP subnet.

Seeing as how you want the /same/ IP subnet on both sides and are
forwarding based on the MAC addresses, that sounds like you are
switching or filtering based on layer 2.

Can something that is broadly called a router be coerced to behave this
way, probably. Is that it's default / preferred mode of operations,
doubtful.

> Does there have to be anything special about the router running openWRT
> apart from sufficient RAM and flash memory? Any special hardware?

Not really. At least not for what (I think) you are wanting to do.

There are some cases where you can potentially run into bandwidth
limitations, particularly depending on how the network interfaces are
connected to the CPU. (Ask if you want to go down this rabbit hole.)

> I'm gradually realizing that the switch directs traffic by IP number
> mapped to MAC address,

Close.

Traditional (L2) switches direct traffic by destination MAC address.
They actually have no concept of (L3) IP addresses.

> so traffic directed to a private address need not be offered to a device
> using a public address.

Traffic is directed to the destination MAC address, independent of what
IP address is in the IP packet.

> I was confusing switches and hubs.

For this discussion, switches are just smart hubs and only send traffic
out the port that the destination MAC address is connected to.

Switches and hubs can largely be used interchangeably. At least from a
functionality point of view. Granted, you probably want to use a switch
unless you have a specific reason to use a hub.

Routers on the other hand, they behave significantly differently than
switches & hubs.

> It would be interesting to see how much extraneous traffic is actually
> coming across the bridged modem. Would a packet sniffer or protocol
> analyzer (wireshark, for example) let me see it?

Absolutely.

Be warned, you might not like what you see. It will likely cause more
questions. Some of which you likely won't like the answers too. (But
that doesn't make them any valid questions.)

> Conversely, could another ISP user on the same subnet observe traffic
> among my servers?

They can /likely/ see broadcast traffic from your public servers and router.

If your switch is behaving properly, they shouldn't be able to see
traffic between your public servers.

If your switch is misbehaving or you use a hub, they /may/ be able to
see your server to server traffic. - This starts getting into the
minutia of how the ISP's network is configured and behaves. Usually
they are configured to behave like a switch too. So other subscribers
shouldn't see traffic that isn't to them. Broadcast traffic is to
everybody in the network, hence why it passes through the switch to
everybody.

> This is getting complicated.....

Na. It's just a number of simple things that interact with each other.

Start understanding how each Lego piece works, and you can start doing
some fun ~> amazing things.

Now, when you start bending / breaking the rules and redefining how Lego
pieces behave, then it starts to get interesting.

> Thanks for your patience!

You're welcome.

Thank you for the interest.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/15/19 12:54 PM, bob prohaska wrote:
>> IIUC, in bridge mode the modem presents all traffic offered by the ISP
>> to the Cayman's internal switch.
>
> Yes.
>
> Technically many DSL modems use RFC 1483 Bridging to bridge encapsulate
> Ethernet frames into ATM cells.
>
> PPPoE has the added complication that the router sends PPP-over-Ethernet
> frames out and those Ethernet frames are subsequently 1483 Bridged.
>
> At least that's the case for traditional ATM based DSL networks. There
> are older DSL networks that used Frame Relay in place of ATM. I think
> there are newer DSL networks that use something in place of ATM.
>
> But that's my understanding of how it works at a high level conceptual
> view. Get the Ethernet frame from the router through the xDSL network
> to the router at the ISP.
>
> It's my understanding that Cable Modems are conceptually similar at the
> 10,000 foot view, but have different nuances.
>
>> The switch then sorts traffic by IP/MAC address among my servers and
>> its own internal router.
>
> Mostly yes.
>
> Most /switches/ operate on the Layer 2 MAC address.
>
> Most /routers/ operate on the Layer 3 IP address.
>
> I say /most/ because there are layer 3 switches and some routers can
> also operate at layer 2.
>

But in terms of consumer grade network switches, I gather they're MAC
address controlled and ignore IP addresses. It follows that consumer
routers ignore MAC addresses unless something special is done...

> So, an IP packet will:
>
> 1) The DSL modem demodulates the signal and provides ATM cells.
> 2) ATM cells are decapsulated and provide Ethernet frames.
> 3) Ethernet frames go to the switch.
> 4) The switch sends the frame out based on the destination MAC address.

Which does not have to be the same host as the one using the IP address?

> 5) The router or server receives the Ethernet frame.
> 6) Performs any firewalling and / or NAT processing.
>
> This is where the path diverges depending on if the frame is to your
> router or one of your servers.
>

So, a firewall has to be hardware between steps 2 and 3?

My first thought is that a packet with an unrouteable address would never
get to the public address of my router. It does seem that a packet sent
to a public IP address on my network but containing a MAC address of a
private host might reach the private host. That is somewhat disturbing.
It could come from anywhere. It would also sidestep NAT. It isn't obvious
how it could be converted to a useful two-way conversation by an attacker.

> I say conceptually because the ISP can configure the DSL network in such
> a way that this is less likely to happen, and it is possible to teach a
> switch to treat things differently. But this requires work and I
> wouldn't bet on it happening. As such, I would assume that my internal
> machines are directly accessible from other machines on the ISP's DSL
> network.
>

Is there a way to test for this condition?

> This is where the Layer 2 firewall that I mentioned in a previous
> message comes into play. Something to filter and protect the internal
> machines.
>

Ok, I'm starting to see your point. I tend to think of a firewall as
part of a router. If the traffic hits the switch before the router
all bets are off.

>> I've wondered about that, and whether it would be a useful way to connect
>> from my private network to the servers in a way that's not visible to the
>> public net.
>
> There is a reasonable chance that something else on the DSL network
> would see broadcasts escape from your private network. Thus they would
> learn about your internal network. They could use this knowledge to
> perpetuate the attack I mentioned above.

>
>> I've played a little with ifconfig aliases, but failed to get simultaneous
>> communications using both public and private IP addresses. Probably my
>> error.
>
> It should be simple to do.
>
> ip addr add 192.0.2.123/24 dev eth0
>
> Assuming that you are using Test-Net-1 and are connected to eth0.
>

I tried alias, but it displaced the original address. Maybe add behaves
more as desired. I'll experiment further, but I'm pretty sure using
private addresses to communicate with public servers is no more private
than using public addresses. That rather defeats my original intent..

>> If an intruder were to do it I think he'd have to root a server, another
>> perennial risk.
>
> Yes, they would need something to give them remote access (any
> vulnerable public service will suffice). Then they would likely need a
> privilege escalation to go from non-root to root. (Assuming that the
> service was running as something other than root.)
>
> This is largely a question of /when/, not /if/. You can make the /when/
> longer by keeping things up to date and trying to stay current.
>
>> You're right, I'm being sloppy.
>
> I get the impression that some of this is somewhat new and / or we are
> using the terms more precisely than you may have in the past. Sounds
> like learning to me. IMHO learning > sloppy. ;-)
>

The basic ideas aren't all new, but some are and the level of detail is.

>> According to the crab book the term secure router is probably closer
>> to right.
>
> I'm not familiar with "(the) crab book".
>

Sorry, it's a whimsical reference to "TCP/IP Network Administration" by Craig
Hunt, published by O'Reilly. The cover features a crab, probably Dungenes
given the publisher's location. It's old, but I don't think it's wrong yet.
However, it's not the easiest read in the world. Is there something better?

>> What I'm really alluding to is the use of a home router that can limit
>> traffic to what's relevant to my servers and not otherwise objectionable.
>
> I am getting hung up on "router" as in a device that forwards traffic
> from one IP subnet to a different IP subnet.
>

I tend to use the term "router" because I'd like to use a router to host
the service provided. Probably firewall is the more correct term, but may
imply more than I hope to need 8-)

However, it does seem that a router that's also a firewall needs to have
a somewhat different internal layout: Traffic must pass the firewall before
it can be presented to the switch. IIUC that's not the usual path in a
one-piece DSL modem/router.

> Seeing as how you want the /same/ IP subnet on both sides and are
> forwarding based on the MAC addresses, that sounds like you are
> switching or filtering based on layer 2.
>

My intent was more to block traffic based on IP address that is not
to my hosts, or from a known malicious host. I didn't consider the
case of traffic with a legitimate IP address for routing but a malicious
MAC address for delivery.

> Can something that is broadly called a router be coerced to behave this
> way, probably. Is that it's default / preferred mode of operations,
> doubtful.
>

I'm not entirely opposed to coercion applied to hardware 8-)

>> Does there have to be anything special about the router running openWRT
>> apart from sufficient RAM and flash memory? Any special hardware?
>
> Not really. At least not for what (I think) you are wanting to do.
>

I might want to do more than I planned. Originally, I just wanted to
filter malicious/pointless IP addresses. It sounds worth filtering for
destination IPs that don't match destination MAC addresses. Is that
within openWRT's ability on residential hardware?

> There are some cases where you can potentially run into bandwidth
> limitations, particularly depending on how the network interfaces are
> connected to the CPU. (Ask if you want to go down this rabbit hole.)
>

Let's not, for now. My hosts are slow, their purpose educational.

>> I'm gradually realizing that the switch directs traffic by IP number
>> mapped to MAC address,
>
> Close.
>
> Traditional (L2) switches direct traffic by destination MAC address.
> They actually have no concept of (L3) IP addresses.
>
>> so traffic directed to a private address need not be offered to a device
>> using a public address.
>
> Traffic is directed to the destination MAC address, independent of what
> IP address is in the IP packet.
>

That is a revelation to me. 8-|

>> I was confusing switches and hubs.
>
> For this discussion, switches are just smart hubs and only send traffic
> out the port that the destination MAC address is connected to.
>
> Switches and hubs can largely be used interchangeably. At least from a
> functionality point of view. Granted, you probably want to use a switch
> unless you have a specific reason to use a hub.
>
> Routers on the other hand, they behave significantly differently than
> switches & hubs.
>
>> It would be interesting to see how much extraneous traffic is actually
>> coming across the bridged modem. Would a packet sniffer or protocol
>> analyzer (wireshark, for example) let me see it?
>
> Absolutely.
>
> Be warned, you might not like what you see. It will likely cause more
> questions. Some of which you likely won't like the answers too. (But
> that doesn't make them any valid questions.)
>

Just tried to compile wireshark from the FreeBSD ports. The CLI version
installed successfully, but the docs are for the GUI version. It'll be
a minute (or many) before progress happens.

It seems that even if I put the Ethernet interface on a public host into
promiscuous mode it'll only see the packets sent to its MAC address by the
switch. In my case, that address is two hops away from the DSL modem. At
best it'll be one hop from the modem. Can a good whiff be had that far away?

>> Conversely, could another ISP user on the same subnet observe traffic
>> among my servers?
>
> They can /likely/ see broadcast traffic from your public servers and router.
>
> If your switch is behaving properly, they shouldn't be able to see
> traffic between your public servers.
>
> If your switch is misbehaving or you use a hub, they /may/ be able to
> see your server to server traffic. - This starts getting into the
> minutia of how the ISP's network is configured and behaves. Usually
> they are configured to behave like a switch too. So other subscribers
> shouldn't see traffic that isn't to them. Broadcast traffic is to
> everybody in the network, hence why it passes through the switch to
> everybody.
>
>> This is getting complicated.....
>
> Na. It's just a number of simple things that interact with each other.
>
> Start understanding how each Lego piece works, and you can start doing
> some fun ~> amazing things.
>
> Now, when you start bending / breaking the rules and redefining how Lego
> pieces behave, then it starts to get interesting.
>
>> Thanks for your patience!
>
> You're welcome.
>
> Thank you for the interest.

I'm beginning to understand your preference for routed networks.

bob prohaska

[Grant Taylor]

On 3/16/19 1:01 AM, bob prohaska wrote:
> But in terms of consumer grade network switches, I gather they're MAC
> address controlled and ignore IP addresses. It follows that consumer
> routers ignore MAC addresses unless something special is done...

Most consumer (SOHO) grade switches function on layer 2, and only worry
about MAC addresses.

Most consumer (SOHO) grade routers function on layer 3, and only worry
about IP addresses. - However, they do need to worry about resolving
the MAC addresses of (directly deliverable) IPs in the locally attached
subnets. So they do care about MAC addresses for that. But that's not
what switches do.

> Which does not have to be the same host as the one using the IP address?

Correct.

Switches learn the port that a source MAC address is connected to when
an Ethernet frame comes in. That way the switch (ideally) knows which
port a destination MAC address is connected to and thus what port to
send the Ethernet frame out. - I saw something from Bob come in the
yellow door, so I'll send things to Bob out the yellow door.

If a switch doesn't know what port the destination MAC address is
connected to, it will send (copies of) the Ethernet frame out all ports,
save for the port that it came in on.

> So, a firewall has to be hardware between steps 2 and 3?

That's likely the ideal place to put a firewall that deals with Ethernet
frames. That's typically a Layer 2 firewall.

> My first thought is that a packet with an unrouteable address would never
> get to the public address of my router.

Sadly, that happens all too often.

It happens because other ISP clientele (or the ISP itself) has something
misconfigured (possibly plugging a DSL modem into a switch with private
computers) such that traffic meant for a LAN makes it out into the DSL
network.

There are other reasons it can happen, but they are (almost) all
directly connected to the same DSL network.

> It does seem that a packet sent to a public IP address on my network
> but containing a MAC address of a private host might reach the private
> host.

Yes, such is possible.

Such an Ethernet frame would have to be sent by someone directly
connected to the DSL network.

MAC addresses are inherently layer 2 and do not cross a layer 3 boundary.

Usually, the ISP's router is a well behaved layer 3 boundary and would
never send an Ethernet frame like you are describing. Hence why such a
frame would need to come from someone on the same ISP network.

> That is somewhat disturbing.

You're starting to see the security concerns that I was alluding to.

> It could come from anywhere.

Not quite. See above.

> It would also sidestep NAT.

Yes.

> It isn't obvious how it could be converted to a useful two-way
> conversation by an attacker.

Let's say I'm on the same DSL network as you. I can configure my
computer(s) to use 192.168.1.234 and send print jobs to your network
attacked printer at 192.168.1.111.

Since both IPs are in the 192.168.1.0/24 network, it will not be routed.
Which means that it will all be layer 2 traffic. I could send an ARP
request for 192.168.1.111 to learn your printer's MAC address.

Now, my computer and your printer think that each other are on the same
LAN in your house.

Now I can send print jobs that consume your ink / toner and use all the
paper in the printer. Thus performing a denial of service.

This is all possible because the DSL network is connected at layer 2
with your private LAN. If there was something separating them, I can't
do any of this. (At least not this way.)

> Is there a way to test for this condition?

It depends what you mean by test, particularly how active (vs passive)
you mean.

You can use a network sniffer (tcpdump & Wireshark are good choices) to
sniff the traffic coming in from a DSL / Cable modem. If you see
private IPs or other traffic that you think shouldn't be on the
Internet, chances are good that the ISP is /not/ filtering things like
I'd like them to.

> Ok, I'm starting to see your point. I tend to think of a firewall as
> part of a router. If the traffic hits the switch before the router all
> bets are off.

Yep. You got it.

What we typically call a "router" is really a piece of equipment that is
performing multiple functions. Usually the firewalling that is in SOHO
models is L3 filtering in the router portion. Frequently the switch is
a cheap and completely independent L2 switching chip with the physical
ports you see and a port that connects to the CPU. Thus any switching
functions are done by the basic chip and NOT the software running on the
router.

The router usually sees an outside (WAN) and an inside (LAN) interface
(which is really it's connection to the switch chip).

> I tried alias, but it displaced the original address. Maybe add behaves
> more as desired.

What are traditionally called "aliases" are weird. It also implies that
you're dealing with "ifconfig" instead of "ip". I never liked them.

You always had to know what alias number you were working with. You'd
use ifconfig to assign the main IP. Then you'd use ifconfig to assign
the alias IP to the alias interface, which was the interface name, with
a colon and an alias number appended.

ifconfig eth0 192.0.2.254
ifconfig eth0:1 192.0.2.1...
ifconfig eth0:2 192.0.2.2...

If you didn't use a unique ":#" after the physical interface name, you'd
likely get unexpected results.

To be honest, it's been so long since I've used that method, I don't
even know if it still works, or if it has somehow been broken.

Conversely adding IPs using the "ip" command is trivial and consistent.

ip addr add 192.0.2.254 dev eth0
ip addr add 192.0.2.1 dev eth0
ip addr add 192.0.2.2 dev eth0

Nice and consistent. Easily scriptable. No alias (interface) numbers
to deal with. :-)

> I'll experiment further, but I'm pretty sure using private addresses
> to communicate with public servers is no more private than using public
> addresses. That rather defeats my original intent..

It depends what you're trying to keep private.

If you want a way to communicate with your servers that can't (really
SHOULD NOT) cross the Internet, then private IPs are good. I'd just use
a different private subnet on the outside of the router than I'm using
on the inside of the router for my private LAN. Say 192.168.10.254 to
be able to talk to the Cable modem at 192.168.10.100 to read stats,
while my internal LAN is 192.168.0.<something>.

Private IPs are /okay/. It's important to have the layer 3 routed
boundary between them.

Or at the very least have something that can do some filtering on layer
2 for you. (Most SOHO router switch chips can't.)

Aside: If you go the route of OpenWRT et al., there are options, but
they are more complex.

> The basic ideas aren't all new, but some are and the level of detail is.

:-D

> Sorry, it's a whimsical reference to "TCP/IP Network Administration" by
> Craig Hunt, published by O'Reilly. The cover features a crab, probably
> Dungenes given the publisher's location.

Ah. I know EXACTLY what you mean. I counter with "The Bat book".
(Sendmail, from the same line of books.)

> It's old, but I don't think it's wrong yet.

Old doesn't necessarily mean that it's wrong or bad.

I think that line of books from that publisher says more about the
following.

> However, it's not the easiest read in the world.

*nod*

I've not been impressed with O'Reilly books. At least not for learning.

Don't get me wrong. I think they are packed full of information, and a
*GREAT* /reference/ source. But I think they are a lot like man pages.
They are good for reference, but crap for learning something.
Especially for something that may be largely new to you.

> Is there something better?

I don't know. I've not read the crab book so I can't compare.

I don't know how similar the subject material is, but I will say that
I'm currently reading TCP/IP Illustrated - Volume 1 - Second Edition.
My intention is to pick up smaller details that I've over looked in my
20 years of using & administering TCP/IP for myself and clients. I've
picked up many things that I appreciate. Though I question how useful
they are for many people. Think of it like getting a masters or PhD
half way through your career because you want to learn more about what
you've been using your entire career.

For starting, I have LONG referred people back to what I used to learn.
Linux's Networking How-To, commonly referred to as "net-3 how to". (Or
something similar.) It's a relatively small text file (compared to the
aforementioned books) that has a LOT of information in it. Obviously
it's Linux specific. But it is a good read. At least that's how I
remember it.

> I tend to use the term "router" because I'd like to use a router to
> host the service provided. Probably firewall is the more correct term,
> but may imply more than I hope to need 8-)

Fair enough.

> However, it does seem that a router that's also a firewall needs to have
> a somewhat different internal layout: Traffic must pass the firewall
> before it can be presented to the switch. IIUC that's not the usual path
> in a one-piece DSL modem/router.

Now we get into the minutia of what the capabilities of devices are and
how they are configured.

Basic / simple DSL / Cable modem router switch combos should have the
modem component connected to the WAN interface of the router component.
The router component should have the LAN interface connected to the
switch component.

> My intent was more to block traffic based on IP address that is not to
> my hosts, or from a known malicious host. I didn't consider the case
> of traffic with a legitimate IP address for routing but a malicious MAC
> address for delivery.

Now you have considered a malicious actor.

> I'm not entirely opposed to coercion applied to hardware 8-)

~chuckle~

> I might want to do more than I planned. Originally, I just wanted to
> filter malicious/pointless IP addresses. It sounds worth filtering for
> destination IPs that don't match destination MAC addresses. Is that
> within openWRT's ability on residential hardware?

I believe so.

> Let's not, for now. My hosts are slow, their purpose educational.

ACK

> That is a revelation to me. 8-|

Isn't learning fun. :-)

> Just tried to compile wireshark from the FreeBSD ports. The CLI version
> installed successfully, but the docs are for the GUI version. It'll be
> a minute (or many) before progress happens.

Hum.

I've found tshark to be annoying. Or maybe it's just a personal bias
for tcpdump, which I'm more familiar with.

I'm guessing that there are more tutorials on tcpdump that target a
broad range of audiences. I'd bet that many tshark tutorials are
targeting more advanced Wireshark users that are comfortable with
sniffing network traffic. More as an alternate mode of Wireshark than a
general sniffer.

> It seems that even if I put the Ethernet interface on a public host into
> promiscuous mode it'll only see the packets sent to its MAC address
> by the switch.

If you wait long enough, you should also see "broadcast" Ethernet frames
(like ARP uses).

You might also see frames destined to (what is called) an "unknown" MAC
address, thus flooded out all ports.

Then there is "multicast", which I'd be somewhat surprised if you see.

Collectively these are generally known as "B.U.M. frames". I say this
as you should see Ethernet frames destined to your MAC and / or B.U.M.
frames.

The switch should filter anything not to you or a B.U.M. frame.

> In my case, that address is two hops away from the DSL modem.

Point of order: The term "hop(s)" usually implies routers.

I tend to hear "number of switches or (L2) devices" when referring to
what I think you mean.

I'm not trying to be pedantic. It's just that the different terms tend
to make some implications.

> At best it'll be one hop from the modem. Can a good whiff be had that
> far away?

If you are referring to the number of layer 2 devices, you can be many
""hops (L2 devices) away. As long as the modem and your sniffer are in
the same Layer 2 broadcast domain, you should be fairly good.

Note: I'm assuming that there isn't something like an L2 firewall
filtering and conditionally dividing the L2 broadcast domain. - This
is why I mentioned such as an option in a previous email.

The best way to know is to run the sniffer on a computer (device) that
is directly connected to the modem.

> I'm beginning to understand your preference for routed networks.

:-)

Yep. That layer 3 routed boundary is nice.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/16/19 1:01 AM, bob prohaska wrote:
>

[huge snip]

Denial of service is annoying, but presumably I could complain to my
ISP, who (after some delay) could make it go away. Surveillance is a
more worrying issue. Is it a significant threat in this (bridged DSL)
scenario, assuming my equipment is set up correctly?

>> Is there a way to test for this condition?
>
> It depends what you mean by test, particularly how active (vs passive)
> you mean.
>
> You can use a network sniffer (tcpdump & Wireshark are good choices) to
> sniff the traffic coming in from a DSL / Cable modem. If you see
> private IPs or other traffic that you think shouldn't be on the
> Internet, chances are good that the ISP is /not/ filtering things like
> I'd like them to.
>

Let's suppose I have a free-standing modem (I don't right now); would a
hub (not a switch) then be required to sample _all_ the traffic from the
modem and deliver it to something like tcpdump? I raise the issue because
I don't have a hub and it looks like they're not widely available.

> What we typically call a "router" is really a piece of equipment that is
> performing multiple functions. Usually the firewalling that is in SOHO
> models is L3 filtering in the router portion. Frequently the switch is
> a cheap and completely independent L2 switching chip with the physical
> ports you see and a port that connects to the CPU. Thus any switching
> functions are done by the basic chip and NOT the software running on the
> router.
>
> The router usually sees an outside (WAN) and an inside (LAN) interface
> (which is really it's connection to the switch chip).
>

Up to now I thought of routers as multi-homed hosts with a
distinguishable Ethernet interface for every physical port.
Clearly that's not how they usually work, but the misconception
colored my thinking and language.

Given a SOHO router constructed in the usual way, how can openWRT,
or any software, prevent a packet with a malicious MAC address
from evading the router?

>> I tried alias, but it displaced the original address. Maybe add behaves
>> more as desired.
>
> What are traditionally called "aliases" are weird. It also implies that
> you're dealing with "ifconfig" instead of "ip". I never liked them.

[another big snip]

I'm on FreeBSD, which has a man page for ip but apparently no
executable shell command. It looks like I'm supposed to use
something like

ifconfig ue0 inet 192.168.1.n/28 add

to make a host answer to that address in addition to its existing
address. In that case n has to be between 1 and 7.

>> I'll experiment further, but I'm pretty sure using private addresses
>> to communicate with public servers is no more private than using public
>> addresses. That rather defeats my original intent..
>
> It depends what you're trying to keep private.
>

Passwords, credit card numbers, the usual stuff...

> If you want a way to communicate with your servers that can't (really
> SHOULD NOT) cross the Internet, then private IPs are good. I'd just use
> a different private subnet on the outside of the router than I'm using
> on the inside of the router for my private LAN. Say 192.168.10.254 to
> be able to talk to the Cable modem at 192.168.10.100 to read stats,
> while my internal LAN is 192.168.0.<something>.
>
> Private IPs are /okay/. It's important to have the layer 3 routed
> boundary between them.
>
> Or at the very least have something that can do some filtering on layer
> 2 for you. (Most SOHO router switch chips can't.)
>

I gather that making both private and public hosts answer to
192.168.0.n/28 would give then a (somewhat) private conversation,
since the router answers to 192.168.1.254. A private host
that needs to talk to the router as well still needs an address on
the router's network. That would appear to breach the layer 3
boundary. Is it fatal to privacy?

> Aside: If you go the route of OpenWRT et al., there are options, but
> they are more complex.
>

Does the complexity entail choosing a particular kind of router, i.e.,
one with a specific hardware configuration?

>
> Ah. I know EXACTLY what you mean. I counter with "The Bat book".
> (Sendmail, from the same line of books.)
>
>> It's old, but I don't think it's wrong yet.
>
> Old doesn't necessarily mean that it's wrong or bad.
>

The "crab book" makes no mention of switches and how they work.
I think everybody was using vampire taps on coax at the time.....
A case of error by "not invented yet" 8-)

>
> For starting, I have LONG referred people back to what I used to learn.
> Linux's Networking How-To, commonly referred to as "net-3 how to". (Or

Found and placed in my bookmarks.

> Now we get into the minutia of what the capabilities of devices are and
> how they are configured.
>
> Basic / simple DSL / Cable modem router switch combos should have the
> modem component connected to the WAN interface of the router component.
> The router component should have the LAN interface connected to the
> switch component.
>

Should, as opposed to _does_?

[big snip]


Point of order accepted!

> The best way to know is to run the sniffer on a computer (device) that
> is directly connected to the modem.

I tried tcpdump on a public host, excluding all traffic addressed
to or from that host. It was two switches (one inside the modem/router,
another outside) away from the modem. Here's an entry that looks strange:

13:45:58.676717 fc:25:3f:8a:a6:ba (oui Unknown) > 00:11:24:a9:f4:db (oui Unknown), ethertype Unknown (0x999a), length 133:
0x0000: 0109 0063 776c 3000 0000 0000 0000 0000 ...cwl0.........
0x0010: 0000 0000 0203 005f 0203 0200 2000 0000 ......._........
0x0020: 0000 0001 1b00 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 00f2 9e8f 7bcd 0444 e6e6 1913 ........{..D....
0x0070: 8655 e35b e700 00 .U.[...
. .cwl0................_.... ...........................................................................{..D.....U.[...

There's only one entry like this, tcpdump ran for about fifty minutes.
All the other entries appeared to have internal origns.


Thanks for reading this far, apologies if the snippage obscured context.

bob prohaska

[Grant Taylor]

On 3/17/19 2:47 PM, bob prohaska wrote:
> Denial of service is annoying, but presumably I could complain to my
> ISP, who (after some delay) could make it go away. Surveillance is a
> more worrying issue. Is it a significant threat in this (bridged DSL)
> scenario, assuming my equipment is set up correctly?

I would hope that the ISP could figure it out.

But I sure wouldn't hold my breath for some of the ISPs that I've worked
with to do so.

Also, how many people would realize that they are being attacked (DoSed)
by their printer printing pages of solid colors? Rather, how many
people would think that the printer had malfunctioned and would get mad
at it?

Of the people that realize that the printer didn't malfunction, how many
of them would suspect their computer was infected with something and go
down that deep rabbit hole?

All the while, not having any clue that it's someone maliciously doing
something across the ISP's network.

> Let's suppose I have a free-standing modem (I don't right now); would
> a hub (not a switch) then be required to sample _all_ the traffic from
> the modem and deliver it to something like tcpdump? I raise the issue
> because I don't have a hub and it looks like they're not widely available.

No, a hub is not required. A hub does make it easier.

You can connect the modem to a computer and use that computer to sniff
the traffic on the connected Ethernet interface.

> Up to now I thought of routers as multi-homed hosts with a distinguishable
> Ethernet interface for every physical port. Clearly that's not how they
> usually work, but the misconception colored my thinking and language.

In some ways, you were close. It's just that most of them only have two
distinguishable Ethernet interfaces (maybe more for wireless, but that's
another story). One for the outside, and one for the inside.

Most routers have a small switch built in. One port goes to the CPU and
is seen as the inside interface. The other switch ports are available
for computers on the LAN to use.

It is possible for some routers to be configured such that they do have
more distinguishable ports (even through some of the small switches via
VLAN tagging). But this is atypical.

> Given a SOHO router constructed in the usual way, how can openWRT,
> or any software, prevent a packet with a malicious MAC address from
> evading the router?

To me, "the usual way" means that the external modem is connected to the
WAN port and the LAN port is connected to the internal switch.

Thus the OS (OpenWRT, et al.) running has to route the traffic between
the two ports.

+-----+
+-----+ CPU +-----+-----+-----+-----+
| +-----+ | | | |
+--+--+ +--+--+--+--+--+--+--+--+
| WAN | | LAN | LAN | LAN | LAN |
+-----+ +-----+-----+-----+-----+

The usual way means that the CPU & OS sits between the modem / ISP
network and your internal computers. Thus the CPU must explicitly copy
the malicious Ethernet frame from the WAN interface to the LAN
interface. Usually such a copy would not happen.

If you decide to plug the DSL modem into one of the LAN ports, you would
need to do something to separate the LAN ports so that they can't talk
to each other without going through the CPU. Some SOHO routers can do
this via VLAN trunking between the small switch and the CPU. But this
is more complex and atypical.

> I'm on FreeBSD, which has a man page for ip but apparently no executable
> shell command.

What section is that man page from? Commands and libraries / protocols
are in different sections.

> It looks like I'm supposed to use something like
>
> ifconfig ue0 inet 192.168.1.n/28 add
>
> to make a host answer to that address in addition to its existing
> address. In that case n has to be between 1 and 7.

I'm not familiar with FreeBSD, so I can't comment. But what you're
saying does make sense.

Mostly. /28 can hold 16 IP addresses, 14 of which can be used, with a
router likely being of of them.

> Passwords, credit card numbers, the usual stuff...

Okay.

I was thinking more internal private LAN and external private
administrative traffic that wouldn't cross the Internet.

> I gather that making both private and public hosts answer to
> 192.168.0.n/28 would give then a (somewhat) private conversation, since
> the router answers to 192.168.1.254. A private host that needs to talk to
> the router as well still needs an address on the router's network. That
> would appear to breach the layer 3 boundary. Is it fatal to privacy?

I'm not following.

I think you said your internal private LAN is 192.168.1.x/24.

Let's say that the outside of your router and your /public/ servers have
both a globally routed IP and a 10.10.10.x/24 IP.

Your internal workstations could talk from private 192.168.1.123 to
private 10.10.10.10 perfectly fine.

> Does the complexity entail choosing a particular kind of router, i.e.,
> one with a specific hardware configuration?

Somewhat.

The complexity does mean that you need a router that supports a feature.

Not so much a specific hardware configuration, as in package of memory,
number of ports, etc.

You will likely want to make sure that the router you choose has a
switch chipset that supports VLANs. I suspect there are many.

> The "crab book" makes no mention of switches and how they work. I think
> everybody was using vampire taps on coax at the time..... A case of
> error by "not invented yet" 8-)

I tend to think of it as "omission" more so than "error". ():-)

> Found and placed in my bookmarks.

Cool.

Feel free to ask questions if you want to. Email is most likely to get
my attention sooner.

> Should, as opposed to _does_?

Should as in "that's my understanding, but I can't prove it". As in I
don't have any hard documentation that I can point at.

Every basic / simple DSL / Cable modem router switch combo that I can
remember having worked with as I type this post /does/....

> Point of order accepted!

:-)

> I tried tcpdump on a public host, excluding all traffic addressed to
> or from that host. It was two switches (one inside the modem/router,
> another outside) away from the modem. Here's an entry that looks strange:
>
> 13:45:58.676717 fc:25:3f:8a:a6:ba (oui Unknown) > 00:11:24:a9:f4:db (oui Unknown), ethertype Unknown (0x999a), length 133:
> 0x0000: 0109 0063 776c 3000 0000 0000 0000 0000 ...cwl0.........
> 0x0010: 0000 0000 0203 005f 0203 0200 2000 0000 ......._........
> 0x0020: 0000 0001 1b00 0000 0000 0000 0000 0000 ................
> 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0060: 0000 0000 00f2 9e8f 7bcd 0444 e6e6 1913 ........{..D....
> 0x0070: 8655 e35b e700 00 .U.[...
> . .cwl0................_.... ...........................................................................{..D.....U.[...

I don't recognize Ethertype 0x999a. Nor can I find anything quickly.

> There's only one entry like this, tcpdump ran for about fifty minutes.
> All the other entries appeared to have internal origns.

If they are truly coming from your systems, or replies there to, you are
probably fairly good.

> Thanks for reading this far, apologies if the snippage obscured context.

You're welcome and you're good.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/17/19 2:47 PM, bob prohaska wrote:
>
>> Let's suppose I have a free-standing modem (I don't right now); would
>> a hub (not a switch) then be required to sample _all_ the traffic from
>> the modem and deliver it to something like tcpdump? I raise the issue
>> because I don't have a hub and it looks like they're not widely available.
>
> No, a hub is not required. A hub does make it easier.
>
> You can connect the modem to a computer and use that computer to sniff
> the traffic on the connected Ethernet interface.
>

Wouldn't that necessarily displace normal network use? That'd` be ok for
a brief test, but not for prolonged monitoring. Perhaps a managed switch
could be set up as a sort of wiretap that wouldn't disturb normal use.

Section 4, Kernel Interface Manual

>
>> Passwords, credit card numbers, the usual stuff...
>
> Okay.
>
> I was thinking more internal private LAN and external private
> administrative traffic that wouldn't cross the Internet.
>

Well, that's part of it. When I connect to one of my servers
to do root-stuff I'd prefer that the conversation does
not get into public netspace, even with ssh encryption.

As more transactions move online banking will become a point of worry.
A VPN to financial institutions will be of some confort, once the
headaches setting it up subside.

>> I gather that making both private and public hosts answer to
>> 192.168.0.n/28 would give then a (somewhat) private conversation, since
>> the router answers to 192.168.1.254. A private host that needs to talk to
>> the router as well still needs an address on the router's network. That
>> would appear to breach the layer 3 boundary. Is it fatal to privacy?
>
> I'm not following.
>

Let's say I have a private 10.10.10.n address on each of my servers,
so I can administer them from "inside". My workstation then needs an
address in the same subnet, so it can directly communicate with the
servers. However, the workstation also needs an address on the subnet
of the router's private network, so it can use NAT to access the ISP's
public network. A broadcast that reaches the private subnet of the
router will reach the workstation. Might the workstation then leak
information about the 10.10.10.n network? Would it matter?

>
>> Does the complexity entail choosing a particular kind of router, i.e.,
>> one with a specific hardware configuration?
>
> Somewhat.
>
> The complexity does mean that you need a router that supports a feature.
>
> Not so much a specific hardware configuration, as in package of memory,
> number of ports, etc.
>
> You will likely want to make sure that the router you choose has a
> switch chipset that supports VLANs. I suspect there are many.

Ah!, so that's what I'm looking for. There are almost too many. In looking
at the openWRT website I was a little surprised to find they don't seem to
sort routers by VLAN compatiblity. Is there a different term I should be
using?

Setting up and using a VLAN is quite a bit more than I was bargaining
for, at least to begin with. I'd not even considered the possiblity.
Will VLAN-compatible routers work in a normal configuration?

> I don't recognize Ethertype 0x999a. Nor can I find anything quickly.
>
>> There's only one entry like this, tcpdump ran for about fifty minutes.
>> All the other entries appeared to have internal origns.
>
> If they are truly coming from your systems, or replies there to, you are
> probably fairly good.
>

Turns out the MAC address belongs to Apple, so it's probably my Airport
Extreme WAP. Tempest in a teapot, most likely.

Thank you!

bob prohaska


>
>
>

[Grant Taylor]

On 3/18/19 9:00 PM, bob prohaska wrote:
> Wouldn't that necessarily displace normal network use? That'd` be ok for
> a brief test, but not for prolonged monitoring. Perhaps a managed switch
> could be set up as a sort of wiretap that wouldn't disturb normal use.

Yes.

If you have root access to a router that's capable of it, you can have
it sniff the traffic for you.

A managed switch configured to SPAN / MIRROR ports (or a hub) between
the modem and the router can also be used.

> Section 4, Kernel Interface Manual

Ya. That's not commands. That's other documentation.

> Well, that's part of it. When I connect to one of my servers to do
> root-stuff I'd prefer that the conversation does not get into public
> netspace, even with ssh encryption.

Please elaborate on what you mean by "netsapce". Are you talking about
the DSL network? Or globally routed IP addresses?

> As more transactions move online banking will become a point of worry.
> A VPN to financial institutions will be of some confort, once the
> headaches setting it up subside.

I'll be shocked if banks support VPNs to normal residential customers.

I think we're going to have to settle for HTTPS (TLS) encrypted connections.

> Let's say I have a private 10.10.10.n address on each of my servers,
> so I can administer them from "inside". My workstation then needs an
> address in the same subnet, so it can directly communicate with the
> servers. However, the workstation also needs an address on the subnet
> of the router's private network, so it can use NAT to access the ISP's
> public network. A broadcast that reaches the private subnet of the router
> will reach the workstation. Might the workstation then leak information
> about the 10.10.10.n network? Would it matter?

Your workstation doesn't need an address in the 10.10.10.0/24 network.
It only needs an IP address from the "inside" network. Your
workstations can communicate through the router to the 10.10.10.0/24
network.

There are a few different ways that you can configure the router &
servers. But they all end up in you using private non-globally-routed
IP addresses between your workstation and your servers.

> Ah!, so that's what I'm looking for. There are almost too many. In
> looking at the openWRT website I was a little surprised to find they
> don't seem to sort routers by VLAN compatiblity. Is there a different
> term I should be using?

I don't know what the term would be.

It might be worth finding an OpenWRT support group that can answer more
questions specific to OpenWRT and possibly hardware recommendations.

It may be old and outdated, but I know that the Linksys WRT54GL will do
what you want. (I did it 10 ~ 15 years ago.)

> Setting up and using a VLAN is quite a bit more than I was bargaining
> for, at least to begin with. I'd not even considered the possiblity.

I'm not convinced that a VLAN is needed for what I think you're wanting
to do.

> Will VLAN-compatible routers work in a normal configuration?

In short: Yes.

In not so short, once you start talking VLANs, things are further from
normal. You'd need to describe what you mean by "normal configuration".
(The conversation has gone quite a few places, and I don't want to
assume.)

> Turns out the MAC address belongs to Apple, so it's probably my Airport
> Extreme WAP. Tempest in a teapot, most likely.

Hum.

> Thank you!

You're welcome.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/18/19 9:00 PM, bob prohaska wrote:
>
>
>> Well, that's part of it. When I connect to one of my servers to do
>> root-stuff I'd prefer that the conversation does not get into public
>> netspace, even with ssh encryption.
>
> Please elaborate on what you mean by "netsapce". Are you talking about
> the DSL network? Or globally routed IP addresses?
>

By "public netspace" I meant portions of the network visible to others.
If the ISP is leaky, that seems to include the DSL network, even if the
traffic isn't explictly sent to the ISP's gateway.

>
>> Let's say I have a private 10.10.10.n address on each of my servers,
>> so I can administer them from "inside". My workstation then needs an
>> address in the same subnet, so it can directly communicate with the
>> servers. However, the workstation also needs an address on the subnet
>> of the router's private network, so it can use NAT to access the ISP's
>> public network. A broadcast that reaches the private subnet of the router
>> will reach the workstation. Might the workstation then leak information
>> about the 10.10.10.n network? Would it matter?
>
> Your workstation doesn't need an address in the 10.10.10.0/24 network.
> It only needs an IP address from the "inside" network. Your
> workstations can communicate through the router to the 10.10.10.0/24
> network.
>

Perhaps I don't understand what's meant by "an IP address from the inside
network". Wouldn't both the servers and the workstation need alias
addresses on the same non-routeable network, say 10.10.10.1 through
10.10.10.6 assuming five servers and one workstation? The servers would
have in addition their routable addresses, and the workstation its
private 192.168.1.n/24 address on the LAN for access to the router.

In essence I wanted to hide the administrative network from the router,
knowing I can't hide it from the router's switch.

> There are a few different ways that you can configure the router &
> servers. But they all end up in you using private non-globally-routed
> IP addresses between your workstation and your servers.
>

Can that traffic be made invisible to eavesdroppers outside my premises?

>
> It might be worth finding an OpenWRT support group that can answer more
> questions specific to OpenWRT and possibly hardware recommendations.
>

I'll try to content myself with digging through FAQs and archives for now.
What I'm trying to learn can't be new.

>
> I'm not convinced that a VLAN is needed for what I think you're wanting
> to do.

I believe (and fervently hope!) you're right 8-)

>
>> Will VLAN-compatible routers work in a normal configuration?
>
> In short: Yes.
>
> In not so short, once you start talking VLANs, things are further from
> normal. You'd need to describe what you mean by "normal configuration".
> (The conversation has gone quite a few places, and I don't want to
> assume.)
>

Let's suppose all I want to do is make it hard to attack the printer.

>> Turns out the MAC address belongs to Apple, so it's probably my Airport
>> Extreme WAP. Tempest in a teapot, most likely.
>
> Hum.
>

Is that hum as in "ho-hum" or hum as in "hmmmmm, what's going on?"?
One websearch found this link:
https://forum.huawei.com/enterprise/en/Case-share-Broadcasting-packets-with-ethertype-0x999a/thread/496447-863
which suggests the packet came from a diagnostic function on a Huawei device.
Does that conflict with the packet originating in an Apple WAP?

The takeaways so far seem to be:

A separate modem and router offers better monitoring possibilities.
A router that supports vlans has better privacy even if I choose not
to set up virtual private networks.

It still isn't clear if there's leakage into my private network from
the ISP's side. That will be much easier to test after the modem and
router are separated so a packet sniffer can be introduced.

Thank you!

bob prohaska

[Grant Taylor]

On 3/19/19 8:23 PM, bob prohaska wrote:
> By "public netspace" I meant portions of the network visible to others.
> If the ISP is leaky, that seems to include the DSL network, even if the
> traffic isn't explictly sent to the ISP's gateway.

Okay. Thank you for clarifying.

That that tells me that you want some sort of firewall (or other
filtering device) between your servers and your ISP.

> Perhaps I don't understand what's meant by "an IP address from the inside
> network". Wouldn't both the servers and the workstation need alias
> addresses on the same non-routeable network, say 10.10.10.1 through
> 10.10.10.6 assuming five servers and one workstation? The servers would
> have in addition their routable addresses, and the workstation its
> private 192.168.1.n/24 address on the LAN for access to the router.

No, that is not a requirement.

The servers can have their globally-routed IP and a non-globally-routed
IP outside your NATing router.

Your workstations can get their non-globally-routed IP from from a
different network.

Your workstations and servers would communicate between their different
non-globally-routed IPs through the (NATing) router.

> In essence I wanted to hide the administrative network from the router,
> knowing I can't hide it from the router's switch.

Okay. I don't remember that requirement.

Why do you want to hide the administrative network from the router?

> Can that traffic be made invisible to eavesdroppers outside my premises?

You will need some sort of firewall (or other filtering device) between
your servers and your ISP to guarantee that none of your administrative
traffic leaks to your ISP for anyone to see.

> I'll try to content myself with digging through FAQs and archives for now.
> What I'm trying to learn can't be new.

It's likely not new. It is likely changing or at least updating as new
models are added to the list.

OpenWRT also adds support for new chipsets. So it's possible that
something that previously wasn't supported now has support.

> I believe (and fervently hope!) you're right 8-)

~chuckle~

> Let's suppose all I want to do is make it hard to attack the printer.

You want an external firewall ... between you and your ISP.

> Is that hum as in "ho-hum" or hum as in "hmmmmm, what's going on?"?

The latter.

> One websearch found this link:
> https://forum.huawei.com/enterprise/en/Case-share-Broadcasting-packets-with-ethertype-0x999a/thread/496447-863
> which suggests the packet came from a diagnostic function on a Huawei
> device. Does that conflict with the packet originating in an Apple WAP?

The article you linked to makes sense in a vacuum.

But it doesn't make sense with your previous statement about Apple.

Do you have a Huawei device?

Do you have an Apple WAP?

> The takeaways so far seem to be:
>
> A separate modem and router offers better monitoring possibilities.

Yes.

> A router that supports vlans has better privacy even if I choose not to
> set up virtual private networks.

Point of order: VLANs and VPNs have two very different meanings.

Can a VLAN be considered a virtual private network by some definitions,
yes. But it is decidedly different than the common meaning of VPN.

Also, not using security you do have is hard to differentiate from not
having it.

> It still isn't clear if there's leakage into my private network from the
> ISP's side. That will be much easier to test after the modem and router
> are separated so a packet sniffer can be introduced.

Agreed.

[Grant Taylor]

On 3/19/19 8:23 PM, bob prohaska wrote:

> One websearch found this link:
> https://forum.huawei.com/enterprise/en/Case-share-Broadcasting-packets-with-ethertype-0x999a/thread/496447-863
> which suggests the packet came from a diagnostic function on a Huawei
> device.

I have added Ethertype 0x999a to Wikipedia's Ethertype page based on the
link that you found.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/19/19 8:23 PM, bob prohaska wrote:
>
>> Perhaps I don't understand what's meant by "an IP address from the inside
>> network". Wouldn't both the servers and the workstation need alias
>> addresses on the same non-routeable network, say 10.10.10.1 through
>> 10.10.10.6 assuming five servers and one workstation? The servers would
>> have in addition their routable addresses, and the workstation its
>> private 192.168.1.n/24 address on the LAN for access to the router.
>
> No, that is not a requirement.
>
> The servers can have their globally-routed IP and a non-globally-routed
> IP outside your NATing router.
>
> Your workstations can get their non-globally-routed IP from from a
> different network.
>
> Your workstations and servers would communicate between their different
> non-globally-routed IPs through the (NATing) router.
>

Ok, so I'd add a static route to the router's internal table?
Is that somehow better than giving the workstation its own alias
address among the non-globally-routed IPs for the servers?

>> In essence I wanted to hide the administrative network from the router,
>> knowing I can't hide it from the router's switch.
>
> Okay. I don't remember that requirement.
>

I don't think I stated it, at least not clearly.

> Why do you want to hide the administrative network from the router?
>

Well, maybe it's wishful thinking on my part. I gather the router is
a point of potential leakage, so it seemed prudent to keep sensitive
traffic out of the router, to the extent possible. If it helps at all
it seems worth doing. It'll be a while before I understand how to
implement a firewall to stop all leakage.

>> I'll try to content myself with digging through FAQs and archives for now.
>> What I'm trying to learn can't be new.
>
> It's likely not new. It is likely changing or at least updating as new
> models are added to the list.
>
> OpenWRT also adds support for new chipsets. So it's possible that
> something that previously wasn't supported now has support.
>

I've been poking around on openWRT.org and trying to locate supported
routers on Amazon. It's a fairly confusing search, I think it'll take
a while to make a reasonable choice. The fact that I care about power
consumption, and am not looking for high performance, puts me well out
of the mainstream. It seems most of the major manufacturers have had
problems with security and other scandals, so that criteria isn't much
help in narrowing the search.

In fact, openWRT isn't a requirement. It just seems to be a good idea.

>> Is that hum as in "ho-hum" or hum as in "hmmmmm, what's going on?"?
>
> The latter.

Ok, not good.

>> One websearch found this link:
>> https://forum.huawei.com/enterprise/en/Case-share-Broadcasting-packets-with-ethertype-0x999a/thread/496447-863
>> which suggests the packet came from a diagnostic function on a Huawei
>> device. Does that conflict with the packet originating in an Apple WAP?
>
> The article you linked to makes sense in a vacuum.
>
> But it doesn't make sense with your previous statement about Apple.
>
> Do you have a Huawei device?

Not that I know of. There's a D-link unmanaged switch, a Netopia modem/router
and the Apple Airport Extreme (flying saucer model).

The D-link switch is newest, about two years old. The Airport is about twelve
years old, the Netopia dates from 2004. The servers and workstation are
Raspberry Pi's less than two years old. There are three old Macs in the
house on wireless, but none were powered up.

Is ethertype 0x999a manufacturer specific? If it is, then something's odd.

>> The takeaways so far seem to be:
>>
>> A separate modem and router offers better monitoring possibilities.
>
> Yes.
>
>> A router that supports vlans has better privacy even if I choose not to
>> set up virtual private networks.
>
> Point of order: VLANs and VPNs have two very different meanings.
>
> Can a VLAN be considered a virtual private network by some definitions,
> yes. But it is decidedly different than the common meaning of VPN.
>

Point of order accepted; I do understand they're different, but I was
thinking they required the same, or at least related, hardware. The
feature I'm most immediately interested in is the "router before
switch" topology you mentioned earlier in connection with VLANs. That
by itself seems like it would relieve the most imminent worry. Until
VPNs become the rule for retail financial transactions I don't foresee
using one.

> Also, not using security you do have is hard to differentiate from not
> having it.
>

It's pretty clear the learning curve for secure communications is steep.
Buying hardware that supports security gives the choice of turning it on
later, once I know how. That seems prudent. I'm hesitant to buy something
that forces an immediate ascent of the learning curve. Especially at my
present rate 8-)

>> It still isn't clear if there's leakage into my private network from the
>> ISP's side. That will be much easier to test after the modem and router
>> are separated so a packet sniffer can be introduced.
>
> Agreed.
>

At the moment I'm thinking of buying an ADSL2+ standalone modem first. Once
I can make that work it'll be possible to sniff the ISP traffic intermittently.
That's enough to learn a little, when I get stuck I can just put the old
hardware back while figuring out what went wrong. In the meantime I'll look
for a better, more secure router/firewall. Quantifying "better, more secure"
promises to take some doing.

Thank you!

bob prohaska

[Grant Taylor]

On 3/20/19 10:08 PM, bob prohaska wrote:
> Ok, so I'd add a static route to the router's internal table? Is that
> somehow better than giving the workstation its own alias address among
> the non-globally-routed IPs for the servers?

You'd add a route to the internal non-globally-routed IP network
pointing the server to the router's outside IP.

The internal workstations will already use the router as their default
gateway.

Thus the servers outside the router and the workstation inside the
router have a route to each other.

> I don't think I stated it, at least not clearly.

Fair enough.

I'm okay with changes as long as they are acknowledged as such. (I hate
doubting myself and wondering what I forgot when.)

> Well, maybe it's wishful thinking on my part. I gather the router is
> a point of potential leakage, so it seemed prudent to keep sensitive
> traffic out of the router, to the extent possible. If it helps at all it
> seems worth doing. It'll be a while before I understand how to implement
> a firewall to stop all leakage.

The router is actually a control point to provide filtering and reduce
leakage. Rather the firewall on the router.

> I've been poking around on openWRT.org and trying to locate supported
> routers on Amazon. It's a fairly confusing search, I think it'll take
> a while to make a reasonable choice. The fact that I care about power
> consumption, and am not looking for high performance, puts me well out
> of the mainstream. It seems most of the major manufacturers have had
> problems with security and other scandals, so that criteria isn't much
> help in narrowing the search.

I wouldn't worry about the scandals, as most of them are related to the
firmware that ships from the factory. Seeing as how you're talking
about replacing that firmware with OpenWRT, you are in control of things.

> In fact, openWRT isn't a requirement. It just seems to be a good idea.

I tend to agree.

> Ok, not good.

I'm content with what you found about the Huawei loopback-detection.

> Not that I know of. There's a D-link unmanaged switch, a Netopia
> modem/router and the Apple Airport Extreme (flying saucer model).

Well, that lends credence to the Apple and tends to negate the Huawei.

Hum. I wonder what's going on. Or if Apple is also using the 0x999a
for something otherwise undocumented.

> The D-link switch is newest, about two years old. The Airport is about
> twelve years old, the Netopia dates from 2004. The servers and workstation
> are Raspberry Pi's less than two years old. There are three old Macs in
> the house on wireless, but none were powered up.

ACK

> Is ethertype 0x999a manufacturer specific? If it is, then something's odd.

No. Ethertype is a 16-bit identifier to specify what the Ethernet frame
contains. Any device can send any Ethertype.

> Point of order accepted; I do understand they're different, but I was
> thinking they required the same, or at least related, hardware.

VLANs actually take very little processing power. Most things can do
it, many of which don't for one reason or another.

VPNs on the other hand, can take between some more processing power and
quite a bit more processing power.

> The feature I'm most immediately interested in is the "router before
> switch" topology you mentioned earlier in connection with VLANs. That
> by itself seems like it would relieve the most imminent worry.

Okay.

I suspect that you might be interested in a router running OpenWRT that
can do the filtering between the modem and the servers / internal
router. Is that correct?

There are a couple of things that come to mind that I think will allow that.

· Bridging the WAN interface with the LAN interface / switch combined
with EBTables L2 filtering.
· Bridging the WAN interface with the LAN interface / switch combined
with IPTables L2 filtering.
· Proxy ARP routing between the WAN interface and the LAN interface /
switch with IPTables L3 filtering.

That would mean that the wild Internet is outside the first router, with
it protecting your DMZ. Your second router would be connected to the
DMZ like a server, and protecting your workstations on the inside.

> Until VPNs become the rule for retail financial transactions I don't
> foresee using one.

I don't think hat banking or retail will require VPNs.

Many of them do require HTTPS (TLS) encryption already.

VPNs would just be a LOT more overhead and a LOT more problematic to
configure / support. I don't see that happening.

> It's pretty clear the learning curve for secure communications is steep.

Depending how deep you want to get into it, it can be. But I don't
think it needs to be. There's a LOT more that you could get into that's
not germane to what I think you're wanting to do.

> Buying hardware that supports security gives the choice of turning it on
> later, once I know how. That seems prudent. I'm hesitant to buy something
> that forces an immediate ascent of the learning curve. Especially at my
> present rate 8-)

I might suggest that you acquire an old Linksys WRT54GL or some other
OpenWRT capable router for minimal cost and play with it to see if you
can get it to do what you want. Maybe the switch port won't be correct,
or it will be a slower speed. But you might learn quite a bit along the
way. I also expect the cost would be minimal.

> At the moment I'm thinking of buying an ADSL2+ standalone modem
> first. Once I can make that work it'll be possible to sniff the
> ISP traffic intermittently. That's enough to learn a little, when
> I get stuck I can just put the old hardware back while figuring out
> what went wrong. In the meantime I'll look for a better, more secure
> router/firewall. Quantifying "better, more secure" promises to take
> some doing.

That sounds reasonable.

I'd suggest a simple hub to go between the modem and router. That way
you can connect another machine to sniff the traffic without interfering
with said traffic.

You can insert the hub when you know you might want to sniff, and then
bypass / unplug it when you don't.

Physically small, low power four port 10/100 hubs should be dirt cheap.

> Thank you!

You're welcome. :-)

Thank you for the engaging conversation.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
>
> I suspect that you might be interested in a router running OpenWRT that
> can do the filtering between the modem and the servers / internal
> router. Is that correct?
>

That sounds like a good first step.

> There are a couple of things that come to mind that I think will allow that.
>

> ? Bridging the WAN interface with the LAN interface / switch combined
> with EBTables L2 filtering.
> ? Bridging the WAN interface with the LAN interface / switch combined
> with IPTables L2 filtering.
> ? Proxy ARP routing between the WAN interface and the LAN interface /

> switch with IPTables L3 filtering.
>
> That would mean that the wild Internet is outside the first router, with
> it protecting your DMZ. Your second router would be connected to the
> DMZ like a server, and protecting your workstations on the inside.
>

Let's see if I understand correctly. I gather the setup is

phoneline---dslmodem---router1---router2---privatenet
|
publichosts

where router1 runs EBTables and router2 runs IPTables. (I'll have to
look up those terms, EBTables is new and IPTables poorly understood.)

I did get a DLink DSL-520B modem working with my ISP in bridge mode, so
that's one (small) hurdle surmounted. At a minimum it'll need a switch.
Is a managed switch worth the cost and complexity over a dumb switch?
In particular, could it replace router1?

>
> I might suggest that you acquire an old Linksys WRT54GL or some other
> OpenWRT capable router for minimal cost and play with it to see if you
> can get it to do what you want. Maybe the switch port won't be correct,
> or it will be a slower speed. But you might learn quite a bit along the
> way. I also expect the cost would be minimal.
>

I like that idea but haven't seen any good candidates locally. I'll keep
looking.

>
> I'd suggest a simple hub to go between the modem and router. That way
> you can connect another machine to sniff the traffic without interfering
> with said traffic.
>
> You can insert the hub when you know you might want to sniff, and then
> bypass / unplug it when you don't.
>

What do you think of "passive taps", like this:
https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
If the signal degradation limits speed to 10Mbps that's ok. I can keep the
sampling lines short, probably under a meter.

Thanks again for reading!

bob prohaska

[Grant Taylor]

On 3/31/19 8:42 PM, bob prohaska wrote:
> Let's see if I understand correctly. I gather the setup is
>
> phoneline---dslmodem---router1---router2---privatenet
> |
> publichosts
>
> where router1 runs EBTables and router2 runs IPTables.

I think it's possible that you can combine router1 and router2 into a
single device. I think the limiting factor would be the switch
configuration and if you wanted to do VLANs between the router's CPU /
OS or not. If you do, they can be one router (if there are enough
ports). If you don't, then you'd need separate routers.

> (I'll have to look up those terms, EBTables is new and IPTables poorly
> understood.)

"ebtables" (I stylize as "EBTables") is how Linux traditionally filtered
/bridged/ traffic. Ethernet Bridge Tables. ;-)

"iptables" (I stylize as "IPTables") is how Linux traditionally filtered
/routed/ traffic.

At some point, IPTables got the ability to filter /bridged/ traffic.
Hence the first and second bullet points.

Feel free to ask questions.

> I did get a DLink DSL-520B modem working with my ISP in bridge mode, so
> that's one (small) hurdle surmounted.

:-)

> At a minimum it'll need a switch. Is a managed switch worth the cost and
> complexity over a dumb switch? In particular, could it replace router1?

I personally like managed switches. But they are definitely not
/required/ for the configuration you outlined above. The management
comes into play when you start talking about VLANs.

I will say that I am happy with my TP-Link TL-SG108E 8 port gigabit
layer 2 managed switches. They aren't that expensive and do provide an
opportunity to play with VLANs if you /want/ to do so.

> I like that idea but haven't seen any good candidates locally. I'll
> keep looking.

Where are you located? I have one that I am not and have not used.
Presuming it powers on, you can have it for the price of shipping and a
soft drink. (Drink is optional.)

> What do you think of "passive taps", like this:
> https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
> If the signal degradation limits speed to 10Mbps that's ok. I can keep
> the sampling lines short, probably under a meter.

I'm aware of them. I've never actually needed anything like it. I
think they will work at 10 Mbps and 100 Mbps. 1 Gbps uses different wiring.

I am curious how it relates to / fits in the larger discussion. I
usually see them discussed around things like an IDS / IPS or something
else where you want to make it so that a machine on the receiving side
of the tap is incapable of transmitting data.

Word to the wise: These taps may not work with all equipment. Fancier
equipment can get cranky at the disconnected Tx side and refuse to Rx
things. I don't know how prevalent this is, but it is a possibility.

> Thanks again for reading!

You're welcome.

Sorry for the late reply. I was traveling and wanted to give this the
time and attention it deserves.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 3/31/19 8:42 PM, bob prohaska wrote:
>> Let's see if I understand correctly. I gather the setup is
>>
>> phoneline---dslmodem---router1---router2---privatenet
>> |
>> publichosts
>>
>> where router1 runs EBTables and router2 runs IPTables.
>
> I think it's possible that you can combine router1 and router2 into a
> single device. I think the limiting factor would be the switch
> configuration and if you wanted to do VLANs between the router's CPU /
> OS or not. If you do, they can be one router (if there are enough
> ports). If you don't, then you'd need separate routers.
>
>> (I'll have to look up those terms, EBTables is new and IPTables poorly
>> understood.)
>
> "ebtables" (I stylize as "EBTables") is how Linux traditionally filtered
> /bridged/ traffic. Ethernet Bridge Tables. ;-)
>
> "iptables" (I stylize as "IPTables") is how Linux traditionally filtered
> /routed/ traffic.
>
> At some point, IPTables got the ability to filter /bridged/ traffic.
> Hence the first and second bullet points.
>
> Feel free to ask questions.
>

It's tempting to think bridged traffic is more complicated to filter
than routed traffic. True?

>> I did get a DLink DSL-520B modem working with my ISP in bridge mode, so
>> that's one (small) hurdle surmounted.
>
> :-)
>
>> At a minimum it'll need a switch. Is a managed switch worth the cost and
>> complexity over a dumb switch? In particular, could it replace router1?
>
> I personally like managed switches. But they are definitely not
> /required/ for the configuration you outlined above. The management
> comes into play when you start talking about VLANs.
>
> I will say that I am happy with my TP-Link TL-SG108E 8 port gigabit
> layer 2 managed switches. They aren't that expensive and do provide an
> opportunity to play with VLANs if you /want/ to do so.
>

Perhaps the cart has gotten slightly ahead of the horse, but I acquired
a Netgear GS108PE managed switch from the local BestBuy. It's in service
now and seems to work fine, but the management is more awkward than hoped.

The layout for now is

phoneline----DSLbridge---switch-----publichosts
|
|
router
|
workstation--WAP--privatenet

The switch defaults to management on a 192.168.0.x network in the
absence of a DHCP server (which I'm guessing must be upstream) and
it isn't obvious how to get at it from the private side. I probably
could use an alias address on one of the public hosts, but that seems
awkward. I could loop back a cable from the private side of the router
to the switch, but that makes me cringe even if it works 8-)

The router is a D-Link DI-524, updated to the latest firmware. It's
rather crude but will do for now. I'm guessing that a one-router setup
would put the router between modem and switch, using some sort of vlan
downstream to sort traffic between public and private nets; is that close?

[on getting a secondhand openWRT router]

>> I like that idea but haven't seen any good candidates locally. I'll
>> keep looking.
>
> Where are you located? I have one that I am not and have not used.
> Presuming it powers on, you can have it for the price of shipping and a
> soft drink. (Drink is optional.)
>

Thank you!

I'm in Davis, CA, a little west of Sacramento. There are thrift stores in
the area that have home networking equipment, I just need to keep looking.
There were a few Linksys routers for sale, but by the time I went back for
a second look they were gone. Not clear whether they were sold or scrapped.

OpenWRT makes much of the need for sufficient flash and RAM in routers for
current versions. They suggest 8 MB flash and 64 MB RAM. That's part of why
I hesitated. Likely, knowledgeable folks can tell by looking at the label,
but I can't, yet.

>> What do you think of "passive taps", like this:
>> https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
>> If the signal degradation limits speed to 10Mbps that's ok. I can keep
>> the sampling lines short, probably under a meter.
>
> I'm aware of them. I've never actually needed anything like it. I
> think they will work at 10 Mbps and 100 Mbps. 1 Gbps uses different wiring.
>
> I am curious how it relates to / fits in the larger discussion. I
> usually see them discussed around things like an IDS / IPS or something
> else where you want to make it so that a machine on the receiving side
> of the tap is incapable of transmitting data.
>
> Word to the wise: These taps may not work with all equipment. Fancier
> equipment can get cranky at the disconnected Tx side and refuse to Rx
> things. I don't know how prevalent this is, but it is a possibility.
>

I thought of the passive tap as a cheap alternative to a managed switch.
That's now water under the bridge, assuming I _can_ manage the switch.

>
> Sorry for the late reply. I was traveling and wanted to give this the
> time and attention it deserves.
>

I really appreciate your help!

bob prohaska

[Grant Taylor]

On 4/4/19 1:36 AM, bob prohaska wrote:
> It's tempting to think bridged traffic is more complicated to filter
> than routed traffic. True?

In a vacuum, I don't think filtering bridged traffic with EBTables is
any more difficult than filtering routed traffic with IPTables.

Some of the complexity can come from the network configuration that said
filtering fits within.

> Perhaps the cart has gotten slightly ahead of the horse, but I acquired
> a Netgear GS108PE managed switch from the local BestBuy. It's in service
> now and seems to work fine, but the management is more awkward than hoped.

Cool.

Feel free to ask questions. I'll have to look at the manual and deduce
things about that switch.

> The layout for now is
>
> phoneline----DSLbridge---switch-----publichosts
> |
> |
> router
> |
> workstation--WAP--privatenet

Assuming that the switch is not doing any VLANs, I'm going to go out on
a limb and say that there is no filtering between the ISP and the public
hosts.

Other than the lack of filtering, this is a perfectly valid network
configuration.

> The switch defaults to management on a 192.168.0.x network in the absence
> of a DHCP server (which I'm guessing must be upstream) and it isn't
> obvious how to get at it from the private side.

I would probably configure the switch to use a static IP for it's
management interface and not even try to use DHCP and then fall back to
something. (There's also the chance that it can DHCP from the upstream
provider, if they support that.)

> I probably could use an alias address on one of the public hosts, but
> that seems awkward.

You're closer than you might realize. You can put the additional IP on
one of your public hosts, or you could put it on your router, which is
also connected to the same network. (This is what I have done many
times in the past.)

> I could loop back a cable from the private side of the router to the
> switch, but that makes me cringe even if it works 8-)

I would advise against that. Doing that effectively connects the public
side of your router to the private side. Then you're back to mixing the
two networks. Which I'm confident you want to avoid doing.

> The router is a D-Link DI-524, updated to the latest firmware. It's
> rather crude but will do for now. I'm guessing that a one-router setup
> would put the router between modem and switch, using some sort of vlan
> downstream to sort traffic between public and private nets; is that close?

Yes, that's quite close.

You can bridge traffic (with EBTables filtering) from the modem to a
VLAN that the public servers are connected to, and route / NAT to the
private VLAN where your internal systems are connected.

phoneline---DSLbridge---router===switch---[public VLAN]---public host
|
[private VLAN]
|
workstation---WAP---privatenet

--- regular Ethernet connection
=== VLAN trunk Ethernet connection

> [on getting a secondhand openWRT router]
>

> Thank you!

:-)

> I'm in Davis, CA, a little west of Sacramento. There are thrift stores
> in the area that have home networking equipment, I just need to keep
> looking. There were a few Linksys routers for sale, but by the time I
> went back for a second look they were gone. Not clear whether they were
> sold or scrapped.

ACK

Things turn over faster in your area than in mine.

> OpenWRT makes much of the need for sufficient flash and RAM in routers
> for current versions. They suggest 8 MB flash and 64 MB RAM. That's part
> of why I hesitated. Likely, knowledgeable folks can tell by looking at
> the label, but I can't, yet.

I can't tell off hand.

I'd have to look at the OpenWRT site to see what models are supported.

If I was on the hunt, I'd probably make a cheat sheet, or bookmark it on
my smartphone. That way I could check while at the thrift store. ;-)

> I thought of the passive tap as a cheap alternative to a managed switch.

Ah.

It is an alternative to a SPAN port. But I'm fairly sure that won't do

what (I think) you are wanting to do.

> That's now water under the bridge, assuming I _can_ manage the switch.

I'm betting that you will be able to.

> I really appreciate your help!

:-)

I enjoy helping ~> teaching people.

I actually had someone send me a couple 2-liters of soda internationally
as payment for helping them for about 9 months. I say internationally,
he was in Germany and had a friend in the same town as me proxy the
2-liters. The 2-liters were more of a joke. But it was a fun joke.

I did ask him, and I will ask you, to help someone else in the future if
you can. :-)

[Johann Beretta]

On 3/8/19 4:52 PM, bob prohaska wrote:

>
> The modem/routers I've contemplated have four switch ports unless I want
> commercial grade equipment, which seems extravagant.
>

I'm coming in to this conversation in the middle, so I probably don't
have all the facts, but from what I have read so far, I'd suggest you
take a very detailed look at MikroTik's line of switches/routers and the
base operating system for it, RouterOS.

I suspect these routers and/or switches may be able to solve your issues
or at least solve some of them.

RouterOS is deceptively powerful and well documented so it bears a look.

(not affiliated with MikroTik, I just use their routers, exclusively, to
handle routing for my ISP)

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/4/19 1:36 AM, bob prohaska wrote:
>> It's tempting to think bridged traffic is more complicated to filter
>> than routed traffic. True?
>
> In a vacuum, I don't think filtering bridged traffic with EBTables is
> any more difficult than filtering routed traffic with IPTables.
>
> Some of the complexity can come from the network configuration that said
> filtering fits within.
>
>> Perhaps the cart has gotten slightly ahead of the horse, but I acquired
>> a Netgear GS108PE managed switch from the local BestBuy. It's in service
>> now and seems to work fine, but the management is more awkward than hoped.
>
> Cool.
>
> Feel free to ask questions. I'll have to look at the manual and deduce
> things about that switch.
>
>> The layout for now is
>>
>> phoneline----DSLbridge---switch-----publichosts
>> |
>> |
>> router
>> |
>> workstation--WAP--privatenet
>
> Assuming that the switch is not doing any VLANs, I'm going to go out on
> a limb and say that there is no filtering between the ISP and the public
> hosts.
>
> Other than the lack of filtering, this is a perfectly valid network
> configuration.
>

At least now the public and private IPs aren't on the same switch.....

>> The switch defaults to management on a 192.168.0.x network in the absence
>> of a DHCP server (which I'm guessing must be upstream) and it isn't
>> obvious how to get at it from the private side.
>
> I would probably configure the switch to use a static IP for it's
> management interface and not even try to use DHCP and then fall back to
> something. (There's also the chance that it can DHCP from the upstream
> provider, if they support that.)
>
>> I probably could use an alias address on one of the public hosts, but
>> that seems awkward.
>
> You're closer than you might realize. You can put the additional IP on
> one of your public hosts, or you could put it on your router, which is
> also connected to the same network. (This is what I have done many
> times in the past.)
>

Indeed, it seems to work, with a small twist. After a couple days' runtime
the switch wouldn't answer its default address. If it was power-cycled and
then pinged, it did answer. Looks like there's a timeout of some sort.

The DI-524 router does not seem to allow more than one static route, so it
isn't apparent how to let a host on the private net administer the switch.

>> I could loop back a cable from the private side of the router to the
>> switch, but that makes me cringe even if it works 8-)
>
> I would advise against that. Doing that effectively connects the public
> side of your router to the private side. Then you're back to mixing the
> two networks. Which I'm confident you want to avoid doing.
>

Please count that idea as a badly-bungled joke..!

>> The router is a D-Link DI-524, updated to the latest firmware. It's
>> rather crude but will do for now. I'm guessing that a one-router setup
>> would put the router between modem and switch, using some sort of vlan
>> downstream to sort traffic between public and private nets; is that close?
>
> Yes, that's quite close.
>
> You can bridge traffic (with EBTables filtering) from the modem to a
> VLAN that the public servers are connected to, and route / NAT to the
> private VLAN where your internal systems are connected.
>
> phoneline---DSLbridge---router===switch---[public VLAN]---public host
> |
> [private VLAN]
> |
> workstation---WAP---privatenet
>
> --- regular Ethernet connection
> === VLAN trunk Ethernet connection
>

One option in the switch settings is a default route, which surprised me.
Now that's starting to make a little sense.

>> [on getting a secondhand openWRT router]
>>
>> Thank you!
>
> :-)
>
>> I'm in Davis, CA, a little west of Sacramento. There are thrift stores
>> in the area that have home networking equipment, I just need to keep
>> looking. There were a few Linksys routers for sale, but by the time I
>> went back for a second look they were gone. Not clear whether they were
>> sold or scrapped.
>
> ACK
>
> Things turn over faster in your area than in mine.
>
>> OpenWRT makes much of the need for sufficient flash and RAM in routers
>> for current versions. They suggest 8 MB flash and 64 MB RAM. That's part
>> of why I hesitated. Likely, knowledgeable folks can tell by looking at
>> the label, but I can't, yet.
>
> I can't tell off hand.
>
> I'd have to look at the OpenWRT site to see what models are supported.
>
> If I was on the hunt, I'd probably make a cheat sheet, or bookmark it on
> my smartphone. That way I could check while at the thrift store. ;-)
>

I've so far resisted getting a smartphone...Not sure how much longer I can
hold out.

>> I thought of the passive tap as a cheap alternative to a managed switch.
>
> Ah.
>
> It is an alternative to a SPAN port. But I'm fairly sure that won't do
> what (I think) you are wanting to do.
>
>> That's now water under the bridge, assuming I _can_ manage the switch.
>
> I'm betting that you will be able to.
>

The only barrier remaining is getting a usable browser on a public host.
FreeBSD is very good at CLI work, but GUI ports are kinda cranky, in
particular on ARM. Firefox worked for a while, but broke, and is a heavy
burden on a tiny computer. Lynx gets stuck at the login page. Epiphany
is next to try.

>> I really appreciate your help!
>
> :-)
>
> I enjoy helping ~> teaching people.
>
> I actually had someone send me a couple 2-liters of soda internationally
> as payment for helping them for about 9 months. I say internationally,
> he was in Germany and had a friend in the same town as me proxy the
> 2-liters. The 2-liters were more of a joke. But it was a fun joke.
>
> I did ask him, and I will ask you, to help someone else in the future if
> you can. :-)
>

Please be assured, I will!

bob prohaska

[bob prohaska]

Johann Beretta <ber...@nun-ya-bizness.com> wrote:
> On 3/8/19 4:52 PM, bob prohaska wrote:
>
>>
>> The modem/routers I've contemplated have four switch ports unless I want
>> commercial grade equipment, which seems extravagant.
>>

I bought an 8 port managed switch. It was slightly more extravagant than
intended. Less so than earlier options found. An existing simple router
provides the private network for now, but a better router is desirable.

>
>
> I'm coming in to this conversation in the middle, so I probably don't
> have all the facts, but from what I have read so far, I'd suggest you
> take a very detailed look at MikroTik's line of switches/routers and the
> base operating system for it, RouterOS.
>
> I suspect these routers and/or switches may be able to solve your issues
> or at least solve some of them.
>
> RouterOS is deceptively powerful and well documented so it bears a look.
>
> (not affiliated with MikroTik, I just use their routers, exclusively, to
> handle routing for my ISP)

I'd not paid much attention to MikroTik, but they seem well-represented on
Amazon. They also seem well-supported by openWRT.

I'll keep an eye peeled!

As a (probably unrealistic) side question, is there any established
protocol for evaluating network equipment with regard to security?
Manufacturers eagerly describe features and performance, but nobody
says a word about audits for buffer overruns and backdoors. Underwriter's
Laboratories made a good business out of testing electrical equipment
for demonstrable fire safety flaws in design and construction.

Is there any parallel in network equipment security? Is it even possible?
First guess I'd say "no", only because I can't think of a way. Hopefully
others are more skillful.

Thanks for reading

bob prohaska

[Grant Taylor]

On 4/5/19 10:00 PM, bob prohaska wrote:
> At least now the public and private IPs aren't on the same switch.....

:-)

> Indeed, it seems to work, with a small twist. After a couple days' runtime
> the switch wouldn't answer its default address. If it was power-cycled
> and then pinged, it did answer. Looks like there's a timeout of some sort.

Hum. That's mildly concerning.

> The DI-524 router does not seem to allow more than one static route, so it
> isn't apparent how to let a host on the private net administer the switch.
>

> Please count that idea as a badly-bungled joke..!

Been there. Done that. Moving on.

> One option in the switch settings is a default route, which surprised me.
> Now that's starting to make a little sense.

The switch's default route will be for the management traffic.

> I've so far resisted getting a smartphone...Not sure how much longer I
> can hold out.

Paper lists work perfectly fine for things you can research ahead of time.

> The only barrier remaining is getting a usable browser on a public host.
> FreeBSD is very good at CLI work, but GUI ports are kinda cranky, in
> particular on ARM. Firefox worked for a while, but broke, and is a heavy
> burden on a tiny computer. Lynx gets stuck at the login page. Epiphany
> is next to try.

To each his / her own.

> Please be assured, I will!

:-D

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/5/19 10:00 PM, bob prohaska wrote:
>
>> One option in the switch settings is a default route, which surprised me.
>> Now that's starting to make a little sense.
>
> The switch's default route will be for the management traffic.
>

Then maybe I don't understand.

Is it a destination for logging information?

In this case all the hosts can "see" the ISP's default gateway and
send their traffic to it through the switch.

Thanks for reading!

bob prohaska

[Grant Taylor]

On 4/7/19 11:08 PM, bob prohaska wrote:
> Then maybe I don't understand.

Switching is (usually) a layer 2 operation and doesn't care about IP
addresses, much less gateways. (I say usually because some special
switches operate on layer 3.)

> Is it a destination for logging information?

No, it's not a destination. It's a route to something that's not on the
local subnet.

The switch's default gateway is really functionally the same as the
default gateway for your computer. It's a route to use to get to
something that's not in the locally attached subnet.

For a switch, this is applicable to the management traffic. Like your
access to it via web and / or ssh. The switch won't use the default
gateway as part of the process of switching traffic based on layer 2 MAC
addresses.

> In this case all the hosts can "see" the ISP's default gateway and
> send their traffic to it through the switch.

That should be the case with what ever the switch's default gateway is
configured to be.

> Thanks for reading!
You're welcome.

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/7/19 11:08 PM, bob prohaska wrote:
>
>> Is it a destination for logging information?
>
> No, it's not a destination. It's a route to something that's not on the
> local subnet.
>
> The switch's default gateway is really functionally the same as the
> default gateway for your computer. It's a route to use to get to
> something that's not in the locally attached subnet.
>
> For a switch, this is applicable to the management traffic. Like your
> access to it via web and / or ssh. The switch won't use the default
> gateway as part of the process of switching traffic based on layer 2 MAC
> addresses.
>
>

Given this layout

phoneline-------dslbridge----------switch------publichosts
|
router
|
privatenet
|
workstation

would the gateway for the switch then be the public IP of the router?

At this point the router knows only about the ISP's gateway, so it's
not obvious how to move traffic from the workstation to the switch's
192.168.x.y address.

The router can be told its own IP, the ISP's gateway IP, netmask and
a MAC address, but I think the MAC address refers to what the router
advertises, not a destination. Looks like there's no option for adding
static routes.

No matter, I just learned a great deal!

Thank you,

bob prohaska








>
>

[Grant Taylor]

On 4/8/19 8:34 PM, bob prohaska wrote:
> Given this layout
>
> phoneline-------dslbridge----------switch------publichosts
> |
> router
> |
> privatenet
> |
> workstation
>
> would the gateway for the switch then be the public IP of the router?

Yes, that's what I would use.

> At this point the router knows only about the ISP's gateway, so it's
> not obvious how to move traffic from the workstation to the switch's
> 192.168.x.y address.

I would add the 192.168.x.y address to the router's outside. But I
don't know if that's possible with the firmware that's on it now.

> The router can be told its own IP, the ISP's gateway IP, netmask and
> a MAC address, but I think the MAC address refers to what the router
> advertises, not a destination. Looks like there's no option for adding
> static routes.

I would think the router would use it's own MAC address. At least
unless you had the router clone a MAC address. (Something I almost
never do.)

> No matter, I just learned a great deal!

Cool!

> Thank you,

[bob prohaska]

Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/8/19 8:34 PM, bob prohaska wrote:
>
>> At this point the router knows only about the ISP's gateway, so it's
>> not obvious how to move traffic from the workstation to the switch's
>> 192.168.x.y address.
>
> I would add the 192.168.x.y address to the router's outside. But I
> don't know if that's possible with the firmware that's on it now.
>

Far as I can tell it isn't possible. Another reason to look for a better
router.


Thank you very much, the solution was most unexpected.

bob prohaska

[Grant Taylor]

On 4/9/19 6:35 PM, bob prohaska wrote:
> Far as I can tell it isn't possible. Another reason to look for a
> better router.

ACK

> Thank you very much, the solution was most unexpected.

You're very welcome. You know where I'll be. :-)

[Johann Beretta]

On 4/5/19 9:38 PM, bob prohaska wrote:

> As a (probably unrealistic) side question, is there any established
> protocol for evaluating network equipment with regard to security?
> Manufacturers eagerly describe features and performance, but nobody
> says a word about audits for buffer overruns and backdoors. Underwriter's
> Laboratories made a good business out of testing electrical equipment
> for demonstrable fire safety flaws in design and construction.
>
> Is there any parallel in network equipment security? Is it even possible?
> First guess I'd say "no", only because I can't think of a way. Hopefully
> others are more skillful.
>
> Thanks for reading
>
> bob prohaska
>

Well, most routers are running some closed source OS, so auditing would
be nearly impossible.

Using MikroTik as an example, because that's what I use, there are
updates and fixes quite regularly. That's probably about the best you
can hope for short of building (or using) a router based on OpenBSD (a
Unix variant). OpenBSD has the best reputation in computing for "secure
out of the box".

Consumer routers are definitely out.. They get a couple of updates and
then are EOL (end of life) pretty quickly. Once that happens you're
screwed if an exploit is discovered. You want something that is updated
regularly and not abandoned.

[bob prohaska]

Johann Beretta <ber...@nun-ya-bizness.com> wrote:
>
> Well, most routers are running some closed source OS, so auditing would
> be nearly impossible.
>

Perhaps "auditing" is over-specific. Would "testing" be more feasible?
Things like buffer overflows, unsecured ports or services, acceptance of
admin traffic on the WAN side. Admittedly, the odds of knocking correctly
on a deliberate backdoor are very poor, but any testing seems better than
none.

> Using MikroTik as an example, because that's what I use, there are
> updates and fixes quite regularly. That's probably about the best you
> can hope for short of building (or using) a router based on OpenBSD (a
> Unix variant). OpenBSD has the best reputation in computing for "secure
> out of the box".
>
> Consumer routers are definitely out.. They get a couple of updates and
> then are EOL (end of life) pretty quickly. Once that happens you're
> screwed if an exploit is discovered. You want something that is updated
> regularly and not abandoned.
>

What do you think of things like openWRT, dd-WRT, tomato or other
open-source software running on a consumer-grade router? From afar
it would seem to offer both inexpensive hardware and ongoing updates.
However, I've never gotten close enough to any of them to actually
know what they're like to work with. Flashing new firmware doesn't
seem like a great barrier. Cross-compiling the firmware is probably
more than I want to tackle.


Thanks for reading, and any insights...

bob prohaska

[Johann Beretta]

On 4/13/19 4:01 PM, bob prohaska wrote:

>
> Perhaps "auditing" is over-specific. Would "testing" be more feasible?
> Things like buffer overflows, unsecured ports or services, acceptance of
> admin traffic on the WAN side. Admittedly, the odds of knocking correctly
> on a deliberate backdoor are very poor, but any testing seems better than
> none.

I don't know. Maybe.. I have a gut feeling that testing would only catch
old and well known vulnerabilities. The ones the hackers seem to
exploit are the brand new ones..

If you discover, for example, some new exploit in a Netgear router you
know is no longer in production, I think it would be reasonable to
assume that it's not going to be patched.. More than likely the router
is no longer maintained.. If I was the bad guy, I'd be looking for
those routers to infect. You're gonna infect it and it'll probably
never be patched.. Basically you'll own it until it's replaced or dies.

> What do you think of things like openWRT, dd-WRT, tomato or other
> open-source software running on a consumer-grade router? From afar
> it would seem to offer both inexpensive hardware and ongoing updates.
> However, I've never gotten close enough to any of them to actually
> know what they're like to work with. Flashing new firmware doesn't
> seem like a great barrier. Cross-compiling the firmware is probably
> more than I want to tackle.

I don't have much experience with any of those so I cannot comment with
any authority. I remember trying DD-WRT on a Ubiquiti PowerBridge way
back in the day. I wasn't overly impressed and quickly abandoned the
idea of running 3rd party firmware on Ubiquiti's hardware. That's not
to suggest that it's not great firmware.. It just didn't do it for me.

I have been far more impressed with RouterOS and the RouterBoard
hardware. My current business router is a Cloud Core CCR1009-7G-1C-1S+
with 9 CPU cores & 2 Gigs of RAM and and at home I'm using a Cloud
Router CRS109-8G-1S-2HnD Switch (kinda like a switch and router in one).

The CCR1009 is rated at several gigabits per second, but for me it's
usually averaging about 400mbps 24 hours a day.. Sometimes a little
more, sometimes a little less. This device is rock solid stable. It
only gets rebooted to apply firmware updates that are relevant, so
sometimes it goes 6 months at a time and it's never crashed.