Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About CPARMUK
Community Record
7
Posts
0
Kudos
0
Solutions
Badges
09-23-2022
11:21 AM
This is the only AP we have up at the moment, and it only services the needs of about 4 or 5 people at once. All other network connections are hard wired. We did pull one of the switches from our existing stack- that one was used as the temporary switch during the move- but that switch wasn't actually being used for anything on the existing stack, it was just extra ports if we needed it. The AP was what changed ports on the stack. Currently the AP is configured to draw from our primary DC- a virtual DC- and our physical DC for DNS.
... View more
09-23-2022
11:10 AM
Yes. The SSID is tagged to a specific vlan which is provisioned for on our DNS server. All settings were tested and known to work fine prior to this server relocation so unless losing internet connection temporarily and briefly being plugged into a temporary switch while we relocated the stack has some kind of rule that changes settings, everything is the same as it was prior to the move, except that switch port is different. But I don't think it's that because the same AP with a different SSID has no problems.
... View more
09-23-2022
10:57 AM
Recently I had to relocate my company's server room from one location in a build to another. Things are mostly back to normal but my one remaining meraki AP (MR42's) has lost internet connectivity on the BYOD SSID. Other than an allowance for spanning-tree portfast the current switch (Cisco) port config it's plugged into is identical to it's old port config, and it's using the exact same internet connection it had previously. This is all the exact same hardware as well- same switch stack, same AP. I know the AP itself is working fine because the wifi for company devices has internet access and I can ping google from the meraki interface for the BYOD SSID. When I do connect my company laptop to the BYOD SSID the process seems to take longer than expected and gives me an APIPA address for my IP. So I figured it was a DNS / DHCP issue and sure enough when I look up the SSID in Meraki it's citing DNS problems with the error Client made a request to the DNS server, but it did not respond.type='NO DNS response' associated='true' radio='1' vap='1' Except the Wireless AP is configured with the correct DNS, and it works fine with the primary SSID, just not the BYOD SSID. How should I proceed with this? I'm out of ideas.
... View more
Labels:
- Labels:
-
SSID
03-08-2022
01:02 PM
That ended up being the solution. I'm waiting for an end user to confirm it works for them but my own testing demonstrated that it worked. I thought that setting was granting VPN users access to those given subnets so for security reasons I didn't want people with VPN access to be able to meddle with the VPN VLAN.
... View more
03-08-2022
12:48 PM
The hub is set to 'routed' mode, not 'passthrough or VPN concentrator.' The spoke is also set to 'routed.' Does the spoke's VPN config page matter? Because every VLAN we're trying to access has VPN turned on. Again, we're running our VPN out of our hub, not the spoke. The VLAN for VPN connections is on the hub. As for the hub's VPN config page, VPN is enabled for all VLAN's that we need access to, but the specific VLAN set aside for the client VPN has it disabled? I'm guessing that specifically refers to VPN access to objects located on that specific VLAN? @Ryan_Miles wrote: Could be the spoke is using split tunnel and traffic back to the VNP client via the hub isn't being advertised so it's going directly out the spoke's internet link? I have no idea. I know that the spoke's router connects to it's switch from one port, and then has a single internet connection, but for whatever reason it's not plugged into the designated 'internet' port.
... View more
03-08-2022
11:04 AM
VPN is allowed on both networks, Site-to-site VPN is active, every VLAN that would have network devices we are trying to connect to is allowing it, client VPN's are active on both networks, and I allowed the relevant user accounts in client VPN to connect to either network. All of this works normally, as intended when you're on the hub or spoke's network directly, and you can access anything you're allowed to access on either network. The problem only comes up when someone connects to the network remotely via VPN and then tried to connect or access something on the other network. Specifically I am trying to connect to the hub's network via VPN from home, and then access a device on the spoke's network.
... View more
03-08-2022
10:36 AM
Hello, I'm experiencing an issue that I've been able to replicate on standard user accounts and admin accounts, on multiple devices. I have two separate networks (meaning it's a two hour car ride from one to the other) both running Meraki MX64 routers that talk to each other, one's the hub, the other a spoke. As long as I am physically at either office I can access everything on the network fine, including RDP'ing (windows 10 computers, virtual machines running anything from Server 2010 to 2019) to virtual machines, accessing a file server, and a few physical devices like two security camera boxes. The problem I'm running into is when I connect to the office via VPN (Meraki's VPN service), which we run from our hub router, we can't RDP or access anything running out of our spoke's router. I get the same "make sure you typed in the address correctly" error as though I'd entered a bad address. I am out of ideas on what to even try at this point, and whatever my problem is the language is so vague that google searches find everything except my specific problem. It's not a permissions issue because even top level admin accounts can't access it, VPN is allowed on both networks, this works normally when I do it from the hub's network when I'm in the office, the only difference is that I'm connecting to the office via a VPN remotely instead of the office's network directly.
... View more
Labels:
- Labels:
-
Client VPN
