(Reverse) Printing Through MX64 Client VPN Tunnel

[AJ]

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?

[PhilipDAth]

Use a Z3 then you can physically plug the hardware in and have no more issues.

https://meraki.cisco.com/products/appliances/z3

[AJ]

@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.

[Ben]

@AJ,

What app server setup do you have? (Citrix, RDWEB, ..)

Because depending on the technology you're using client printing devices can be mapped on startup of the remote app.

If it's a remote desktop connection than the option needs to be set that local resources can be used in remote connections. 

Regards,

Ben

[AJ]

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.

[Ben]

@AJ

What you could try is install the drivers of the thermal printer on the server the client is connecting on and try to print

.

Printer redirection is a tricky one.

Many things can go wrong because the print queue is created in the remote session for a not so standard printer(thermal one) and there is a chance the server simply does not know the correct driver to assign.

You can find a lot of threads regarding barcode printers online. Issues should be fairly similar to what you are experiencing. 

This could result in a redirected printer not showing up in the session or print jobs not beeing correctly forwarded in the queue

Cheers,

Ben

[AJ]

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.