|
Well the ISE upgrade went as smooth as you can ask for. Got delayed a couple times because I started the install and after 10-15 minutes it would give me an error, had to set my primary to standalone since I wasn’t upgrading any of the other nodes. Then when it rebooted, gave it 30 minutes like it said, no reply to ping and wasn’t coming back so I asked a VM person to check the console. Sends me a screenshot that was a boot menu for ISE 2.4 and I nearly poo poo lol. I realized that they must still have the image mounted from the original install and it booted to that, so he needed to press enter to get it to continue. Then all I needed to do was register my secondary and policy nodes, join them to the domain and we are all good. No serious problems and only upgrading one node but it took about 4h 50 minutes lol. Glad to be done with it tho.
|
#
?
Jan 20, 2024 08:06
|
|
|
|
| # ? Apr 24, 2024 15:52 |
|
|
I'm currently taking Cisco II, after being beaten down by the initial class. Are you supposed to like, memorize and just shoot out every single text command for what does what when messing with Cisco routers and switches bcz I see no way I can recollect all of that without an enormous cheat sheet.
|
|
#
?
Jan 25, 2024 19:35
|
|
|
Yes but also you get a mental model for the config structure and can basically just "?" your way to what you want eventually if you're CLI cowboying. Or just look it up and/or automate the config.
doomisland fucked around with this message at 19:58 on Jan 25, 2024 |
|
#
?
Jan 25, 2024 19:56
|
|
|
doomisland posted:Yes but also you get a mental model for the config structure and can basically just "?" your way to what you want eventually if you're CLI cowboying. Or just look it up and/or automate the config.
|
|
#
?
Jan 25, 2024 22:34
|
|
|
wolrah posted:It's amazing how logical and explorable the Cisco CLI layout is until it suddenly does something backwards from all reasonable expectations like enabling a port via `no shutdown` or of course everyone's favorite learning experience `switchport trunk allowed vlan add` Logical? Junos > IOS
|
|
#
?
Jan 26, 2024 03:38
|
|
|
Moey posted:Logical? Junos > IOS
|
|
#
?
Jan 26, 2024 17:14
|
|
|
wolrah posted:It's amazing how logical and explorable the Cisco CLI layout is until it suddenly does something backwards from all reasonable expectations like enabling a port via `no shutdown` or of course everyone's favorite learning experience `switchport trunk allowed vlan add` As noted ios isn't logical at all, it's 30 years of them mashing more commands in while not breaking compatibility. It's sad that most other vendors cloned it. Not Junos of course which is actual legit 95% logical. Give it a try on some virtual thing sometime.
|
|
#
?
Jan 27, 2024 17:25
|
|
|
Fortinet gear is also pretty good overall. IOS is fine because I know it, which basically means I know 50% of other vendors CLi, and yeah it's not intuitive at all
|
|
#
?
Jan 28, 2024 06:32
|
|
|
Junos is harder to learn but it's so well designed that it makes the time spent worth it. IOS is what happens when you make your system so backwards compatible you can punch commands from the original AGS manual into a modern router and almost all of them will work just fine.
|
|
#
?
Jan 28, 2024 06:39
|
|
|
Fortigate CLI tab completion doesn't automatically insert a space after you use it, which is the single most annoying feature.
|
|
#
?
Jan 28, 2024 10:27
|
|
|
Thanks Ants posted:Fortigate CLI tab completion doesn't automatically insert a space after you use it, which is the single most annoying feature. The fact that its tab completion toggles through all valid options is really bad. This is one thing IOS does better. Also arbitrary numbers for things - wtf. Makes it really hard to have config templates and make bulk changes since everything is an arbitrary number. Sorry last complaint, locking down management interface to source IPs is so stupid - you can't just define an ACL, it's based on each user. so if you lock down users to specific source ranges, something internal blocks https/ssh/etc from everything else. But if someone adds a user, it defaults to 0/0, and is then open to the world again.
|
|
#
?
Jan 28, 2024 22:01
|
|
|
Local in policies aren't per-user are they? Or is that not what you mean?
|
|
#
?
Jan 28, 2024 22:07
|
|
|
Thanks Ants posted:Local in policies aren't per-user are they? Or is that not what you mean? quote:Setting trusted hosts for all of your administrators increases the security of your network by further restricting administrative permissions. In addition to knowing the password, an administrator must connect only through the subnet or subnets you specify. You can even restrict an administrator to a single IP address if you define only one trusted host IP address with a netmask of 255.255.255.255. https://help.fortinet.com/fmgr/50hlp/56/5-6-1/FMG-FAZ/0900_Administrators/0005_Trusted%20Hosts.htm Basically there should be a setting to permit which source IP's can get to management interfaces that's not associated with user accounts, just 'listen on mgmt iface from x/y/z'. Maybe there's a better way to do this now but our folks didn't seem to find one.
|
|
#
?
Jan 28, 2024 22:31
|
|
|
Ah, FortiManager vs. FortiGate
|
|
#
?
Jan 28, 2024 22:33
|
|
|
Thanks Ants posted:Ah, FortiManager vs. FortiGate It's fortigate (firewall) 600e/1000d/etc.
|
|
#
?
Jan 28, 2024 22:34
|
|
|
falz posted:It's fortigate (firewall) 600e/1000d/etc. You quoted from the FMG/FAZ manual not FGT.
|
|
#
?
Jan 28, 2024 22:47
|
|
|
Thanks Ants posted:Ah, FortiManager vs. FortiGate It's the same for the fortigate's as well from what I remember, I can tell you in about a week when I need to configure our new ones.
|
|
#
?
Jan 30, 2024 00:16
|
|
|
Yeah that was just the first google hit that had the infoz. Since there's fortigate chat here - I think the answer is NO but.. scenario is a Web Server is behind a Fortigate as a DMZ (both public IPs) On the web servers config we whitelist certain hosts, block others. But we put a nice 403 message up saying 'you're coming from the wrong ip' (our customers ips) Ideally I'd move this functionality to a firewall in front of the server - can a Fortigate do some sort of FW policy that only permits certain sources, but for others it displays HTTP error message itsself (not passing those requests to the web server?) Seems like a stretch for this, but pretty sure PA can do it?
|
|
#
?
Feb 2, 2024 15:55
|
|
|
falz posted:Yeah that was just the first google hit that had the infoz. I think you can do that with an app policy, but I've never had cause to do it, I'd talk to Fortinet support if I were you.
|
|
#
?
Feb 2, 2024 18:02
|
|
|
Last post on this here. So I work for a hospital primarily and then also do "IT Work" for a small clinic near the hospital off hours. "IT Work" meaning making sure their servers are updated and replaced, keeping their network up to date and somewhat secure, etc. However I've got a request now that is out of my wheelhouse and I want to make sure I'm doing it correctly, if it can even be done. The request is one of our scheduling teams wants access to the clinic's Allscripts systems to check on referrals and whatnot. The allscripts instance is hosted in-house and there's no direct external connection to the server or clients. The clinic is behind a Fortinet FGT-60F. The client they're looking for is housed on a windows virtual desktop via a link. What the physicians currently do to access this remotely is to log into the VPN, RDP to the VM desktop via IP, and open the client that way. I spoke to my NetSec super, and he suggested for our needs to have an SSL connection that they can open via a link on one of our desktop pools that would connect and open the client automatically. I've dug around in the firewall and see the settings, but I want to ensure that when they connect, they get to the specific desktop and not another one. It also looks like we'll need a certificate, of which we don't have, so I'm not sure if a self-signed certificate will work for this or if we're going to have to buy a trusted Cert and install. I'm probably missing vital information to get this to work correctly, help would be greatly appreciated. At this point I'm probably going to have to hire out to get this set up at least somewhat properly.
|
|
#
?
Mar 28, 2024 13:49
|
|
|
Gothmog1065 posted:Last post on this here. Could you elaborate on the bolded section? I'm not entirely sure what is being suggested there. Unless you want to setup a permanent IPsec tunnel between you environment and the clients the best-practice solution will be FortiClient SSL-VPN from your environment to the FGT-60F and then RDP in (I hope that is what you meant by VPN and you're not doing PPTP/L2TP). I suspect what your colleague is suggesting is something like Citrix where individual applications can be published which is an entirely different technology altogether.
|
|
#
?
Mar 28, 2024 15:14
|
|
|
Pile Of Garbage posted:Could you elaborate on the bolded section? I'm not entirely sure what is being suggested there. This is definitely out of my scope of experience, and I'm pretty sure what he's wanting isn't going to be (easily and/or cheaply) possible. Hospital has a pretty robust system in place with firewalls and security. I do not have access to the networking side as that is not my job and we're pretty heavily silo'd. We use VMWare (instead of Citrix), which is where access is going to originate. Creating a VPN (IPSec) is impractical and quite frankly gives too much access. Clinic is a much smaller clinic where we have a physical server for the Allscripts database. This clinic has never had a properly set up network, and just now I was able to get them on completely updated networking equipment. The way the inhouse people access the software now is primarily though a RDS setup (finally got them to upgrade from terminal services after their previous server died). There are a few fat client scattered around, but those are because of card readers and whatnot, and nobody wanted to deal with making them use the desktop pool. This clinic doesn't want to spend a lot of money because they just dropped a ton of money in the past two years on IT (which lol -- I told them that server was gonna crap itself) two years ago, and this year they dropped a ton of money on a new phone system for their 25 year old phone system (that lol the phone system operator told them they wouldn't be able to fix it if it failed). The clinic manager is terrible about putting things off until they're broke, and while I do get some leeway, they still balk when it comes to spending money to prevent issues. The request is that a group of people want access to a read-only view of Allscripts from hospital to clinic. Parts of this are kind of in place (the desktop pool, etc), but there is no other access other than a VPN connection (again, IPSec tunnel CURRENTLY only for physicians, Clinic manager and myself), RDP to the desktop and access the client. The NetSec manager is the one that mentioned the SSL VPN tunnel (probably so he doesn't have to do poo poo on his side), which is where we're at. My networking knowledge is pretty firmly in the basic camp, and much of this is still a mystery and well out of my wheelhouse. I just want to make sure I'm not missing something that someone who does this every day would find obvious that I wouldn't see at all. The other two clinics (who are much larger than the one I'm doing work for) have web-based access to their server, and I'm not sure if our Allscripts server can handle that as well (which WOULD simplify things, but I doubt it as it's something that probably needs to be paid for).
|
|
#
?
Mar 28, 2024 17:35
|
|
|
Gothmog1065 posted:The request is that a group of people want access to a read-only view of Allscripts from hospital to clinic. Parts of this are kind of in place (the desktop pool, etc), but there is no other access other than a VPN connection (again, IPSec tunnel CURRENTLY only for physicians, Clinic manager and myself), RDP to the desktop and access the client. That sounds like permission delegation within the Allscripts application itself which is dependent on the configured identity provider and RBAC architecture, none of which can be interrogated or altered by a FGT-60F (At least not in any way that would be secure). To keep things both secure and supportable you should just keep it simple: FortiClient SSL-VPN (Tunnel mode only and with MFA, Duo Auth Proxy is a common way of doing that) into the environment, then RDP to a common RDS host where users then access the Allscripts application. Ideally users would have their own login to the Allscripts application which then grants them permissions based on assigned roles or whatnot (A quick Google turned up the following which implies that read-only accounts can be created for users: https://wiki.galenhealthcare.com/index.php/Creating_a_Read_Only_Account_in_Allscripts_Enterprise_EHR). Gothmog1065 posted:The NetSec manager is the one that mentioned the SSL VPN tunnel (probably so he doesn't have to do poo poo on his side), which is where we're at. My networking knowledge is pretty firmly in the basic camp, and much of this is still a mystery and well out of my wheelhouse. I just want to make sure I'm not missing something that someone who does this every day would find obvious that I wouldn't see at all. Network access for SSL-VPN users can be controlled in a granular fashion with user groups on a FortiGate but that only really covers you for Layer 3/4/7 network connectivity (e.g. users in "Group-A" can only connect to "RDS-Host-A", users in "Group-B" can only connect to "RDS-Host-B"). There's no mechanism where the FortiGate can inform an application of the connecting user's role-assignment or permission delegation, that has to be handled entirely within the application itself (And for something like this that is where it should be controlled). One more note, I'd recommend keeping the core principle of Zero Trust Network Access (ZTNA) in mind at all times: never trust, always verify.
|
|
#
?
Mar 28, 2024 18:19
|
|
|
Pile Of Garbage posted:That sounds like permission delegation within the Allscripts application itself which is dependent on the configured identity provider and RBAC architecture, none of which can be interrogated or altered by a FGT-60F (At least not in any way that would be secure). Correct, and Allscripts has it's own userbase outside of LDAP (Namely because LDAP didn't really exist outside of shared logins before I got there). So we'd have to A> get tunneled to the system, so they could B> log into Allscripts. quote:Network access for SSL-VPN users can be controlled in a granular fashion with user groups on a FortiGate but that only really covers you for Layer 3/4/7 network connectivity (e.g. users in "Group-A" can only connect to "RDS-Host-A", users in "Group-B" can only connect to "RDS-Host-B"). There's no mechanism where the FortiGate can inform an application of the connecting user's role-assignment or permission delegation, that has to be handled entirely within the application itself (And for something like this that is where it should be controlled). This would actually be functional and fit with what we're doing. All external access from x IPs would only be able to access x internal IP. "Group A" would be these users. "Group B" would still have the IPSec tunnel for full access. I guess the next question is where my ignorance really shows. What would be the medium for the tunnel itself? I know for our IPSec tunnels, we have to install the Fortinet VPN Client (not the full client since we don't use any of the other features), the hospital uses Cisco AnyConnect, which has to be activated and logged in to for RDP, etc to work. It's not an active site to site vpn or anything like that. The request would basically be the ability to click a desktop icon on the hospital side that would open the vpn, which would bring up the remote desktop, which would allow them to complete the request.
|
|
#
?
Mar 28, 2024 19:12
|
|
|
It's probably not enterprise enough or too janky but for lab access I use Apache Guacamole to sit in between the RDP hosts and the clients which provides a seperate auth mechanism so your end users aren't directly logging in with RDP credentials, and use users/groups to control what RDP hosts they have access to. Guacamole will use internally known credentials to automatically log into the chosen RDP host. This runs in a browser, so you still need a the FortiVPN client to connect via the Fortigate (IPSEC/SSL mode doesn't really matter much), and then fire wall down access to only the Guacamole web interface. I guess the other benefit is they can have a browser bookmark to gain access once they're on the VPN and you could stick Guacamole in some kind of DMZ to further limit access where it can only hit the RDP hosts via the Forti firewall as well. Downside is you need a server to run Guac on. It's kind of a poor man's half assed secure remote access setup.
|
|
#
?
Mar 29, 2024 03:02
|
|
|
Aware posted:This runs in a browser, so you still need a the FortiVPN client to connect via the Fortigate (IPSEC/SSL mode doesn't really matter much), and then fire wall down access to only the Guacamole web interface. This is the ultimate issue I believe that all of this is currently boiling down to: There's not an easy way bypass the need for the FortiVPN client.
|
|
#
?
Mar 29, 2024 04:43
|
|
|
Comedy answer: just expose guacamole to the internet. It's a rabbit whole you can go down into reverse proxies, SSL certs and some kind of SSO but I'd say a dialup client is still the simplest method. I think FortiWeb or whatever it's called does all this if you wanted to stick to a vendor solution.
|
|
#
?
Mar 29, 2024 05:42
|
|
|
Gothmog1065 posted:I guess the next question is where my ignorance really shows. What would be the medium for the tunnel itself? I know for our IPSec tunnels, we have to install the Fortinet VPN Client (not the full client since we don't use any of the other features), the hospital uses Cisco AnyConnect, which has to be activated and logged in to for RDP, etc to work. It's not an active site to site vpn or anything like that. Are you using the FortiClient VPN in IPsec mode? Normally it's just used in SSL-VPN mode. SSL-VPN mode establishes a Layer 7 tunnel using DTLS for transport. IPsec mode establishes a Layer 3 tunnel using ESP and IKE. SSL-VPN mode is far more common as it's simpler to setup and just uses TCP, usually on port 443, which most environments allow. IPsec mode is less common as it needs extra configuration on both sides and uses uncommon protocols (ESP is IP protocol 50, IKE is UDP on port 500) which are often blocked. Either way for an end-user they should function the same. Also given this use-case split-tunnel should definitely be enabled so that only traffic destined for the RDS host is sent over the tunnel. Gothmog1065 posted:The request would basically be the ability to click a desktop icon on the hospital side that would open the vpn, which would bring up the remote desktop, which would allow them to complete the request. The only way I can see this working is with a custom script/automation which when run performs the following:
This script/automation can just be put on the desktop so users can run it like any other program. In addition to the script/automation you'll need to configure the Start a program on connection setting via Group Policy on the RDS host so that when the user connects it fires up the Allscripts client.
|
|
#
?
Mar 29, 2024 12:08
|
|
|
I've got a tiny office(3 people) that someone else put in a lot of Cisco equipment. Switch, security gateway, 7 cameras. They weren't really made aware that this was all a subscription deal as far as the licensing goes, and now they are looking to cut costs. They have 5 mr enterprise licenses(these seem generic, not sure what device they represent), 1 mx68w(security gateway), 1 ms120-48lp(switch), and 7mv(camera) licenses I'd love to tell them to drop all of this for a 3 person office, but I'd like to have at least a modicum of understanding on how meraki licensing works in case some of these licenses still have time left on them and they want to put off changing everything at once. Are the camera's still fully functional if you swap the security gateway and 48p switch(assuming poe compatibility) with another brand or does cisco's cloud access require the gateway? What exactly are mr enterprise licenses? I assumed they represented number of employees with portal access but google mentions devices.
|
|
#
?
Apr 11, 2024 21:05
|
|
|
MR enterprise licenses are per-access point, so you should have as many of them as you have APs. Though it sounds like you don't have any APs so I'm not sure what they are doing there, are you sure they aren't MT licenses which every tenant has five of to try and get people to use Meraki sensors? The cameras don't have a dependency on the MX gateway or MS switches.
|
|
#
?
Apr 11, 2024 21:26
|
|
|
MR is access points in Meraki terms. You’ll have more luck searching on Meraki than Cisco, since that’s what you have. For licensing, they have two models - co-term and per device. Per device is more popular now, but they still offer co-term. You’ll want to see which model of licensing you’re on, then you can decide from there. In the Dashboard, check Organization (Left side) -> Configure -> License Information It does sound like overkill for literally 3 people, but of course we don’t know what your actual costs are. Licenses are 1-1 with Meraki, you need a license for each device you have.
|
|
#
?
Apr 11, 2024 21:30
|
|
|
You’ll want to read this. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Licensing Both rhinonetworks and hummingbird networks are good sources for meraki license purchases when you don’t have an account rep with publicly listed prices. Also I hope you have access to the account. If you don’t; Cisco won’t help you and you can’t claim the device without the existing holder releasing them. (Ask me about the $30k worth of Meraki gear under my desk that I have no idea do “manages”). Rough estimate is around $100/year per AP, switch varies but around $120 for that one, and $180 for the cameras each. Most of the expenses for these come from the purchase price. The router is the opposite and most of the costs come from licenses on the smaller models. You’ll want at least the advanced security licenses (not the enterprise) and that’s going to be $400-$600/yr based off commitment. That looks like a lot, but it’s pretty close to what a fortigate with similar licensing and online management will run you. Cyks fucked around with this message at 01:55 on Apr 12, 2024 |
|
#
?
Apr 11, 2024 23:53
|
|
|
Also don’t buy annual licenses as the multi year terms are massively better value. Here a 5-year license on a basic 48 port PoE switch is about £350, 3-year license for an AP is around £170.
|
|
#
?
Apr 12, 2024 00:39
|
|
|
Thanks guys. Just to confirm, if they rip out everything but those 7 cameras, they can just pay for the license on those 7 cameras and will still have full access to those cameras like nothing has changed?
|
|
#
?
Apr 12, 2024 00:56
|
|
|
bobua posted:Thanks guys. Yes. It's all licensed through the Meraki dashboard. The benefit of keeping it all is the whole single pain of glass bit. Easy to update all your poo poo from one interface.
|
|
#
?
Apr 12, 2024 01:47
|
|
|
|
| # ? Apr 24, 2024 15:52 |
|
|
If you know you are only keeping the cameras then move the tenant to per-device licensing as soon as you can so that expired stuff that you leave in there by mistake doesn't shut the whole thing out
|
|
#
?
Apr 12, 2024 16:45
|
|