All of that is fine, and they mentioned the management perspective, which I get. It was a field test and our original choice of 4001 - which is what other serial to TCP servers like us use, also in their network - was unavailable.
What irks me is the “technical impossibility” of raw TCP and “I must be wrong” when filling out their firewall change form.
They’ve since given us a different port “close to others that we use”, for whatever reason that matters, and based their choice on some list of common protocols outside the reserved range. But not 4001.
That by itself is just one thing and I wouldn’t give it a second thought, but it’s all part of a larger picture of ineptitude. They opened a ticket because an arrow at the border of our UI vanished when they screen shared on Teams. Because of the red border. And they blamed our application for it.
They didn’t set up their PKI correctly and opening our webpage on specific hosts gave the typical “go back” warning. But it was our fault somehow, even though the certificate was the one they supplied us and it was valid.
What irks me is the “technical impossibility” of raw TCP and “I must be wrong” when filling out their firewall change form.
Most commonly a port is opened to accept traffic of a specific protocol that runs overtop of TCP of UDP. I’m guessing the individual that responded might not be very good at technical communication and was just trying to question “are you sure it’s raw TCP and not just http traffic?” In order to keep the holes poked into the firewall as narrow and specific as possible
They’ve since given us a different port “close to others that we use”, for whatever reason that matters, and based their choice on some list of common protocols outside the reserved range. But not 4001.
Usually if infrastructure is assigning a port other than default it’s because that port is already in use. The actual port number you use doesn’t matter as long as it’s not a common default (which basically all ports below 1024 are)
Using ports that are close together for similar purposes can aid in memorability if that’s a need, but ultimately it doesn’t matter much if they’re not conflicting with common defaults
They opened a ticket because an arrow at the border of our UI vanished when they screen shared on Teams. Because of the red border. And they blamed our application for it.
Probably a user was complaining and needed action immediately and they didn’t have time to test a cosmetic issue in an edgecase. For minor issues I’ll open a ticket with the party I think might be responsible just to get it out of the way so I can get to higher priority stuff, and I’ll rely on that party to let me know if it’s not actually their problem. Heck it might even simply be the IT person assumed it was a misrouted ticket, since users open tickets in random queues all the time
They didn’t set up their PKI correctly and opening our webpage on specific hosts gave the typical “go back” warning. But it was our fault somehow, even though the certificate was the one they supplied us and it was valid.
If the certificate is correctly generated and valid an SSL error would indicate it was incorrectly applied to the application. I’m guessing by the inclusion in this rant that the conclusion was it was in fact a problem with the certificate, but we don’t have enough details to speculate if it was truly a mistake by the individual that generated it or just a miscommunication
Honestly it sounds like you’re too quick to bash IT and should instead be more open to dialogue. I don’t know the specifics of your workplace and communications, but if you approach challenges with other teams from an “us vs them” standpoint it’s just going to create conflict. Sometimes the easiest way to do it is to try to hop on a quick call with the person once you get to more than a couple of emails back and forth, plus then you have more social cues to avoid getting angry with eachother and can give more relevant details
All of that is fine, and they mentioned the management perspective, which I get. It was a field test and our original choice of 4001 - which is what other serial to TCP servers like us use, also in their network - was unavailable.
What irks me is the “technical impossibility” of raw TCP and “I must be wrong” when filling out their firewall change form.
They’ve since given us a different port “close to others that we use”, for whatever reason that matters, and based their choice on some list of common protocols outside the reserved range. But not 4001.
That by itself is just one thing and I wouldn’t give it a second thought, but it’s all part of a larger picture of ineptitude. They opened a ticket because an arrow at the border of our UI vanished when they screen shared on Teams. Because of the red border. And they blamed our application for it.
They didn’t set up their PKI correctly and opening our webpage on specific hosts gave the typical “go back” warning. But it was our fault somehow, even though the certificate was the one they supplied us and it was valid.
Most commonly a port is opened to accept traffic of a specific protocol that runs overtop of TCP of UDP. I’m guessing the individual that responded might not be very good at technical communication and was just trying to question “are you sure it’s raw TCP and not just http traffic?” In order to keep the holes poked into the firewall as narrow and specific as possible
Usually if infrastructure is assigning a port other than default it’s because that port is already in use. The actual port number you use doesn’t matter as long as it’s not a common default (which basically all ports below 1024 are)
Using ports that are close together for similar purposes can aid in memorability if that’s a need, but ultimately it doesn’t matter much if they’re not conflicting with common defaults
Probably a user was complaining and needed action immediately and they didn’t have time to test a cosmetic issue in an edgecase. For minor issues I’ll open a ticket with the party I think might be responsible just to get it out of the way so I can get to higher priority stuff, and I’ll rely on that party to let me know if it’s not actually their problem. Heck it might even simply be the IT person assumed it was a misrouted ticket, since users open tickets in random queues all the time
If the certificate is correctly generated and valid an SSL error would indicate it was incorrectly applied to the application. I’m guessing by the inclusion in this rant that the conclusion was it was in fact a problem with the certificate, but we don’t have enough details to speculate if it was truly a mistake by the individual that generated it or just a miscommunication
Honestly it sounds like you’re too quick to bash IT and should instead be more open to dialogue. I don’t know the specifics of your workplace and communications, but if you approach challenges with other teams from an “us vs them” standpoint it’s just going to create conflict. Sometimes the easiest way to do it is to try to hop on a quick call with the person once you get to more than a couple of emails back and forth, plus then you have more social cues to avoid getting angry with eachother and can give more relevant details