We really need a diagram in order to figure out what it is you're describing. ... View more

I don't see any mention of VLANs in the configurations in this discussion.  I have settled on making (i.e. keeping)  VLAN 1 (the default) the management VLAN.  With some Cisco devices, this seems to make a difference.  Example: If you have a VLAN 2 that's set to be the management VLAN and if you assign VLAN 2 to port 4 only and if you try to communicate via GUI on port 4 after upgrading the firmware .. it may not work.   But, if you leave management on VLAN 1 then it seems to work OK. My theory is this: In the process of upgrading the firmware, the ability to communicate with the device over the management port & VLAN is disrupted and the process doesn't finish .. something like that.   ... View more

It's rather critical how the rules are *ordered* in the list of Access Rules.  The first rule applies before the 2nd rule, etc.  So, if the block rules you listed fall below a rule that allows the same traffic, the later rules do nothing. ... View more

Here's a thought:   Either you expect to manage "in band" using an existing subnet or your expect to manage "out-of-band" using a workstation that's on a separate subnet. In the first case, you assign the selected VLAN for management and that's all you need to do. In the second case, you establish a 3rd VLAN (I would recommend VLAN1) with whatever IP address matches the management workstation(s) subnet and assign management to that VLAN. ... View more

Some companies call this "DHCP Relay over VPN".  The RV042 has a setting in DHCP Setup "DHCP Relay".  I would think you'd want that UNCHECKED unless there's a separate good reason for it: "DHCP Relay (IPv4 only): If you have another DHCP server, enable DHCP Relay to allow this router to communicate the clients’ DHCP requests to the DHCP server. The DHCP Relay mechanism allows the DHCP clients and the DHCP server to be located on different networks. The DHCP clients will send DHCP discover broadcast packets to get IP addresses from the DHCP server. This router will act as DHCP Relay agent and send DHCP unicasts to DHCP server."   Is the RV042 also the local site gateway or does it have another unique public IP address? ... View more

Well, I have no experience with using L3-configured switches.  There's a reason for that: I prefer to be able to consider the network in an understandable topology.  Mixing switching and routing departs from that idea.  I've not found situations where this seemed to be a hindrance.  Using VLANs departs from this objective but I do it for VOIP in order to preserve wiring and to add fewer switches to the core infrastructure. That's not to say that you don't have a reason for using L3.  It may be routing between the subnets.  But that can generally be done at the gateway level of the topology - albeit with more traffic overall perhaps.   Consider this:  "a network with nothing but unmanaged switches and all the complicated configuration in the router(s)". Then a switch can be used without regard for ports, etc. and a wider set of folks can help out.  Also, you don't need a diagram or port list for *yourself*. I depart from this in order to implement mirror ports - and usually standardize on Port 1 for the mirror port destination.   So, I would rather set a route in the gateway that directs traffic for the "other" subnet to a particular router port under the assumption that the subnets are physically separate.  I realize this may not be the case. I don't understand what makes the CLI inaccessible in your case. I have seen routers which could be accessed for management from ANY subnet/VLAN.  I must admit that I was a little surprised.  At least I'd expect the management interface to be accessible from ONE ip address - and that may dictate a particular port(s).   ... View more

I don't know what kind of traffic you'd need to worry about looping.  These aren't switches.   Traffic is *routed* from one site to another via one of the VPNs.  Once there, it has no reason to traverse to another site (and no address for doing so).  At least that's my understanding of how things work. Even if you allow NetBIOS traffic, it goes from one site/subnet to another.  I've certainly done this and there were no problems other than having name service over NetBIOS was not something anyone could advise me on really.  So I abandoned it as not being supportable by the community.  But, while it was there, it worked.  These days, that kind of name service is going away.   With VPNs there should not be the type of path that you describe going from A to C through B.  The paths remain clear just as in a hub and spoke arrangement.  In fact, the paths from B to C and from C to B are *clearer* as A would not be involved by any mechanism.  In words, the routing looks like this example:   Subnet A 10.0.1.0/24  Public address: 1.1.1.1 Subnet B 10.0.2.0/24  Public address: 1.1.1.2 Subnet C 10.0.3.0/24 Public address: 1.1.1.3   VPN A-B from 1.1.1.1 to 1.1.1.2 with terminating subnets 10.0.1.0 and 10.0.2.0.  Nothing about C here. VPN A-C from 1.1.1.1 to 1.1.1.3 with terminating subnets 10.0.1.0 and 10.0.3.0.  Nothing about B here. VPN B-C from 1.1.1.2 to 1.1.1.3 with terminating subnets 10.0.2.0 and 10.0.3.0.  Nothing about A here.   A packet launched in subnet X and destined for subnet Y will be routed to the X-Y VPN and the packets will arrive at subnet Y and that is all.  Perhaps that's a bit of a simplification but I think that's all there is to it.  Well, except the return path has to be supported and that generally involved the recipient's local gateway.  If the gateways ARE the VPN devices then this isn't generally an issue.  If the VPN devices are separate from the gateways then the gateways have to know the local IP address for the VPN and route packets accordingly. ... View more

OK.  So first I'll paraphrase your situation and requirements as I understand them. I presume you're using the switch in Layer 2 mode.  Is that right? Also, it seems that the two modes will be used without recabling the switch to various computers.  Is that right?   "An Ethernet connection will be used so the configuration can be switched by a management computer."   This requirement, plus the 2 modes, suggests 3 VLANs to me.  We shall see..... One thing I'd advise is that the "IP Address" for the switch isn't exactly what one might expect.  It's best to view the "switch IP address" as the "management interface address" and that's all.  So, in some sense, it could be *anything* and not at all related to any of the attached device's addresses.  You could switch all manner of devices and then use an entirely separate IP address for management.  So, it's not really an issue on the switch side of things.   "The first use case involves a subnetwork which has to be able to communicate with many other subnetworks but only one at a time. E.g. A computer with the address 10.0.1.162/29 has to be able to talk to another computer with ip 10.0.1.2/30. For this I defined VLAN 1 with ip 10.0.1.161/29 and VLAN 10 with ip 10.0.1.1/30. Assigned each VLAN to the correct interface and it worked." Well, of course it would be typical to assign an interface to at least one VLAN but the IP address only applies to the management IP address and is tied to a VLAN - that is, it is present on that one VLAN. So that's how you reach it.  The other VLANs don't care about IP addresses as communication is via the MAC layer. I don't know how you assign an IP address to multiple VLANs - but you certainly can USE a VLAN for one subnet or more.  What is it that you did here? Here perhaps one VLAN for management and two more VLANs for the connectivity you want.  The network architecture is a bit fuzzy and the overlapping subnets is a concern.   "The second use case is much simpler since the the SG300 should just work like an unmanaged switch. However, I'm not sure how to set this up correctly such that I'm still able to access the CLI via an ethernet connection. The simplest configuration would just be to remove the IP address vom VLAN 1 and assign it to all ports but then only managed to access the SG300 via console cable.   The connection via ethernet is needed since the configuration should be switched by a computer only connected via an ethernet cable to the SG300. I would likely set up a VLAN, associated it with switch management and give it and IP address so either GUI or CLI interfacing can be done.  I might assign this VLAN to 2 ports on the switch and only use those ports for management access.  (2 ports for redundancy).  Then I'd cable the management computer(s) to one of those ports.  But there are any variety of approaches that might best fit your objectives. Then I'd use all the other ports on one VLAN for the intended switch function. I don't understand the emphasis on "unmanaged"... ? ... View more

Yes, you have the right idea.  Add one VPN between the two satellite sites.  The RV320s support this nicely. ... View more

It rather sounds like DHCP traffic is traversing the tunnel and it had not been doing that before. I'd be looking at what type traffic is allowed and what type traffic is not allowed in the VPN / Gateway To Gateway Page with Advanced expanded.  It seems to me this would be the most likely place in settings to cause such a thing.  Perhaps Remote Backup IP Address?  I've not had the same environment to have used this or seen this.     ... View more

See my other post about using Port 8007 here in Small Business Routers.  That may help. Summary: Can access the router with https://(address) Can access some routers with http://(address):8007 In the end, I don't think it's browser-specific although it can seem that way if some browsers aren't flushed of old data.   ... View more

Sorry, I'd solved this problem last year but had lost track of the thread where I described the solution.   It appears there's a bug in firmware at least as recent as 1.4.2.19 and, I'm rather sure now including 1.4.2.20. It has to do with the VLAN setup if starting with earlier firmware where it works (e.g. 1.3.2.12)   Here is my description of how it was fixed / worked around:   At first, I suspected the firewall and Access Rules but they didn’t cause the problem as I added them. Next step was the VLAN configuration: The original VLAN configuration was done like this: Delete default VLAN 25 Delete default VLAN 100 Add new VLAN 2 and used this for Management. Add new VLAN 3: This leaves default VLAN 1 which was originally for Management and is now unused. Here’s the result that is running on 1.3.2.12 but won’t work for GUI login on 1.4.2.19: Then, when building it over again on 1.4.2.19, I did this: Deleted default 100 Renamed VLAN 1 and VLAN 25 and used them. Used VLAN 1 for Management Here’s the result: This one seems to survive a reboot and lets me log in. It occurs to me that maybe having Management on a VLAN other than 1 is the culprit here.   I hope this is helpful to someone! ... View more