Hey all,Long story short a vendor has a user in our network that goes out to a publicly accessible Citrix environment on their network, but it’s broken as hell, so they want to just ship us a Meraki VPN concentrate, have us put it behind our firewall, and then work on routing necessary traffic through it.
I have not done that before and while it seems pretty straight-forward we like to try to keep it really tight here due to the nature of our business (healthcare). Any concerns with this I should be aware of?
I’m trying to put my foot down and get them to just fix what they broke, since it was working at one point, but so far no such luck.
I’m personally not a fan of terminating tunnels on the trusted side of my firewall.
I would recommend putting the VPN concentrator one the outside of your firewall.
If you put on inside, then any controls such as IPS/IDS, DLP…etc that you normally use your firewalls for will not be able to perform that inspection due to the traffic being IPSEC encapsulated as it passes through the ACL and threat detection engine.
If the systems communicating are accessing, storing or transmitting electronic health information and your are not properly inspecting and logging those you MIGHT be teetering on a regulatory requirement and compliance problem.
I’d have to dig into HIPAA technical safe guards and see what’s required vs addressable.
Nevertheless, I wouldn’t put it on the inside.
Not sure the money to throw around where your at but there are some enterprise solutions to help you with “zero trust” third party access like Netskope and CyberArk Alero or even Securelink.
Traditional VPN is a semi dying thing for most cases outside of data transmission and some administrator required stuff.
Explore options and if you have any questions shout them out. Me or someone here will usually assist in some capacity.
This would be a hard no from me for a number of reasons, including that you are giving them a path back into your network and trusting them to not abuse it.
If it is for 1 system, a client on the system would be a more acceptable solution
Depends on your level of trust, if you trust it enough sure you can go ahead. If you’re still paranoid about it, you could also create a vlan, put the meraki behind that vlan. Now depending on what the user needs to do, i.e. You could use setup the meraki as the gateway for the user and static route to access the data vlan or put the user on the data vlan and static route via the meraki essentially an asymmetric network.
Then in your firewall you limit the meraki from accessing your vlan
*snigger* not a VPN concentrator, they want to deploy a Meraki MX with “SD-WAN” enabled to connect back to their network.
In short, if deployed correctly (in a dmz, and only that users traffic allowed in, and zero traffic from the device allowed to anything else) medium/low risk if you are tight as heck.
Oh, also as it’s Meraki, read up on the pitfalls of the suggested model and software version;
Also f**k you cisco, i will stop crapping on your product when you stop trying to protect your “firepower” revenue by not improving your “game changer” product.
Meraki WiFI = Great (for some/many implementations)
Meraki LAN = Ok
Meraki FW = utter crap
Meraki VoIP / CCTV = really… why bother, you have your crappy FW to fix, chop chop peeps!
What Firewall are you currently using? I dont know of any that dont natively support a VPN connection. I’m failing to see why you need an additional appliance for this task.
Getting them to fix their busted Citrix environment is ideal, but that may get you nowhere and you are at a standoff of “fix your shit or this user can’t work” and I’m thinking that will lead to some headache for you when they complain to a higher up on your end.
I personally wouldn’t have a problem taking on the Meraki and putting it behind my network. I would do the following:
Create dedicated VLAN for this use case and restrict it to only be able to get to the internet (basically another “guest” network like you would have for WiFi, but specific to this purpose)
Plug WAN port of Meraki into a port assigned to above VLAN
Plug vendor’s users into a LAN port of Meraki
(Optional) - Require that WiFi is turned off on the Meraki (applicable to Z or “W” model MX firewalls) and if you find it’s turned on at some point, pull the power plug on the device and have a discussion with the vendor
There’s no doubt in my mind the vendor is using Meraki MX on their side, so the device on your network will make an outbound request to Meraki’s Cloud Controller for AutoVPN tunnel to be established, and then state firewall takes over from there for the inbound traffic They won’t care what IP you assign to the VLAN you create for this, or that it’s double-NAT as the Meraki AutoVPN won’t care. No inbound ports will need to be opened on your firewall. You will need appropriate outbound ports open (should you do an outbound deny all by default) so the Meraki device can talk out to the cloud controller.
All that being said, I don’t see any reason you can’t put the Meraki WAN side in your DMZ and patch the user into Meraki LAN side. The vendor doesn’t care when it comes down to it, as long as the Meraki has a way to get out to the Internet.
I’m obviously assuming the user doesn’t need any resources on YOUR LAN side.
Before doing this, be sure to check with your InfoSec group. The last thing you want to do is try to solve a technical problem and then end up with PCI, HIPAA, etc issues.
So it’s one thing to set up a VPN connection for vendors in general because it may be useful (as tight as possible, obviously), but…
If it’s actually to fix a broken mess, the fastest way is to simply arrange a Zoom/Skype/… meeting, so you log in to the devices and don’t even have a password (not even IP reachability for that matter) to do anything. This means you can be absolutely sure that they will never again access your devices, but there’s a catch. The catch is, Zoom/Skype/… may record the video and thus gain info about your configuration (although not your passwords).
If that’s a concern, do what they say, set up this VPN, set up a specific password for that vendor and the specific days (eg VENDOR_2020_MM_DD), try as much as possible to ask your vendor to give you only one IP (alternatively, a tight network range), log everything via syslog.
Put it on it’s own subnet. You pretty much have to, or else you’d be routing across the broadcast domain (assuming you just have a flat setup now). That also lets you control traffic inbound and out from the device. Your call on how tight you want that to be, sounds like you could get away with just blocking access from their network into yours and call it a day, unless you have concerns about data leakage back through their tunnel by your users.
No big deal and vastly referable to swiss cheesing your firewall in other ways.
I am setting up something similar. Meraki has their SDWAN set up this way. It is a one armed concentrator. Traffic is coming out the same link as it went in. All traffic entering the network through the firewall is actually decrypted before going into the local network.
If it’s only facilitating site-to-site tunnels to other corporate sites, why connect it to the firewall at all? Why not just connect it directly to the outside zone and put up an ACL that blocks all non-IPsec traffic?
Only if your doing IPsec. They’re probably not going to. They probably want Meraki’s AutoVPN.
Meraki uses a UDP wrapper on its IPsec tunnel. They use UDP hole punching combined with a cloud registry to build tunnels. Automatic NAT Traversal for AutoVPN Peers
Also, as a cloud managed product it will need outbound ports opened to the Meraki cloud controller these aren’t optional.
If you want to lock down incoming ports you only need to allow one inbound and then you can configure which port you want it to be.
Feel free to DM me if you need technical specs and better details.
*snigger* not a VPN concentrator, they want to deploy a Meraki MX with “SD-WAN” enabled to connect back to their network.
This is a new territory to me, so I trust you on that because you speak with snickering (assuming thats what you meant…) confidence.
In short, if deployed correctly (in a dmz, and only that users traffic allowed in, and zero traffic from the device allowed to anything else) medium/low risk if you are tight as heck.
That’s the plan. Meraki behind my ASA, Meraki routes to the host, host on the DMZ, drilled down to 1 UDP port.
Oh, also as it’s Meraki, read up on the pitfalls of the suggested model and software version;
I would think this is on them to handle, and if handled poorly, I am still secured by my ASAs ACLs???