Setup Behind Switches?

[RSJ]

Has anyone set up their Camect behind switches? I have nine Wyze cams, four Logitech cameras, and one Nest cam. I was going to install my Camect in my basement behind a switch. I have Verizon Fios GB connection to my house and am running Asus routers and Linksys switches. I was just curious if anyone has set up their Camect behind a switch/WAP or multiple devices and if the Camect was still able to detect all of your cameras? If it'll be an issue I'll just have to do some rearranging so it's connected directly to my Fios router. 

[CamectArup]

As long as we're really talking about a simple _switch_ hanging off your main router there should be no problem plugging Camect into it.  

If you're plugging into something more complex (i.e. something that's doing routing, running a firewall, then you may have problems). 

You want to put it somewhere that it can connect directly to your cameras (usually that means it's in the same subnet as they are) and also connect directly to your router. (If there's a second router between your Camect and your ISP router, you may have problems, or at least degraded quality, with access from outside your home.) 

[AAron nAAs]

I bought a 16 port PoE+ switch, made it its own subnet, and put Camect and all cameras on it.

I plugged the switch into my main home network (routes without restrictions for the moment).

That should keep all the camera traffic on that one gigabit switch, while keeping it all accessible from main home network (when requested).

This allows me to restrict traffic from the Camera subnet to my main home network (I just like the separation).

Here's what I did so far: My Story and Setup

Example:

Main home network: 10.10.1.0/24

Camera network: 10.10.2.0/24

Camect (static): 10.10.2.1

Cameras (static): 10.10.2.(10,11,12, ...)

No restricted access between Main home & Camera subnets yet.

 

Result:

Everything is working great, except....

Using the normal home.camect.com always has the cloud icon, meaning that all video is "relaying" across the internet to display on my screen.

I was going to get around to asking about why that is. Most of the time my phone would need to relay anyway, but relaying makes the video speed/smoothness hard to control.

As Arup points out, if I just had the switch as an extension to my Main home network, I'd just have one network and there shouldn't be any issues at all.

[CamectArup]

AAron: Is there NATing of this special subnet going on at your router? If so, that's probably why you wind up with the cloud icon.  (It's worth mentioning the cloud icon up top as a big possible caveat of using an extra router for people who aren't really network-savvy enough about configuring routing. Latency will certainly be higher if you're using a relay, and quality is often lower too.) 

Your phone shouldn't inherently require use of a relay unless your carrier is AT&T. Most other cell carriers in the US seem to be set up such that WebRTC can make direct connections (i.e. and not require the relay). 

[AAron nAAs]

Arup, thanks for the feedback.

I'll look for NATing & my carrier is Verizon.

My router is an Ubiquiti EdgeRouter and adding this as my first subnet came with some defaults.
I'm reasonable with network setup, but I'd definitely lump myself into that "not network-savvy enough" group. 

[RSJ]

I went ahead and set this up last night. I set it up down in my basement so it is behind a switch, possibly two switches I got to go back and look. I have stuff all over my network so I need to take another look to confirm. However, it picked up all of my cameras with no issues except for my Logitech alert cameras. I wasn't really expecting them to work with this since they are older cameras and for whatever reason Logitech decided to stop supporting the app. They were really good cameras, but I am looking to replace them with something else I just don't know what at this time. If anybody has any suggestions I would love to hear what you are using for outside cameras. I know some people use wyze cameras even though they're not made for the outdoors.

I'm still poking around and learning, but I did set up the telegram stuff in I have to say it's pretty damn slick! That's working perfectly and I'm getting all my notifications and short videos sent there it's pretty awesome. So far so good and I'm loving it!! I had been looking for something like this for quite a while so this is really awesome and it was perfect timing.

[Jason Sharpee]

I had a very complicated setup with my cameras and it all works well.

My farthest camera ~300ft wooded connects via:
4 port internet router with WiFi
-LAN-
8 port unmanaged Poe switch
-LAN-
4 port WiFi AP
-WiFi bridge to shed-
1 port WiFi extender
-LAN-
4 port WiFi AP
-LAN-
4 port unmanaged switch

[AAron nAAs]

Arup,

I wonder if the Camect is actively dropping activity from my "other" subnet.

I'm looking into why my Camect is "relaying" due to my network setup.

#1) I can fully access other devices across subnets (Ping, HTTP, RTSP)

#2) I can't access Camect by IP across subnets (Ping, HTTP)

#3) I can access Camect by IP from same subnet (Ping, HTTP)

Accessing Camect, it's not a routing issue or deny/refuse issue. Its like there's a Camect firewall rule that drops packets from outside it's subnet, causing spinning and timeouts.

I also checked that there's no NAT occurring between the subnets.

I appreciate the help, thanks in advance,

-AAron

Here's some details...

I'm using

Ubiquiti EdgeRouter managed router

Local subnet: 10.0.1.0/24

Home PC on 10.0.1.174

VidLan subnet: 10.0.3.0/24

Camect on 10.0.3.2 (static lease)

Amcrest camera on 10.0.3.99 (static lease)

Test PC on 10.0.3.100

Using Home PC (on Local subnet),

I can ping the Amcrest camera by IP.

I can ping the EdgeRouter by IP.

I can browse the Amcrest camera UI via HTTP.

I can view the Amcrest camera via RTSP & VLC by IP.

Amcrest's ConfigTool finds the cameras (even through I changed to all non-standard port numbers).

Camect

Pings to the Camect IP time out.

Browsing https://10.0.3.2:443 spins and times out.

Browsing https://home.camect.com/ works with all cameras but "relaying".

Using Test PC (on VidLan subnet),

I can ping the Amcrest camera by IP.
I can ping the EdgeRouter by IP.
I can browse the Amcrest camera via RTSP & VLC by IP.
I can ping Camect by IP.
I can use Camect at https://10.0.3.2:443

I can use Camect at https://10.0.3.2:443/debug/prof

Browsing https://home.camect.com/ works with all cameras without "relaying".

[CamectArup]

There's no firewall set up that would be actively dropping any packets. 

Is your Amcrest camera from 10.0.3.99 currently connected to your Camect? Please use "Report Bug" from your device so I can take a peek to see what Camect is seeing at the moment. 

(I don't think this is very likely but ... ) If you have traffic leaking from your local subnet to your vidlan subnet, it's possible that Camect has noticed some of this traffic, decided there is another subnet active, and is attempting to scan it. Since it has to make a guess about the netmask on another subnet like that, perhaps that causes issues routing packets back to you when you visit form the local subnet. We could try switching Camect to a mode where it will only scan the local subnet, and see if that will make a difference. 

[AAron nAAs]

Yup. I'm willing to help diagnose. I just sent the bug report as requested.

I wouldn't think there would be any traffic leaking. It's a newly setup and simple configuration with a quality managed router, but lets rule it out if we can!

I like that "scan only the local subnet" idea. It's what I would want/expect anyway for my setup.

The 10.0.3.0 subnet has 3 cameras, the Camect, and a laptop for testing. There's open routing between 10.0.3.0 and 10.0.1.0.

[Jason Sharpee]

If I were to assume correctly, you are running both subnets on the same physical media without vlan tagging or other layer 2 seperation?

If so and Camect appears to be in promiscuous mode, it may be seeing all broadcast traffic (arp) on both subnets right?

[Jason Sharpee]

Your 10.x.x.x is considered a Class A network with a presumed mask of /8, not /24. If Camect is indeed seeing all the traffic then it likely guessed /8 and is causing your problems (it is doing an ARP request for your local subnet devices and not going to gateway)

If this were me, I would switch to class C 192.168.x.x/24 networks. Or you could widen you mask if you really need all the IP space and go with a video lan of 11.x.x.x/8

[AAron nAAs]

Hi Jason,

I'm going to see what I can do about checking/fixing this.

Your explanation makes some sense, so I'm going to post some details to Ubiquity and see if I can isolate the traffic between the subnets more effectively.

I really want to confine VidLan traffic on its high speed subnet, but some requests and "Internet updates" access are necessary.

BTW, this is what my setup looks like, and by default the EdgeRouter allows traffic to talk across the 2 subnets.

(To simplify for posting to Ubiquity, I labeled the Camect as "Video Hub")

[Dolf Starreveld]

I'm an Edgerouter user. Your problems, to me smell like an EdgeRouter misconfiguration issue. A subtle one for sure. You mention that there is unrestricted traffic between the two subnets on the EdgeRouter. Are you saying that because there is absolutely no firewall configuration, or because you believe the configuration is set to allow it?

I take my cue from the fact that ping and https access on port 443 from the HomeLan to the VidLan does not work. This may seem contradicted by the access to the Armcrest working with RTSP (VLC also uses RTSP) but I'd note that these last ones essentially use the UDP protocol and your attempts with camect use the ICMP and TCP protocol (http uses TCP). It is possible that your firewall configuration is not symmetrically configured across all these protocols.

Now if you really do not have any firewall rules/configuration that theory obviously does not fly. If you do, and want to test further, enable logging on specific firewall rules and look in the system log to see what is being dropped to explain your problems.

Also check that your subnet configuration for each of eth1 and eth2 properly uses a /24 because the default of /8 would cause routing problems.

On a different, but somewhat related note: as long as you have an unmanaged switch that supports VLAN tagging (just preserving an honoring the tags), you could eliminate one switch and simply configure two different VLANs on, lets say, port eth1 and tie each VLAN to the respective desired subnets.

[AAron nAAs]

Hi Dolf,

I looked at my EdgeRouter and confirmed settings.

I didn't do anything fancy, and definitely avoided VLANs for now.

When I added the eth2 subnet, it allowed routing across the three by default.

EdgeMAX

EdgeRouter 6P v1.10.10

Dashboard shows

eth0, eth1 with /24, eth2 with /24.

Port Forwarding:

no rules

Firewall Policies:

eth0/in and eth0/local 

Allow established/related, drop the rest.

Routing: 

Each single subnet is listed for its interface (eth0, eth1, eth2), listed as "connected"

Strangely I found the computers can't ping the other across subnets:

When the Home PC 1 is on the 10.0.1.0/24 subnet, it can't ping 10.0.3.2 (Camect)

When the Home PC 1 is on the 10.0.3.0/24 subnet, it can't ping 10.0.1.101 (Home PC 2)

But

When the Home PC 1 is on the 10.0.1.0/24 subnet, I can still ping 10.0.3.100 (Camera1)

I took a look at the HDMI output Arup suggested to see some working stats, but nothing seemed strange/helpful there.

I'll need to wait till Sunday to get into this again.

If you've got any more diagnostic ideas, I'll run with them.

Thanks for the suggestions!

[Dolf Starreveld]

OK, now that we know this I am wondering if the network configuration of the Camect is not entirely correct. This may be due to your DHCP setup as well. Can you send you configuration's "show service dhcp-server" output (assuming you use the ER as your DHCP server).

[Dolf Starreveld]

I did some testing on my own network and, initially, I could not reach the local camect on VLAN 10 from VLAN 25. That was actually as expected, because VLAN 25 is my WiFi agues network, and I don't want random guests to establish new connections to other VLANs. I added a firewall rule:

rule 91 {
     action accept
     state {
         new enable
     }
 }

and all was working.

The caveat here is that both VLANs run a class C subnet 192.168.1.0/24 and 192.168.25.0/24. If either your DHCP advertises the wrong net mask, or camect code does the wrong thing and computes a net mask based on the presumed class of the network (in your case your 10.x.x.x networks are all class A and computed net masks would be 255.0.0.0) things could go wrong.

While I doubt your switches are implicated, you could remove them from the equation by directly plugging Home PC into eth1 and Camect into eth2. This would allow you to determine if, somehow, the switches are the problem.

[CamectArup]

For the main ip address (which is the only one on his system, since we turned off scanning for other subnets) Camect simply takes the netmask that's handed to it by the dhcp server. 

[ZzyzxOh]

This sounds like the default configuration for an EdgeRouter, since it will not "bridge" eth1 and eth2 as LAN ports unless you tell it to do so. If you used the default profiles there is one that provides this. I do not think that is what you want, however. You may be more interested in NATing to the CAMect (and not the cameras or PCs) and setting the EdgeRouter to let you through. I am assuming you do not want these bridged because it will make the traffic be everywhere.

My configuration is not identical to your as I have yet to isolate the camera subnet, but I do use two ERL units inside my ISP router. To manage the second router from the main subnet of the first router was pretty straightforward (and to limit it to that subnet access). I think that is pretty similar to addressing a Camect on that "isolated" subnet. I won't be moving to that configuration until the end of March so I will check back on your progress.

[AAron nAAs]

Arup,

I'm trying to avoid using your video relay, to get better responsiveness.

I'm debugging the routing to/from Camect, to find out why its ALWAYS relaying traffic rather than giving me a direct connection.

Here's my setup/subnets

• 172.17.203.2 (Camect)
• 172.17.203.100 (PC-A)
• 172.17.201.160 (PC-B)

As an initial test, I'm trying to hit

• https://172.17.203.2/
• Works for PC-A on same subnet (OMG, Camect is wonderful without relaying!!!!)
• Does not work for PC-B on different subnet

I have firewall accept rules logging each step of PC-B's traffic to Camect:

• LAN_IN - Logged request from PC-B to router on port 443 from 172.17.201.160 (PC-B) to 172.17.203.2 (Camect)
• VID_OUT - Logged request from router to Camect on port 443 from 172.17.201.160 (PC-B) to 172.17.203.2 (Camect)
• VID_IN - Nothing logged from Camect to router
• LAN_OUT - Nothing logged from router to PC-B

It really appears that Camect is not replying to requests from different subnet, but is replying to the same subnet.

(BTW, VID_IN is logging traffic from Camect to router to 35.202.229.234, 173.194.203.127, 104.154.100.179, and 8.8.8.8, but not to PC-B)

Please advise on path forward. I'll diagnose further but need your direction.

Thanks.

[TechnologyResearch]

What does the router log from the router -to- the Cametc? I would first
suspect your router is not relaying a route to the Camect subnet.

On 3/22/20 1:05 PM, AAron nAAs wrote:
> Arup,
>
> I'm trying to avoid using your video relay, to get better responsiveness.
> I'm debugging the routing to/from Camect, to find out why its ALWAYS
> relaying traffic rather than giving me a direct connection.
>
> Here's my setup/subnets
>

> * 172.17.203.2 (Camect)
> * 172.17.203.100 (PC-A)
> * 172.17.201.160 (PC-B)

>
> As an initial test, I'm trying to hit
>

> * https://172.17.203.2/
> * *Works *for PC-A on same subnet (OMG, Camect is wonderful without
> relaying!!!!)
> * *Does not work* for PC-B on different subnet

>
> I have firewall accept rules logging each step of PC-B's traffic to
> Camect:
>

> * LAN_IN - Logged request *from PC-B to router *on port 443 from

> 172.17.201.160 (PC-B) to 172.17.203.2 (Camect)

> * VID_OUT - Logged request *from router to Camect *on port 443 from

> 172.17.201.160 (PC-B) to 172.17.203.2 (Camect)

> * VID_IN - Nothing logged *from Camect to router*
> * LAN_OUT - Nothing logged *from router to PC-B*
>
> It really appears that *Camect is not replying to requests from
> different subnet*, but is replying to the same subnet.

> (BTW, VID_IN is logging traffic from Camect to router to
> 35.202.229.234, 173.194.203.127, 104.154.100.179, and 8.8.8.8, but not
> to PC-B)
>
> Please advise on path forward. I'll diagnose further but need your
> direction.
> Thanks.
>
> On Friday, January 24, 2020 at 1:50:19 AM UTC-5, CamectArup wrote:
>
> For the main ip address (which is the only one on his system,
> since we turned off scanning for other subnets) Camect simply
> takes the netmask that's handed to it by the dhcp server.
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Camect User Forum" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/camect.com/d/topic/forum/Vh73JAZM9iE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> forum+un...@camect.com <mailto:forum+un...@camect.com>.
> To view this discussion on the web visit
> https://groups.google.com/a/camect.com/d/msgid/forum/1df465fa-dcc8-41c6-9c5d-0a2b11934186%40camect.com
> <https://groups.google.com/a/camect.com/d/msgid/forum/1df465fa-dcc8-41c6-9c5d-0a2b11934186%40camect.com?utm_medium=email&utm_source=footer>.

--
Never reuse a password. Anywhere.
[4488ea0d-7c65-4410-8859-5abedaa03bd3v2019.01.24]

[AAron nAAs]

I could show you the log entries, but first I'll put a web server on the VID subnet and verify the routing you suspect.

> fo...@camect.com <mailto:fo...@camect.com>.

[John Groseclose]

It wouldn't be the first time I've seen someone forget to change the netmask when they're using the 172.16.0.0-172.31.255.255 (/12, or 255.240.0.0) ranges. Double-check that, too.

[AAron nAAs]

I see the netmask question, but everything appears properly configured to the /24 CIDR setup. LMK if there are more questions/guidance on this.

Here's my detailed tests and logs....

Addresses

• 172.17.203.2 (Camect)
• Netmask 255.255.255.0, Gateway 172.17.203.1 (confirmed below)
• 172.17.203.100 (PC-A) Windows 10
• Netmask 255.255.255.0, Gateway 172.17.203.1 (confirmed via ipconfig)
• 172.17.201.160 (PC-B) Windows 10
• Netmask 255.255.255.0, Gateway 172.17.201.1 (confirmed via ipconfig)

Notes:

• LAN switch plugged into LAN subnet 172.17.201.0/24 (private range)
  
• VID switch plugged into VID subnet 172.17.203.0/24 (private range)
• I used the same firewall rules for both tests below. I just changed the rule target destinations, so logging and "accepts" are all the same.
• Router is Ubiquity EdgeRouter 6P

Test: Success: From LAN subnet, access a test web server on VID subnet

LAN PC-B requesting from VID PC-A: http://172.17.203.100:8080/index.html

LAN request to VID PC-A (into Router LAN port, then out of Router VID port)

AAClamps kernel: [LAN_IN-2-A]IN=eth1 OUT=eth2 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.201.160 DST=172.17.203.100 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=23136 DF PROTO=TCP SPT=63141 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0 

AAClamps kernel: [VID_OUT-2-A]IN=eth1 OUT=eth2 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.201.160 DST=172.17.203.100 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=23136 DF PROTO=TCP SPT=63141 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0 

VID response from VID PC-A (into Router VID port, then out of Router LAN port)

AAClamps kernel: [VID_IN-20-A]IN=eth2 OUT=eth1 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.203.100 DST=172.17.201.160 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1870 DF PROTO=TCP SPT=8080 DPT=63141 WINDOW=65535 RES=0x00 ACK SYN URGP=0 

AAClamps kernel: [LAN_OUT-2-A]IN=eth2 OUT=eth1 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.203.100 DST=172.17.201.160 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1870 DF PROTO=TCP SPT=8080 DPT=63141 WINDOW=65535 RES=0x00 ACK SYN URGP=0 

Test: Failed: From LAN subnet, access Camect on VID subnet

LAN PC-B requesting from VID Camect: https://172.17.203.2

LAN request to Camect (into Router LAN port, then out to Router VID port)

AAClamps kernel: [LAN_IN-2-A]IN=eth1 OUT=eth2 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.201.160 DST=172.17.203.2 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=23193 DF PROTO=TCP SPT=63797 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 

AAClamps kernel: [VID_OUT-2-A]IN=eth1 OUT=eth2 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.17.201.160 DST=172.17.203.2 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=23193 DF PROTO=TCP SPT=63797 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 

VID response from Camect (into Router VID port, then out of Router LAN port)

-nothing into VID_IN port-

-nothing out of LAN_OUT port-

More Config

Camect:

EdgeRouter:

On Sunday, March 22, 2020 at 1:27:27 PM UTC-4, ZzyzxOh wrote:

> fo...@camect.com <mailto:fo...@camect.com>.

[Dolf Starreveld]

In my experience with any router/firewall (I use an ER5-POE) troubleshooting starts with simply disabling the firewall. You only have to do this for a few minutes, and only for the VLANs involved. You do not have to shut down the part of the firewall that protects you from the Internet. If the problem goes away, all further work goes into figuring what's wrong with the firewall setup. If it doesn't you can put the firewall back in place and not worry about it anymore.

Generally, simplification of the setup makes for easier troubleshooting.

[AAron nAAs]

Absolutely!

Here I'm using the router's firewall rules to target certain traffic for logging. I had merely added some "accept" rules to log specific source/dest traffic (not to shape or deny it).

To ensure I'm not actually causing the problem, I just disabled all the LAN and VID rules and my test got the same results.

LAN to VID worked to web server on PC, but LAN to VID, the Camect didn't respond (as if "dropped" rather than "refused").

There's not much in my firewall rules, but it was worth checking.

[CamectArup]

With the internal firewall off, can you ping your Camect device from the PC on the other subnet?

[AAron nAAs]

No.

[AAron nAAs]

For a while I've wanted to convert to more conventional subnet ranges.

There's no obvious reason why switching from one private non-routable range to another should make a difference, but we'll see what happens.

In a day or so I should have these subnets:

• LAN 192.168.1.0/24
• VID 192.168.2.0/24 (Camect & cameras)
• GUEST 192.168.3.0/24

Are these more conventional for Camect known scenarios?

[CamectArup]

I agree that there's no obvious reason that switching to more conventional subnets should make a difference. What you propose is closer to what other people use though. 

The kernel routing table you see in the diagnostic output tells the full story ... i.e. Camect knows how to route to your second subnet, assuming 172.17.203.1 will accept and forward the responses Camect.  There is no firewall to drop packets as you have been wondering about. It's clearly able to talk to the internet through your firewall, and I think it's probably also responding to your other tests, but in some way that's not showing up in how you're checking. 

The port 443 test is a bit iffy, because Camect won't respond on port 443 to non-local connections. There is no reason that ping should not work though. 

My money is still on something weird about  the firewall configuration. Unfortunately, I don't know anything about Edgerouter so I can't help much with that. 

I'd like to see an actual packet trace of the traffic (rather than logging from firewall rules) if there's any way to get it. (i.e. With your port 443 test I'd expect to see a SYN packet from the PC to camect, and then we could see if there's a SYN-ACK sent back from Camect in response, and whether that packet makes it beyond the router.) 

With the firewall off, if you ping from the remote pc to Camect, what exactly happens? Are there simply no replies, or are any errors printed too? 

[AAron nAAs]

Current

It all works.

I finished changing my network last night, merely editing my config file and renaming the 3 subnets by replacing the 172.17.201.'s to 192.168.1.'s, etc. Otherwise I left the router setup (& firewall rules) exactly as it was.

I can now ping Camect (192.168.2.2) from PC (192.168.1.160).

I can view Camect web page without relaying (performance is wonderful).

I can view Camect web page from IP address.

Theory

If Camect has no rules/firewall, then my odd private network subnet range was confusing your host OS. Maybe only typical ranges 192.168.*.* and 10.*.*.* are properly considered as private?!?

Historical

I had turned off the firewall rules on my router, and still got no response. There's no place that errors print out. I wasn't ready to dive beyond my current logging-via-firewall-accept-rules into packet snooping.

Thanks for all the help/info/suggestions.

I'm really glad to have gotten this working as intended.

[Jason Sharpee]

Worked on way to much gear to rely on CIDR actually working everywhere. Even Cisco IOS had bugs in the early days with this.

[FredJenks]

I noticed the POE switch you purchased only has 8 of the ports with POE+.  What is a good option for a switch to power more than 8 devices?  I will have 10 cameras total.

Thanks  

On Sunday, January 5, 2020 at 7:13:27 PM UTC-8, AAron nAAs wrote:

I bought a 16 port PoE+ switch, made it its own subnet, and put Camect and all cameras on it.

I plugged the switch into my main home network (routes without restrictions for the moment).

That should keep all the camera traffic on that one gigabit switch, while keeping it all accessible from main home network (when requested).

This allows me to restrict traffic from the Camera subnet to my main home network (I just like the separation).

Here's what I did so far: My Story and Setup

Example:

Main home network: 10.10.1.0/24

Camera network: 10.10.2.0/24

Camect (static): 10.10.2.1

Cameras (static): 10.10.2.(10,11,12, ...)

No restricted access between Main home & Camera subnets yet.

 

Result:

Everything is working great, except....

Using the normal home.camect.com always has the cloud icon, meaning that all video is "relaying" across the internet to display on my screen.

I was going to get around to asking about why that is. Most of the time my phone would need to relay anyway, but relaying makes the video speed/smoothness hard to control.

As Arup points out, if I just had the switch as an extension to my Main home network, I'd just have one network and there shouldn't be any issues at all.

[John Groseclose]

If you're wanting to get into managed switches, I'm a big fan of Ubiquiti's hardware. Powerful, reasonably priced, easy to manage.

Their UniFi line is pretty stellar. And it integrates nicely with their WiFi APs.

https://www.ui.com/products/#unifi

[AAron]

Agree with Groseclose. I too like Ubiquiti equipment and there's good stuff in the UniFi line... but if you just need a POE switch with lots of ports, you could do almost anything. I went with Linksys after considering price and feedback on amazon.

Make sure the switch can handle the wattage pull of all your cameras.

-AAron