Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About AJ
Community Record
11
Posts
0
Kudos
1
Solution
Badges
Sep 28 2023
10:14 AM
I'm not sure what happened. Previously the only WAN public IP returned by PHP's $_SERVER['REMOTE_HOST'] was the firewall's. All LAN client private IPs were already visible. Now I'm suddenly seeing WAN client public IP's via that server variable. I didn't change anything on the MX. Thank you for helping. You clarified that the MX is already configured as needed. I'm wondering if there's something in IIS that maybe mucking things up.
... View more
Sep 28 2023
8:45 AM
I may be looking at the wrong settings, but when I attempt to make a 1:1 NAT or 1:Many NAT, it wants me to set up a known public IP for use by an LAN device, but that's not what I need. I do have a port forwarding rule to get HTTP traffic from the WAN to the LAN web server, and of course the web server sees the firewall's IP as opposed to the user's IP. What I'm attempting to change on the incoming packets is the WAN user's IP, so the LAN web server can see that instead of the firewall IP.
... View more
Sep 28 2023
6:39 AM
I have a publicly accessible web server, and I'd like for it to receive all users' public IP addresses, rather than the firewall's address, so that it can attempt to cooldown and ban bad actors that try to hack a portal login. Other communities say that it's possible for some firewalls to replace the forwarded packet's IP with the user's real IP instead of forwarding its own IP address. Can this be done with a MX64? I don't want to capture the HTTP_X header info, since that can be spoofed by the user. JS based answers mention that they can capture and send a client's IP address, but then it's usually a private one.
... View more
Dec 1 2019
2:32 PM
Closing this question. Verified that the problem I had is only found with Windows 7, which is now antiquated. Again, this was observed only the remote site (Site2), so I'm assuming this has something to do with the poor-quality Internet connection. Taking care of this on a Sunday proved to work better.
... View more
Nov 30 2019
5:52 PM
That particular setting is handled via group policy. Members of D1 have the suffix order of "D1.COM, D2.COM", and members of D2 have search order of "D2.COM, D1.COM".
... View more
Nov 27 2019
8:06 AM
Background: "Site1" and "Site2" have been communicating with each other for several years via Meraki MXes (same models) with no DNS problems. They have their own subnets, which the MXes are aware of and route properly. There was one DNS server in Site1, which Site2 has been using without issues. Both sites have been operating in the same AD domain. All servers are at Site1, so Site2 has DHCP handled by the MX. Basically, everything has been hunky dory with the site-to-site connection (aside from Internet service burps). Now, I'm transitioning our network from one domain ("D1") to another ("D2"). D1 and D2 are setup with proper trusts, both have DNS servers that aware of each other. The workstations at Site1 have no problem with finding each other between D1 and D2 via DNS and have no problems with security (that I'm aware) between D1 and D2. Problem: When I transition a workstation at Site2 from D1 to D2, it fails to handle DNS resolution. It won't find anything on either D1 or D2, despite it still being assigned the DNS server from D1 (which is not a problem for any workstations at Site1). I can run NSLOOKUP from the command prompt, and it will indicate the correct DNS server, but it fails to resolve any names. Pinging by IP address works fine. The MX at Site2 is able to ping DNS servers in both D1 and D2 by short name. There are no WINS servers in either domain. At Site1, only D1 has DHCP services. All of Site1 is on the same subnet, no matter which domain. I attempted this transition on two workstations at Site2, both Windows 7, and they both have the same issue. They have no problems with DNS when I move them back to D1. Again, no workstations in Site1 have any observed DNS or security issues. Any ideas on what's going on? (edit) Now that I think about it, there was a strange error message when attempting to join the new domain. Something along the lines of, "Changing the Primary Domain DNS name of this computer to "" failed. The name will remain "D2.COM".The specified server cannot perform the operation." MS says that this happens due to security package or RPC failure and it appears to be related to only Windows 7/Server 2008 (which we are phasing out). I'm guessing that there's a latency and/or subnet translation issue that's causing problems with the domain join attempt. I may have to find a way to join the Site2 workstations to D2 by putting them directly into the Site1 subnet (physically or by client VPN). Then once they are joined to D2, maybe they won't have DNS issues while using the site-to-site VPN.
... View more
Apr 17 2018
9:13 AM
I think your point on searching more for thermal printer threads may be the way to go in this circumstance, as it appears that I'm not able to get the MX64 to do anything particular that would help with this. As for the printer drivers, those were already installed on the server. More recent sessions have been showing the printer to appear as redirected, but the printer's queue gets stuck. I tried a different solution, for the sake of testing, where I installed the printer on the server as a shared printer from the client, but it seems that the RD session refuses to list any shared printers at all. Not sure if that's a RD feature or a GP issue--have to look that up. FYI: This was done during a single VPN session so as to not lose the client's address for the share. Now that I see MS RD services won't list shared printers (unless I find otherwise), the point of having the MX use an assigned or reserved IP address is moot here. I have a feeling that this may end up boiling down to printing a PDF to client desktop, then print that to thermal. Came to my senses and remembered that shared printer installations are per user, which means setting this up as admin was the reason for it not working. Just tested and got a successful print to a shared Zebra (not redirected) over RDP. So I'm right back to my original need for establishing a static address mapping to a VPN client. The only thing I can think of is to set the client pool to 1 address only. This of course means only one client can access at a time. 😞 I'm starting to like the Z3 idea.
... View more
Apr 10 2018
7:48 AM
@PhilipDAth I'm looking for more details on this. Does the Z3 behave as if it were a site-to-site VPN? If so, that would indeed solve the problem. I have no issues with printer sharing through S2S, but the extra subnet mixed in from the client VPN setup seems to be giving problems. At the very least, DNS is just not working to access the client, and I can't rely on dynamic IP addressing. Of course the MX won't let me create a static route from the office to the client subnet. I suppose the client VPN automatically defines this, but it's clearly not doing what I need.
... View more
Apr 10 2018
7:02 AM
We are using Windows Server 2012 Remote Desktop Services. Please note that simple printer redirection is not necessarily the solution, not because of resources generally failing to map, but because this is a thermal printer. The client's desktop printers redirect and work just fine, but the thermal printer fails to list. With testing another client, the thermal printer does list, and pretends to print, but nothing comes out the printer. This is an issue with thermal printers not working in the same manner as laser/inkjet printers. Microsoft's remote desktop "easy print" doesn't particularly work for thermal printers. The server setup for the remote app doesn't directly handle assignment of resources (that's up to Group Policy), but all RD clients we have are automatically redirecting their desktop printers with no problem. Maybe I'm missing something else that does more robust redirection or resource handling. This question seeks a way to let the VPN client reliably share resources over the network, since I'm not having faith in Microsoft RDP handling this.
... View more
Apr 9 2018
2:48 PM
I have a VPN client that needs to tell the office's remote app server to print at the client's location. Normally RDP redirection will fix this, but not for thermal printers. The way I see it, the remote app server needs to have the client's printer installed via share, but I can't figure how to create a stable connection to that printer. I can ping the client's IP address (assigned by MX64 VPN client setup), once I know that address, but I can't ping it via DNS. The client is assigned a DNS server inside the office (via MX64 VPN client setup), so the client can access office resources via DNS. However, the office can't access client resources via DNS--it just fails. I see the office server assign an internal IP address and DNS record to the client, but requests to either fail. I've also tried assigning a static IP address to the client via Windows VPN adapter settings, but then the client fails to connect to the MX64. I see no way to make the MX64 hand a static IP address to the client. Any ideas how to reliably access the client's printer?
... View more
Apr 5 2018
1:17 PM
Would someone be so kind as to mention what features AnyConnect has over native Windows 10 VPN client? I had used AnyConnect years ago and don't recall what was so great about it. It was good, but didn't seem that wonderful. The Windows 10 native client seems just as easy to setup and even easier to use. Specific point of interest to me: Does AnyConnect allow me to give a static IP address to the client and still connect to a Meraki? Win10 client allows this (technically), but it fails to connect unless set to DHCP, even though the static IP is within the Meraki's assigned VPN client address range. I redact the previous paragraph. Turns out that Windows Firewall was causing problems. Got my client connected with a static IP address after turning it off.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 3983 | Dec 1 2019 2:32 PM |
© 2024 Cisco Systems, Inc.
