Pertino - Is Anyone Successfully Using Any Version Above 510 with DNS/AD Connect?
-
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
-
@wrx7m said:
@scottalanmiller I don't want any home user to access that but I, as the admin, do want access to them from a remote location.
But not on the ZT, access in ohter ways, through a jump system, right? ZT wouldn't be a limitation there.
-
-
@wrx7m said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
I was referring to Pertino in terms of how easy it is supposed to be so I am deploying it in the manner in which it is designed to be deployed. It just doesn't work.
What manner was that?
*nevermind - scott already asked.
-
@scottalanmiller I can use a jump system. I just hate doing it that way.
-
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
-
@Dashrender Using their gateway feature and installing the client on remote users' laptops
-
@wrx7m said:
@scottalanmiller I can use a jump system. I just hate doing it that way.
But isn't that the better way and keep it away from the end users? This just seems like a lot of "problem" introduced for the purpose of putting things like switches on the network extended to the users' homes.
-
@wrx7m said:
@Dashrender Using their gateway feature and installing the client on remote users' laptops
I've definitely spoken to the main designers about that feature and they were very clear that while it could theoretically be done, it could never work easily and was not part of the design because of the known issues that that would cause. Anything involving the gateway cannot involve "as designed."
-
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
-
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
But you are extending it "to that network" one way or another. So you expose it, then add a firewall to limit access. Seems like more and more complication to do things in an odd way, then to mitigate the problems introduced by doing so, etc. What makes a jump device so bad?
-
@scottalanmiller LOL - Semantics. The gateway product was "developed/engineered" for the purpose of allowing access to devices that did not have the actual client installed on them.
-
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
How did that work? Unless you had multiple Pertino networks? i.e. the home users are on P1, and the gateway/swtiches are on P2.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
Ah, so was still a network printer. That's what I missed. Of course if you are running an AS/400 the wheels are about to come off the wagon and ZT isn't an option anyway.
-
@Dashrender said:
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
How did that work? Unless you had multiple Pertino networks? i.e. the home users are on P1, and the gateway/swtiches are on P2.
Extra firewall.
-
@scottalanmiller Well, with ssh it would not be so bad but in the world of gui, it is a pain because you are resizing windows and scrolling and waiting for screen refreshing, etc.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
Ah, so was still a network printer. That's what I missed. Of course if you are running an AS/400 the wheels are about to come off the wagon and ZT isn't an option anyway.
I was simply talking about a single example.. you would replace AS/400 with Linux box - now how would you solve it? I'm guessing there is a way to make a print server on Windows that linux could talk to over the ZT network, yes?
-
@wrx7m said:
@scottalanmiller LOL - Semantics. The gateway product was "developed/engineered" for the purpose of allowing access to devices that did not have the actual client installed on them.
Well as anything in IT, semantics are all important. The gateway was "removed for being banned" in order to make sales. It was developed before the "deploy everywhere" method and it was not released because it was only developed for testing and had no means of being used well. So even its design was not for that. It's like someone buying a writer's body of work after they are dead and releasing their scraps and saying it was the book they "intended to write" when, in truth, it was the garbage they didn't want anyone to see as it wasn't a polished book or meant to be. The gateway was not designed for how it might be being sold under Cradlepoint.
And it is very, very important to understand that none of us recommended the system you are discussing or saying that it was easy. I realize that the name is all Pertino, but the Pertino product we spoke of was designed and produced to be a fundamentally different product that how you are trying to use this. I would say that they can't even be considered the same product given the gaps in "intent".
-
@wrx7m said:
@scottalanmiller Well, with ssh it would not be so bad but in the world of gui, it is a pain because you are resizing windows and scrolling and waiting for screen refreshing, etc.
I don't have those issues. What kind of jump box is causing issues like that? I work from a jump box all day.
