Pertino - Is Anyone Successfully Using Any Version Above 510 with DNS/AD Connect?
-
@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.
-
@Dashrender said:
@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?
As long as you have a print server, Windows and Linux all talk to each other.
-
@scottalanmiller I was using the term loosely to describe my windows 8.1 workstation in my office. Where I can connect to using screen connect.
-
@scottalanmiller I understand that things have changed with the cradlepoint acquisition but the release of the gateway was prior to that.
-
@scottalanmiller said:
@Dashrender said:
@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?
As long as you have a print server, Windows and Linux all talk to each other.
Right, the question is - for a home worker, can they setup a print server on their windows machine that Linux can print to? I know Windows Server can, I don't know about Windows Clients. Windows Server can make LPR printers, can say, Windows 10?
And if not, now that home worker would have to setup a Linux box on their home network that is also on the ZT network to act as a print server. More gear to maintain.
-
@scottalanmiller said:
@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.
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".
Also, the DNS bug is a problem that prevents me from using it. period.
-
@wrx7m said:
@scottalanmiller I understand that things have changed with the cradlepoint acquisition but the release of the gateway was prior to that.
When did the gateway come out? Those acquisitions are often years in the works, the release was likely related to the purchase. But regardless, internal changes led to the release. The product that we all described is a deploy everywhere solution without gateways as the Pertino founders and architects designed.
-
@wrx7m said:
@scottalanmiller said:
@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.
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".
Also, the DNS bug is a problem that prevents me from using it. period.
DNS bug? In ZT, Pertino or in the "use of" gateways?
-
The gateway, I assume, works fine and DNS works and they "work" as expected which means they do not work together in a transparent way.
-
@wrx7m said:
@scottalanmiller I understand that things have changed with the cradlepoint acquisition but the release of the gateway was prior to that.
That may be so - but the point is the sale people are selling you something that you want - even though it's not really how their product is meant to work. It's like Dell doing a DPACK and then selling you a SAN for one VM host. Will it work - it should.
