I think I've mentioned this before but are our shop we have the more senior guys cover the tier 1/ticket system for one morning or afternoon a week to give the entry level guy a break to work on other stuff uninterrupted. I don't mind it, it's only a few hours a week and we average like 4 tier 1 tickets a day so it's generally not a big deal.
My shift is this morning. there have been 10 tickets in 3 hours. I want to die.
Disclaimer: I'm shite when it comes to network hardware
I'm working with an HP Aruba J9774A and trying to figure out how to enroll it in 8021x. I know how to do the actual enrolling part but figuring out the best method here is causing me to scratch my head. This application seems to be a little too specific for the googling.
The goal is to create an authorized switch in a small engineering lab that the user can connect an authorized PC to for domain network access, while also being able to communicate with unauthorized embedded linux devices on the local switch.
I just found out the solution that has been put in place is to just force auth the port... so basically rendering 8021x pointless because all a user needs to do is unhook the switch and connect a PED. I do not like this.
Any of y'all running HP Network switches and know if this is possible? The other option is I just set them up with a secondary nic and give them their 30 dollar netgear switch back. I don't like this either because then there is a rogue switch running around and some chuckle head might put us in a routing loop again.
Disclaimer: I'm shite when it comes to network hardware
I'm working with an HP Aruba J9774A and trying to figure out how to enroll it in 8021x. I know how to do the actual enrolling part but figuring out the best method here is causing me to scratch my head. This application seems to be a little too specific for the googling.
The goal is to create an authorized switch in a small engineering lab that the user can connect an authorized PC to for domain network access, while also being able to communicate with unauthorized embedded linux devices on the local switch.
I just found out the solution that has been put in place is to just force auth the port... so basically rendering 8021x pointless because all a user needs to do is unhook the switch and connect a PED. I do not like this.
Any of y'all running HP Network switches and know if this is possible? The other option is I just set them up with a secondary nic and give them their 30 dollar netgear switch back. I don't like this either because then there is a rogue switch running around and some chuckle head might put us in a routing loop again.
You set up your access ports as an 802.1x authenticator on one VLAN and also configure the second, unauthorized VLAN for 802.1x. Devices that successfully authenticate get put on the first VLAN, the linux devices that can't authenticate stay on the second VLAN.
The trunk port used as an uplink to the upstream network needs to be configured as an 802.1x supplicant so the switch can authenticate itself to the upstream switch. This would prevent someone swapping out the entire lab switch to gain unauthorized access.
Then you'd need to configure a route between the authenticated VLAN and the unauthorized VLAN to allow the PC's to talk to the linux devices. Put traffic ACL's in place to prevent the unauthorized devices from sending traffic anywhere you don't want it.
Just remember that half the people you meet are below average intelligence.
Stay the hell away from anything from GoAnywhere software. Download one free program and I've been spammed with email and calls for the past two months.
Because if you're going to attempt to squeeze that big black monster into your slot you will need to be able to take at least 12 inches or else you're going to have a bad time...
Disclaimer: I'm shite when it comes to network hardware
I'm working with an HP Aruba J9774A and trying to figure out how to enroll it in 8021x. I know how to do the actual enrolling part but figuring out the best method here is causing me to scratch my head. This application seems to be a little too specific for the googling.
The goal is to create an authorized switch in a small engineering lab that the user can connect an authorized PC to for domain network access, while also being able to communicate with unauthorized embedded linux devices on the local switch.
I just found out the solution that has been put in place is to just force auth the port... so basically rendering 8021x pointless because all a user needs to do is unhook the switch and connect a PED. I do not like this.
Any of y'all running HP Network switches and know if this is possible? The other option is I just set them up with a secondary nic and give them their 30 dollar netgear switch back. I don't like this either because then there is a rogue switch running around and some chuckle head might put us in a routing loop again.
You set up your access ports as an 802.1x authenticator on one VLAN and also configure the second, unauthorized VLAN for 802.1x. Devices that successfully authenticate get put on the first VLAN, the linux devices that can't authenticate stay on the second VLAN.
The trunk port used as an uplink to the upstream network needs to be configured as an 802.1x supplicant so the switch can authenticate itself to the upstream switch. This would prevent someone swapping out the entire lab switch to gain unauthorized access.
Then you'd need to configure a route between the authenticated VLAN and the unauthorized VLAN to allow the PC's to talk to the linux devices. Put traffic ACL's in place to prevent the unauthorized devices from sending traffic anywhere you don't want it.
I really appreciate your response, I'll be trying to convince my network admin we need to revisit this and try again. he uh... doesn't like when I suggest he may have done something incorrectly.
Someone posted this in our internal Yammer...and some people actually came out and said they disagree with this. I can't even imagine that thought process.
Someone posted this in our internal Yammer...and some people actually came out and said they disagree with this. I can't even imagine that thought process.
It was a honey pot to see who you were kicking off Yammer, right?
Mostly just huntin' monsters.
XBL:Phenyhelm - 3DS:Phenyhelm
We have a server that manages the cameras for our building and when we got the DNS server installed, we organized the cabling better in that room and rearranged things. Which of course meant that we had to unplug stuff and when we plugged it back in, the camera server didn't have internet access. Network access yes, but no internet. Made a static IP in the DHCP server and all that, checked the IP settings of the device, all seemed good. Oh well, cameras are working, so I left it alone. Then a week or two later I was told it needed to have internet access by the guy that runs the cameras, and he had no idea how it had been setup previously. Turns out the machine had two NICs for some reason and we had both ethernets plugged in, which was apparently supposed to happen.
So I swapped the ethernet cords and oh hey look at that it works now. Sometimes my job feels silly.
Being a vendor now rather than operations means that 80% of my life is now diagnosing that the issue is decidedly not my product but something their ops team has messed up. It's actually a really frustrating thing, because I still do most of the heavy lifting of analysis, and then never get to fix it since it's inevitably something else.
Being a vendor now rather than operations means that 80% of my life is now diagnosing that the issue is decidedly not my product but something their ops team has messed up. It's actually a really frustrating thing, because I still do most of the heavy lifting of analysis, and then never get to fix it since it's inevitably something else.
Living the dream!
Mostly just huntin' monsters.
XBL:Phenyhelm - 3DS:Phenyhelm
Being a vendor now rather than operations means that 80% of my life is now diagnosing that the issue is decidedly not my product but something their ops team has messed up. It's actually a really frustrating thing, because I still do most of the heavy lifting of analysis, and then never get to fix it since it's inevitably something else.
Just had my first taste of that a bit yesterday. Its usually pretty easy to determine its not my area and send the customer off, but I had someone asking how to get our tool to work with Cisco ISE, so I have to churn on that next week. I'll likely write an integration guide for the rest of the team to reference or other customers.
Disclaimer: I'm shite when it comes to network hardware
I'm working with an HP Aruba J9774A and trying to figure out how to enroll it in 8021x. I know how to do the actual enrolling part but figuring out the best method here is causing me to scratch my head. This application seems to be a little too specific for the googling.
The goal is to create an authorized switch in a small engineering lab that the user can connect an authorized PC to for domain network access, while also being able to communicate with unauthorized embedded linux devices on the local switch.
I just found out the solution that has been put in place is to just force auth the port... so basically rendering 8021x pointless because all a user needs to do is unhook the switch and connect a PED. I do not like this.
Any of y'all running HP Network switches and know if this is possible? The other option is I just set them up with a secondary nic and give them their 30 dollar netgear switch back. I don't like this either because then there is a rogue switch running around and some chuckle head might put us in a routing loop again.
You set up your access ports as an 802.1x authenticator on one VLAN and also configure the second, unauthorized VLAN for 802.1x. Devices that successfully authenticate get put on the first VLAN, the linux devices that can't authenticate stay on the second VLAN.
The trunk port used as an uplink to the upstream network needs to be configured as an 802.1x supplicant so the switch can authenticate itself to the upstream switch. This would prevent someone swapping out the entire lab switch to gain unauthorized access.
Then you'd need to configure a route between the authenticated VLAN and the unauthorized VLAN to allow the PC's to talk to the linux devices. Put traffic ACL's in place to prevent the unauthorized devices from sending traffic anywhere you don't want it.
I really appreciate your response, I'll be trying to convince my network admin we need to revisit this and try again. he uh... doesn't like when I suggest he may have done something incorrectly.
For those who would like an update on this issue, I framed it as, "Hey, this is what the lab would look like, from everything I've read and the discussions I've had around this, this should work. If our current hardware just isn't able to support this because Vlaning, or something else I think we should investigate a hardware solution that does" My director and network administrators take on this request "It doesn't work that way" and "you don't know how it works".
Everytime I try to do anything with these Cisco Meraki MX's there's some kind of bullshit involved.
Using the API to export all the group policy l3 rules we have for an audit.
They have some prewritten scripts that will do that for the default l3 rules, but not the group policy rules.
Not a huge deal, I write my own.
Looking through the output, there's no source or source port for any of these rules. Double check the json file the API gives you, and yeah... They just left that info out.
At my normal Wednesday client and a guy comes and asks me if I got his message the other day. Tell him no, never saw one. Then it dawned on me that it was probably the phone call I ignored because it was 5:30pm and I am off the clock. One more reason to call our office and not my personal cell number.
Because if you're going to attempt to squeeze that big black monster into your slot you will need to be able to take at least 12 inches or else you're going to have a bad time...
Everytime I try to do anything with these Cisco Meraki MX's there's some kind of bullshit involved.
Using the API to export all the group policy l3 rules we have for an audit.
They have some prewritten scripts that will do that for the default l3 rules, but not the group policy rules.
Not a huge deal, I write my own.
Looking through the output, there's no source or source port for any of these rules. Double check the json file the API gives you, and yeah... They just left that info out.
What the fuck man
I like Meraki for setting up basic stuff but it gets tedious I find with content filtering. A client has full on filtering in place where they can only access sites on the whitelist and every few months I have to dick around with the Office 365 portal login for an hour because a URL somewhere changed.
Because if you're going to attempt to squeeze that big black monster into your slot you will need to be able to take at least 12 inches or else you're going to have a bad time...
I'm not sure what the use case for Meraki firewalls is, but it's gotta be razor thin.
The client VPN fails pci compliance, and there's nothing you can do about it.
The active directory integration requires ntlmv1.
You can't set up groups for sources, destinations, ports. On group policy l3 rules you can't even put multiple ports into a rule, so creating a group policy for a domain controller takes like 20 rules.
The site to site VPN firewall has a section for inbound rules. It doesn't do anything. In the documentation it says it doesn't do anything and will be removed at some point. The fuck is that about?
Still have to test more, but it seems like the whole sd-wan is torn down when one site to site tunnel goes down and has to be rebuilt.
If you type 'konami' into their suggestion box, it loads a god damn browser game.
At an old job my boss sent me to a day long course on Meraki stuff as we needed someone that knew something about them. At that time we had one or two clients with Meraki APs but no firewalls, switches, etc.
Got back to work the following day and was telling them about some of the features and how it could be useful having a firewall in place instead of just the APs and was met with, "ya, maybe, but we don't make any money off of the subscription renewals so there's no point".
Because if you're going to attempt to squeeze that big black monster into your slot you will need to be able to take at least 12 inches or else you're going to have a bad time...
Hey, if you need someone to wander in my server room and start messing with the fucking electrical box. OK, I guess. But maybe my UPS screaming at me when your guy flips the wrong breaker isn't the best way to notify me that this is happening.
I'm not sure what the use case for Meraki firewalls is, but it's gotta be razor thin.
The client VPN fails pci compliance, and there's nothing you can do about it.
The active directory integration requires ntlmv1.
You can't set up groups for sources, destinations, ports. On group policy l3 rules you can't even put multiple ports into a rule, so creating a group policy for a domain controller takes like 20 rules.
The site to site VPN firewall has a section for inbound rules. It doesn't do anything. In the documentation it says it doesn't do anything and will be removed at some point. The fuck is that about?
Still have to test more, but it seems like the whole sd-wan is torn down when one site to site tunnel goes down and has to be rebuilt.
If you type 'konami' into their suggestion box, it loads a god damn browser game.
They call their shit enterprise, it is not.
Their wireless APs are phenomenal. Their firewalls ("security appliances")... well, my experience isn't terribly different than yours.
The use case we've found for them is Internet-only guest wifi at branch offices. We don't use SD-WAN, we backhaul all of our production traffic back to HQ. But because we use Meraki APs, when we rolled out guest wifi, it made sense to drop in Meraki MXs and segregate off the guest Internet traffic on completely different connections. We don't give a shit about group policies or client VPNs. They're cheap simple firewalls that are easily manageable over the cloud.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
I had a friend who would send sms messages to people in this manner.
You'll note I said "had" because the entire township decided to murder him in the street for it.
I can't say this is something I care about, but I sympathize with the author because people who put in tickets or send me emails without details bother me in almost exactly the same way.
"I'm having trouble with my email."
What trouble? Is there an error message? Describe it. You're an adult, use your fucking words, don't make me drag it out of you.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Posts
XBL:Phenyhelm - 3DS:Phenyhelm
My shift is this morning. there have been 10 tickets in 3 hours. I want to die.
I'm working with an HP Aruba J9774A and trying to figure out how to enroll it in 8021x. I know how to do the actual enrolling part but figuring out the best method here is causing me to scratch my head. This application seems to be a little too specific for the googling.
The goal is to create an authorized switch in a small engineering lab that the user can connect an authorized PC to for domain network access, while also being able to communicate with unauthorized embedded linux devices on the local switch.
I just found out the solution that has been put in place is to just force auth the port... so basically rendering 8021x pointless because all a user needs to do is unhook the switch and connect a PED. I do not like this.
Any of y'all running HP Network switches and know if this is possible? The other option is I just set them up with a secondary nic and give them their 30 dollar netgear switch back. I don't like this either because then there is a rogue switch running around and some chuckle head might put us in a routing loop again.
You set up your access ports as an 802.1x authenticator on one VLAN and also configure the second, unauthorized VLAN for 802.1x. Devices that successfully authenticate get put on the first VLAN, the linux devices that can't authenticate stay on the second VLAN.
The trunk port used as an uplink to the upstream network needs to be configured as an 802.1x supplicant so the switch can authenticate itself to the upstream switch. This would prevent someone swapping out the entire lab switch to gain unauthorized access.
Then you'd need to configure a route between the authenticated VLAN and the unauthorized VLAN to allow the PC's to talk to the linux devices. Put traffic ACL's in place to prevent the unauthorized devices from sending traffic anywhere you don't want it.
I really appreciate your response, I'll be trying to convince my network admin we need to revisit this and try again. he uh... doesn't like when I suggest he may have done something incorrectly.
XBL:Phenyhelm - 3DS:Phenyhelm
I had a friend who would send sms messages to people in this manner.
You'll note I said "had" because the entire township decided to murder him in the street for it.
Someone posted this in our internal Yammer...and some people actually came out and said they disagree with this. I can't even imagine that thought process.
It was a honey pot to see who you were kicking off Yammer, right?
XBL:Phenyhelm - 3DS:Phenyhelm
Also, I'm extremely on board with someone having purchased a domain to have only that post shown.
Hi.
XBL:Phenyhelm - 3DS:Phenyhelm
So I swapped the ethernet cords and oh hey look at that it works now. Sometimes my job feels silly.
Living the dream!
XBL:Phenyhelm - 3DS:Phenyhelm
Just had my first taste of that a bit yesterday. Its usually pretty easy to determine its not my area and send the customer off, but I had someone asking how to get our tool to work with Cisco ISE, so I have to churn on that next week. I'll likely write an integration guide for the rest of the team to reference or other customers.
Hi!
For those who would like an update on this issue, I framed it as, "Hey, this is what the lab would look like, from everything I've read and the discussions I've had around this, this should work. If our current hardware just isn't able to support this because Vlaning, or something else I think we should investigate a hardware solution that does" My director and network administrators take on this request "It doesn't work that way" and "you don't know how it works".
Interview tomorrow with another company.
Using the API to export all the group policy l3 rules we have for an audit.
They have some prewritten scripts that will do that for the default l3 rules, but not the group policy rules.
Not a huge deal, I write my own.
Looking through the output, there's no source or source port for any of these rules. Double check the json file the API gives you, and yeah... They just left that info out.
What the fuck man
I like Meraki for setting up basic stuff but it gets tedious I find with content filtering. A client has full on filtering in place where they can only access sites on the whitelist and every few months I have to dick around with the Office 365 portal login for an hour because a URL somewhere changed.
The client VPN fails pci compliance, and there's nothing you can do about it.
The active directory integration requires ntlmv1.
You can't set up groups for sources, destinations, ports. On group policy l3 rules you can't even put multiple ports into a rule, so creating a group policy for a domain controller takes like 20 rules.
The site to site VPN firewall has a section for inbound rules. It doesn't do anything. In the documentation it says it doesn't do anything and will be removed at some point. The fuck is that about?
Still have to test more, but it seems like the whole sd-wan is torn down when one site to site tunnel goes down and has to be rebuilt.
If you type 'konami' into their suggestion box, it loads a god damn browser game.
They call their shit enterprise, it is not.
Got back to work the following day and was telling them about some of the features and how it could be useful having a firewall in place instead of just the APs and was met with, "ya, maybe, but we don't make any money off of the subscription renewals so there's no point".
Then why the fuck did I go do this course?!?!
Dell lifecycle controller still takes 10 minutes to load.
Ok, tell us what plug and cable we need.
Contractor: "ok, here you go"
Us: "well the plug has 4 pins but the wire has 3 conductors"
:rotate:
We have 4 days remaining to get the dehumidifier running.
Guess I do know what I'm talking about.
Go you!
XBL:Phenyhelm - 3DS:Phenyhelm
These next couple weeks are gonna be fun, I'm nervous but really excited.
Their wireless APs are phenomenal. Their firewalls ("security appliances")... well, my experience isn't terribly different than yours.
The use case we've found for them is Internet-only guest wifi at branch offices. We don't use SD-WAN, we backhaul all of our production traffic back to HQ. But because we use Meraki APs, when we rolled out guest wifi, it made sense to drop in Meraki MXs and segregate off the guest Internet traffic on completely different connections. We don't give a shit about group policies or client VPNs. They're cheap simple firewalls that are easily manageable over the cloud.
the "no true scotch man" fallacy.
I can't say this is something I care about, but I sympathize with the author because people who put in tickets or send me emails without details bother me in almost exactly the same way.
"I'm having trouble with my email."
What trouble? Is there an error message? Describe it. You're an adult, use your fucking words, don't make me drag it out of you.
the "no true scotch man" fallacy.