MerakiではUTMに相当するMXシリーズでURL Filteringの機能が利用できます。 ただ、Meraki全般がシンプルな機能になっているため、 もし複雑な制御をしたいのであれば、URL Filteringに特化したForward Proxyを検討した方が好ましい場合がございます。 > そうした場合、LAN側にはそのPCを直接、WAN側には社内ネットワークを接続することを想定しており、その場合ブリッジでIPアドレスは社内ネットワークのポリシーを守ったままにしたいと思っています。 言葉だとお互いにイメージが合致しているのか分かりにくそうに見えたので、 先にコメントがあるように簡単な構成のイメージなどがあった方がコメントしやすいと思います。 もしLAN側とWAN側がL2でスイッチング/ブリッジングして同一ネットワークになるイメージだと、 先のURL Filteringに対応したMXシリーズでは実現が出来ないと思います。 Routed ModeでMXがRouterのように動作するとセグメントが分かれるため、L3レベルでセグメントが分断されます。 (One-Armedの構成もありますが、それはVPN終端装置の用途に特化しているので意図的に深堀してないです。) またULR Filteringに対応しているMXは、Internet RouterのようなWANに直接つなぐ構成 (WAN & LAN)に向いていますが、 逆に、社内LAN同士 (LAN-to-LAN)をつなぐ「社内システム間の境界Firewall」のような用途には向いてないです。 仮に無理やりにやるとしても、Firewall PolicyにZoneの概念がないのでPolicy管理が煩雑になる点、 Routed ModeのLAN->WAN通信は常にNATされる点、Beta版でその送信元NATの無効化機能 (NAT Exceptions)があるものの、製品特性に向いていない点や、そもそもBeta版などがあるので。 ... View more

Thanks for your quick response! ... View more

アカウントのメール アドレスが分かれば、リセットを試せませんか。 Meraki Go - Reset Password - Cisco Meraki Documentation https://documentation.meraki.com/Go/How_To_Guides/Meraki_Go_-_Reset_Password もし社員の方のメール アドレス (例: suzuki)に紐付いているのであれば、 セキュリティ部門などに相談の上で、エイリアスを設定して受信できるようにする方法があるかと思います。 備考: 元々、退職者のアカウントに紐づいていたのを別の人が受信できるようにすると、コンプライアンスなどの問題に発展する可能性があるので、やる場合はセキュリティ部門に相談した方が良いかと思います。 ... View more

Thank you! I captured a screenshot.   ... View more

実際の案件でパラメータ シートでの管理や、手順の作成にあたり 「英語を前提にするか、BETA版だとしても日本語を前提にするか」の観点があったので、 言語設定の扱いの状況をフォロー頂けて助かりました。 ... View more

すでにコメントがありますが、言語の変更機能はBETA版になります。 フィードバックまでは出来ると思いますが、修正の担保まではサポートされないかと存じます。   フィードバックを送りたい場合は、Dashboard右下の「Give your feedback」から英語で送るのが良いかと存じます。     ↓↓↓↓   またMeraki全体のIssuesは下記で確認が可能です。 2025年05月20日の20時現在で該当事象は発生していないようです。 Meraki Status https://status.meraki.net/ また今回のようにCommunityにて同様の事象が発生しているユーザーが居るかどうか確認する方法もあるかと存じます。 (私は英語環境にしているため、事象の該当条件を満たしてなかったです。) ... View more

> New articles: > Local DNS Service on MX > Change: New article. There's a separate discussion on this topic - just dropping the link here in case it's helpful: Local DNS server on MX - The Meraki Community https://community.meraki.com/t5/-/-/m-p/271957 ... View more

日本語の記事を作っていただいて大変助かります。 今までだと、下記の「API」によって「APIのリクエストのログを取得」して解析になると思うので Dashboardから簡単に見れるようになったのは有難いです。 Get Organization Api Requests - Meraki Dashboard API v1 - Cisco Meraki Developer Hub https://developer.cisco.com/meraki/api-v1/get-organization-api-requests/ GET /organizations/{organizationId}/apiRequests   ... View more

@CarolineS - thanks for the information! ... View more

Japan Community still appears to be independent. It would be helpful if you could consider consolidating the Japan Community. Meraki Go Japan - The Meraki Community https://community.meraki.com/t5/Meraki-Go-Japan/ct-p/go-jp ... View more

まず最近の事情を鑑みると、Wi-Fi 6E (6GHz)を利用したい場合は WPA3 や 802.11w が必須になります。 その都合上、特に「古い端末」や「特殊な端末 (例:ハンディ ターミナル)」の場合は必須要件を満たせない可能性が出てきます。   一般的に、 ・情報システム部門が制御可能な「社内端末」 ・情報システム部門が制御できない「ゲストWi-Fi」 に大別されると思いますが、「ゲストWi-Fi」用途であればユーザーがどのような端末を持ち出すか分からないため、 サービス提供にあたり利用規約で絞ったり、あくまでもベスト エフォートでの提供といった条件付けが必要になるかもしれません。 極端な例ですが、昔のゲーム機であるPSPでゲストWi-FiにWPA2で接続しようとして、内蔵ブラウザを使おうとするかもしれません。   「社内端末」であれば、端末種別, 無線LANチップ, ドライバーなどを把握して 事前に十分にテストできれば、接続互換性の問題を潰していくチャンスがあると存じます。 また「WPA3 Transition Mode」で接続されようとして接続できなくて、 「WPA3 Only (WPA3のみ」にしての動作を確認されたのかもしれませんが、 WPA3 Transition Modeは互換性を維持する側面があるものの、 古い端末は(互換性重視とはいえ新しい規格の)WPA3 Transition Modeの動きを想定してない可能性があるので問題が出るかもしれません。 それらを踏まえまして設計の観点では、下記のような案が考えうるかと存じます。あくまでも一例です。 ・執務用の端末は6GHzをメインに利用してセキュリティを確保するためにWPA3 OnlyのSSID ・社内端末で接続互換性に問題が出た際に暫定対処策となるWPA2 OnlyのSSID ・ゲストWi-Fiは端末種別が想定できないのでWPA1 and WPA2のSSID   各社 (各メーカー)が互換性の維持を務めているかと存じますが、 どうしても何かしらの課題は残ってしまう可能性があるので、それらを吸収できるような設計にしていくしかないかなと存じます。 ... View more

監査要件などでエクスポートが必須ではないのであれば、 攻撃の兆候などを捉えるために、隔週などでWeb UIの方からチェックする運用もあるかなと存じます。 結局はエクスポートしても役立てないと意味がないので。 ... View more

Beta版 (Early Access)も見てみましたが、 現状でメニュー「Organization > Login attempts」相当のAPIは無いように見受けられます。   Beta版 (Early Access)は左ペインの「API Reference (Early Access)」セクションより「API」から参照できます。   https://developer.cisco.com/meraki/api-v1/api-reference-early-access-overview/   ... View more

"Intelligent Capture - MR" seems to be supported in version MR 31.1.3.   [Release note: Wireless firmware versions MR 31.1.3 changelog] > New feature > Intelligent Capture for Wireless Proactive packet capture support ... View more

言い切れはしないですが「Auto VPNありき」の特性になっているかなとは思います。 小難しい話になるかもしれませんが、参考程度に関連情報をお伝えします。   ●用途の観点 Meraki MXでBGPを利用する典型的な用途だと DC側のMXでBGPピアから学習したルートを、拠点側に配布するようなイメージになります。   具体的には、拠点側のMXがSplit TunnelでDC側のMXにトンネルを張っている設計で、 Express RouteのようなDCを経由させたルートをBGPで拠点側のMXに知らせる感じです。 ※備考: Full Tunnelだと全ての通信がトンネルを通ってDC経由になりますが、Split Tunnelでは拠点から直接抜けれます。     ●設定の観点 BGPの設定が可能なのは、基本的にはOne-Armed構成のMXになります。DC側に設置されるMXが対象になると思って頂くのが分かりやすいです。 拠点側のMX (Routed Mode)はBGPのルートは受けれますがBGPの設定はできません。 また、BGPルートの細かな制御はできないです。   一応、最近のバージョンだとRouted Mode (主に拠点側のMX用)と呼ばれる状態でもBGPを設定できるようになったようですが、 前述の用途の都合上、Routed ModeでBGPを使うメリットはあまりないと思います。 Routed ModeでBGPを使うためには、NAT Exception (NATしない機能)が必要なのも向いてないのも理由になります。 Routed Modeは拠点のWAN Router想定で、送信元NATする前提のようなアーキテクチャになっているので、NAT無効化すると色々な前提が崩れて設計が大変になると思います。   【関連ドキュメント】 Border Gateway Protocol (BGP) - Cisco Meraki Documentation https://documentation.meraki.com/MX/Networks_and_Routing/Border_Gateway_Protocol_(BGP) > To enable routed mode eBGP routing, the MX must be running MX 18.205 or higher firmware. > When establishing eBGP peering in on the WAN, NAT Exceptions with Manual Inbound Firewall is also needed, otherwise the subnets advertised by the MX will be behind NAT and not reachable via eBGP upstream.     ●製品選定の観点 Merakiは機能を限定して展開力に秀でたアーキテクチャになってますが、 シンプルに寄せていて機能は絞っているので、 多機能性に秀でた製品からの更改には適さない可能性があります。 そのため、製品候補に最後まで残るのであれば、PoCされるのが良いかと思います。 ... View more

Zを含むMXシリーズの内蔵無線LANは、SSIDを最大 4つまで設定/有効化できます。 そのため、6つのSSIDの事前作成はできません。   またWirelessに特化した製品であるMRシリーズと比べて、簡易的な無線LAN機能になる点に留意を頂くのが良いかと思います。 ... View more

Merakiの技術的・仕様的に云々と言うよりかは、 委託先とご自身の会社間の"双方"で、権利・契約上の問題を整理して認識合わせするのが先だと思います。   ・機器の所有権は誰にあるのか。 ・ライセンスの所有権は誰にあるのか。 ・現在のOrganizationの所有者は誰にあるのか。 ・機器の委託の取り決めは、委託先とご自身の会社間で契約上はどのようになっているのか。 ・ライセンス購入時などにメーカーへの提出するEnd User情報などは誰になっているのか。   などが整理されてない中でメーカーに問い合わせも、メーカー側が困ると思いますし。 それらをクリアしないまま技術的・仕様的な話にフォーカスしても、余計な混乱を招くと思います。 ... View more

企業向けの無線LAN導入の観点だと、「製品仕様としての最大数」より「無線LANデザインとしての接続台数」を気にされた方が良いかと思います。   例えば「1台の無線APに端末が50台ほど接続する設計」と仮定した場合、 1台の無線APが障害でダウンすれば、他の無線APにその50台分が押し寄せてきます。 周囲に自身を含めて無線APが3台しかない場合は、残りの2台で等分しても+25台ほどを捌く必要が出てきてしまいます。 よって、仕様的に許容する接続台数が多くても、無線LANデザイン的には好ましくない状況が考えられます。 そのため、多くても30台程度で見積もっておいた方が良いかと存じます。   接続台数を少なく見積もりすぎて無線APが多くなっても、 それはそれで無線AP同士で電波干渉が発生しやすくなるのでカバレッジのチューニングが必要です。   ちなみにMerakiのドキュメント上では無線APあたりの端末接続数が30台を超えると高密度環境に分類されます。   高密度Wi-Fi導入 - Cisco Meraki Documentation https://documentation.meraki.com/%E6%97%A5%E6%9C%AC%E8%AA%9E/Architectures_and_Best_Practices/%E9%AB%98%E5%AF%86%E5%BA%A6Wi-Fi%E5%B0%8E%E5%85%A5 > 高密度Wi-Fiは、大規模展開のための設計計画です。この計画では、小規模のスペース内で多数のクライアントがアクセス ポイント（AP）に接続することが予想される場合に、広範囲にわたる接続性をクライアントに提供します。30台を超えるクライアントが1台のAPに接続する場合、その場所は高密度環境に分類できます。 ... View more