diff --git a/src/content/changelog/magic-firewall/2024-10-02-custom-rule-search.mdx b/src/content/changelog/magic-firewall/2024-10-02-custom-rule-search.mdx
index a749a5dd7b5d6dc..fde581b866baddc 100644
--- a/src/content/changelog/magic-firewall/2024-10-02-custom-rule-search.mdx
+++ b/src/content/changelog/magic-firewall/2024-10-02-custom-rule-search.mdx
@@ -15,4 +15,4 @@ The Magic Firewall dashboard now allows you to search custom rules using the rul
Additionally, the rule ID URL link has been added to Network Analytics.
-For more details about rules, refer to [Add rules](/magic-firewall/how-to/add-rules/).
+For more details about rules, refer to [Add rules](/cloudflare-one/traffic-policies/packet-filtering/add-rules/).
diff --git a/src/content/docs/cloudflare-one/changelog/magic-firewall.mdx b/src/content/docs/cloudflare-one/changelog/magic-firewall.mdx
new file mode 100644
index 000000000000000..92ed4fa57bd88ac
--- /dev/null
+++ b/src/content/docs/cloudflare-one/changelog/magic-firewall.mdx
@@ -0,0 +1,22 @@
+---
+pcx_content_type: changelog
+title: Magic Firewall
+---
+
+import { ProductChangelog } from "~/components";
+
+{/* */}
+
+
+
+## 2024-09-12
+
+**New UI improvements**
+
+The dashboard now displays the order number of custom rules, and improved drag and drop functionality. You can also preview rules on a side panel without leaving the current page.
+
+## 2024-08-16
+
+**Magic Firewall Analytics Rule Log Enhancement**
+
+Customers who create a rule in a disabled mode will see the rule as **Log (rule disabled)**.
diff --git a/src/content/docs/cloudflare-one/insights/logs/filter-views.mdx b/src/content/docs/cloudflare-one/insights/logs/filter-views.mdx
new file mode 100644
index 000000000000000..7e3b0481e6aa85c
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/logs/filter-views.mdx
@@ -0,0 +1,97 @@
+---
+title: Filter different views
+pcx_content_type: how-to
+
+---
+
+You can utilize different [Log filters](/logs/logpush/logpush-job/filters/) to only view specific data from Magic Firewall.
+
+## Filter by enabled or disabled rules
+
+Use the filter examples below to filter your Magic Firewall traffic to display events for enabled or disabled rules.
+
+The example below only displays fields relevant to Magic Firewall, and the filter only displays events for disabled rules.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logpush/jobs \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ ...
+ "output_options": {
+ "field_names": ["ColoName", "Datetime", "Direction", "IPDestinationAddress", "IPDestinationSubnet", "IPProtocol","IPSourceAddress", "IPSourceSubnet", "Outcome", "RuleID", "RulesetID", "SampleInterval", "Verdict"],
+ },
+ "filter": "{\"where\":{\"or\":[{\"and\":[{\"key\":\"MitigationSystem\",\"operator\":\"eq\",\"value\":\"magic-firewall\"},{\"key\":\"RulesetID\",\"operator\":\"!eq\",\"value\":\"\"},{\"key\":\"Outcome\",\"operator\":\"eq\",\"value\":\"pass\"},{\"key\":\"Verdict\",\"operator\":\"eq\",\"value\":\"drop\"}]}]}}"
+}'
+```
+
+The example below only displays fields relevant to Magic Firewall, and the filter only displays events for enabled rules.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logpush/jobs \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ ...
+ "output_options": {
+ "field_names": ["ColoName", "Datetime", "Direction", "IPDestinationAddress", "IPDestinationSubnet", "IPProtocol","IPSourceAddress", "IPSourceSubnet", "Outcome", "RuleID", "RulesetID", "SampleInterval", "Verdict"],
+ },
+ "filter": "{\"where\":{\"or\":[{\"and\":[{\"key\":\"MitigationSystem\",\"operator\":\"eq\",\"value\":\"magic-firewall\"},{\"key\":\"RulesetID\",\"operator\":\"!eq\",\"value\":\"\"},{\"or\":[{\"key\":\"Outcome\",\"operator\":\"eq\",\"value\":\"drop\"},{\"key\":\"Verdict\",\"operator\":\"eq\",\"value\":\"pass\"}]}]}]}}"
+}'
+```
+
+## Filter by allowed or blocked traffic
+
+Use the filter examples below to filter your Magic Firewall traffic to display events for allowed or blocked traffic.
+
+The example below only displays fields relevant to Magic Firewall, and the filter only displays events where no explicit action was taken, for example, a packet "fell through" Magic Firewall. This example does not have any rules applied.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logpush/jobs \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ ...
+ "output_options": {
+ "field_names": ["ColoName", "Datetime", "Direction", "IPDestinationAddress", "IPDestinationSubnet", "IPProtocol","IPSourceAddress", "IPSourceSubnet", "Outcome", "RuleID", "RulesetID", "SampleInterval", "Verdict"],
+ },
+ "filter": "{\"where\":{\"and\":[{\"key\":\"MitigationSystem\",\"operator\":\"eq\",\"value\":\"magic-firewall\"},{\"key\":\"RulesetID\",\"operator\":\"eq\",\"value\":\"\"}]}}"
+}'
+```
+
+The example below only displays fields relevant to Magic Firewall, and the filter only displays events where explicit action was taken. The example includes both enabled and disabled Magic Firewall rules.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logpush/jobs \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ ...
+ "output_options": {
+ "field_names": ["ColoName", "Datetime", "Direction", "IPDestinationAddress", "IPDestinationSubnet", "IPProtocol","IPSourceAddress", "IPSourceSubnet", "Outcome", "RuleID", "RulesetID", "SampleInterval", "Verdict"],
+ },
+ "filter": "{\"where\":{\"and\":[{\"key\":\"MitigationSystem\",\"operator\":\"eq\",\"value\":\"magic-firewall\"},{\"key\":\"RulesetID\",\"operator\":\"!eq\",\"value\":\"\"}]}}"
+}'
+```
+
+## Filter by relevant fields to Magic Firewall
+
+Use the examples below to filter out fields that are not relevant to traffic flowing through Magic Firewall. The example below only includes Magic Firewall events.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logpush/jobs \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ ...
+ "output_options": {
+ "field_names": ["ColoName", "Datetime", "Direction", "IPDestinationAddress", "IPDestinationSubnet", "IPProtocol","IPSourceAddress", "IPSourceSubnet", "Outcome", "RuleID", "RulesetID", "SampleInterval", "Verdict"],
+ },
+ "filter": "{\"where\":{\"key\":\"MitigationSystem\",\"operator\":\"eq\",\"value\":\"magic-firewall\"}}"
+}'
+```
diff --git a/src/content/docs/cloudflare-one/insights/logs/use-logpush-with-ids.mdx b/src/content/docs/cloudflare-one/insights/logs/use-logpush-with-ids.mdx
new file mode 100644
index 000000000000000..f0bd22ca62e54c8
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/logs/use-logpush-with-ids.mdx
@@ -0,0 +1,21 @@
+---
+title: Use Logpush with IDS
+pcx_content_type: concept
+
+---
+
+You can use Logpush with Magic Firewall IDS to log detected risks:
+
+1. Consult the [Logpush Destination docs](/logs/logpush/logpush-job/api-configuration/#destination) to learn about what destinations Logpush supports. The documentation will also instruct you on how to correctly format the destination URL for Logpush.
+
+2. Follow the [Manage Lopush with cURL](/logs/logpush/examples/example-logpush-curl/) tutorial to validate your Logpush destination and define a Logpush job.
+
+## Notes on using Logpush with IDS
+
+* Magic IDS is an account-scoped dataset. This means the string `/zone/` in the Cloudflare API URLs in the tutorial should be replaced with `/account/`.
+
+* Consult the [Magic IDS Detection fields doc](/logs/logpush/logpush-job/datasets/account/magic_ids_detections/) to know what fields you want configured for the job.
+
+* When creating the Logpush job, the dataset field should equal `magic_ids_detections`.
+
+* Timestamps by default are unixnano. Consult the [Logpush Options docs](/logs/logpush/logpush-job/api-configuration/#options) to learn what format you can choose that will be compatible with your destination and/or expectations. Note that all options must be added *after* all fields you want from the Logpush job, akin to URL parameters.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/buckets.mdx b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/buckets.mdx
new file mode 100644
index 000000000000000..44d2017f301ce25
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/buckets.mdx
@@ -0,0 +1,219 @@
+---
+title: Buckets
+pcx_content_type: how-to
+sidebar:
+ order: 3
+---
+
+import { GlossaryTooltip, TabItem, Tabs, DashButton } from "~/components";
+
+Before you can begin a full packet capture, you must first configure a bucket that Cloudflare can use to upload your files. Setting up a bucket is not required for sample packet captures.
+
+You can configure an Amazon S3 or Google Cloud Platform bucket to use as a target. You can also [use R2](#r2) as a target using the API.
+
+## Set up a bucket
+
+Learn how to set up a bucket for use with full packet captures.
+
+
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Network visibility** > **Diagnostics**.
+2. Select the **Buckets** tab > **Add a bucket**.
+3. Select a bucket service and select **Next**.
+4. Enter the information related to your bucket for your service provider.
+5. When you are done, select **Next**.
+
+The **Prove ownership** step of the **Bucket configuration** displays.
+
+
+
+Before you can begin using a bucket, you must first enable destinations.
+
+Refer to the [Amazon S3](/logs/logpush/logpush-job/enable-destinations/aws-s3/#create-and-get-access-to-an-s3-bucket) or [Google Cloud Storage](/logs/logpush/logpush-job/enable-destinations/google-cloud-storage/#create-and-get-access-to-a-gcs-bucket) documentation and follow the steps for those specific services.
+
+
+
+Next, validate the bucket and confirm ownership.
+
+## Validate a bucket
+
+After the initial bucket set up, you need to confirm you own the bucket via an ownership challenge. After you validate your bucket, you can begin using it to collect full packet captures.
+
+
+
+1. From the **Prove ownership** step of the **Bucket configuration**, locate the **Ownership token** field.
+2. In the **Ownership token** field, enter the ownership token for your service provider.
+3. When you are done, select **Create**. The **Packet captures** page displays.
+
+The **Buckets** tab displays a list of the buckets associated with your account. Refer to the **Status** column to see the status of your bucket configuration.
+
+
+
+The `bucket` field should be the URI of the bucket. For Amazon S3, the `bucket` field is in the form `s3:///?region=`, and for Google Cloud Storage the form is `gs:///`.
+
+```bash title="Ownership challenge request example"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/ownership \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "destination_conf": "'${bucket}'"
+}'
+```
+
+The response has a `"filename"` parameter which contains the content of the `ownership-challenge` text. Find the file in your bucket and copy the contents of the file.
+
+```json title="Ownership challenge response example"
+{
+ "result": {
+ "id": "cc20c2d6c62e11ecbe646b173af3b6b9",
+ "status": "pending",
+ "submitted": "2022-04-22T18:54:13.397413Z",
+ "validated": "",
+ "destination_conf": "gs://bucket-test", // Ensure you use a bucket that you created and registered in the Cloudflare dashboard.
+ "filename": "ownership-challenge-1234.txt"
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+Validate the bucket by inserting the copied text in the `ownership_text` below:
+
+```bash title="Bucket validation example"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/ownership/validate \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "destination_conf": "'${bucket}'",
+ "ownership_challenge": "'${ownership_text}'"
+}'
+```
+
+```json title="Bucket validation response"
+{
+ "result": {
+ "id": "cc20c2d6c62e11ecbe646b173af3b6b9",
+ "status": "success",
+ "submitted": "2022-04-22T18:54:13.397413Z",
+ "validated": "2022-04-27T14:54:46.440548Z",
+ "destination_conf": "gs://", // Ensure you use a bucket that you created and registered in the Cloudflare dashboard
+ "filename": "ownership-challenge-1234.txt"
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+If the `status` shows `success`, the bucket is configured and ready to use.
+
+
+
+The bucket status displays one of the following options:
+
+- **Success:** The bucket is fully verified and ready to use.
+- **Pending:** The challenge response was initiated but is pending verification. Bucket verification can take five to ten minutes to finish processing.
+- **Failed:** The bucket could not be validated. If this occurs, verify your ownership information.
+
+## List configured buckets
+
+View a list of all buckets configured on your account.
+
+
+
+1. In the Cloudflare One dashboard, go to the **Packet captures** page in Magic Transit or Magic WAN.
+
+ To set up a packet capture in Magic Transit:
+
+ To set up a packet capture in Magic WAN:
+2. In **Packet captures**, select **Start a capture**.
+3. Select the **Buckets** tab.
+
+The list of buckets associated with your account displays.
+
+
+
+```bash title="Bucket list request example"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/ownership \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: "
+```
+
+```json title="Bucket list response example"
+{
+ "result": [
+ {
+ "id": "9a993aa6c58711ec89d3037647342e63",
+ "status": "success",
+ "submitted": "2022-04-26T16:58:24.550762Z",
+ "validated": "2022-04-26T17:01:18.426458Z",
+ "destination_conf": "s3://test-bucket?region=us-east-1",
+ "filename": "ownership-challenge-1234.txt"
+ }
+ ],
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+
+
+To learn how to collect packet captures, refer to [Collect packet captures](/magic-firewall/packet-captures/collect-pcaps/).
+
+## R2
+
+To start collecting packet captures with R2, you first need to configure it properly. For all the required details, refer to the [Cloudflare R2](/r2/) documentation.
+
+### Create bucket and API token
+
+1. In the Cloudflare One dashboard, go to the **R2** page.
+
+
+
+2. Select **Create bucket**.
+3. Give your bucket a name > **Create bucket**.
+4. Go to the R2 Overview page, and select **Manage R2 API Tokens**.
+5. Select **Create API Token**.
+6. In **Permissions**, choose **Object Read & Write**. Make sure you also select **Apply to specific buckets only**, and select the bucket you have created for PCAPs from the drop-down menu.
+7. Select **Create API Token**.
+8. Make sure you copy the **Secret Access Key** and **Access Key ID** values, as you will need them for the next step.
+
+### Create initial request
+
+Create your initial request to R2:
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/ownership \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "destination_conf": "r2://?account-id=&access-key-id=&secret-access-key="
+}'
+```
+
+The [response](/api/resources/magic_transit/subresources/pcaps/subresources/ownership/methods/create/) has a `"filename"` parameter with the name of a file that Cloudflare wrote to your R2 bucket. You need to download it for the next step. Example:
+
+```json
+{
+ "errors": [],
+ "messages": [],
+ "result": {
+ "destination_conf": "",
+ "filename": "ownership-challenge-9883874ecac311ec8475433579a6bf5f.txt",
+ "id": "9883874ecac311ec8475433579a6bf5f",
+ "status": "success",
+ "submitted": "2020-01-01T08:00:00Z",
+ "validated": "2020-01-01T08:00:00Z"
+ },
+ "success": true
+}
+```
+
+### Validate bucket ownership
+
+Refer to the [Validate a bucket](#validate-a-bucket) API instructions for more details on the entire process to [validate your R2 bucket](/api/resources/magic_transit/subresources/pcaps/subresources/ownership/methods/validate/). When specifying the R2 destination for this validation, exclude the secret and access keys from the URL.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/index.mdx b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/index.mdx
new file mode 100644
index 000000000000000..b45e3e618687ba6
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/index.mdx
@@ -0,0 +1,33 @@
+---
+title: Diagnostics
+pcx_content_type: navigation
+sidebar:
+ order: 1
+
+---
+
+import { DirectoryListing } from "~/components"
+
+Cloudflare supports two types of packet captures: full and sample. Full packet captures is the default behavior.
+
+:::note
+The maximum packet capture runtime is 24 hours for sample and full packet captures.
+:::
+
+## Sample packet captures
+
+Sample packet captures collects historical data on network traffic that has already passed through Cloudflare's network. It will not collect any new traffic sent to Cloudflare's network after the packet capture has started. All sample packet captures will complete immediately after they are started because they query historical traffic data.
+
+Sample packet captures can be viewed in the Cloudflare dashboard. They only include the first 160 bytes of data. This is useful for capturing packet headers, but will not provide detailed packet data. The sample data is collected across all Cloudflare's data centers to build a PCAP file. This allows you to get a global picture of traffic across all data centers.
+
+You should use full packet captures if you need to collect data on packets that pass through your network less frequently.
+
+## Full packet captures
+
+Full packet captures will actively monitor Cloudflare's network for packets that match the selected filters, and will capture the matching packet data. The matching packet data is saved to a cloud storage bucket that is owned and configured by you.
+
+Full packet captures will collect new traffic sent to Cloudflare's network after the packet capture has started, and include the full packet data. This type of capture cannot be viewed in the Cloudflare dashboard. You can download them from a cloud storage bucket and analyze them in Wireshark or another packet capture tool.
+
+Refer to the articles in this section to learn how to use packet captures.
+
+
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/packet-captures.mdx b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/packet-captures.mdx
new file mode 100644
index 000000000000000..34d8f7f135d053e
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/network-visibility/diagnostics/packet-captures.mdx
@@ -0,0 +1,298 @@
+---
+title: Packet captures
+pcx_content_type: how-to
+sidebar:
+ order: 2
+---
+
+import { Details, GlossaryTooltip, TabItem, Tabs, DashButton } from "~/components";
+
+After a packet capture is requested and the capture is collected, the output is contained within one or more files in PCAP file format. Before starting a `full` type packet capture, you must first follow instructions for [configuring a bucket](/magic-firewall/packet-captures/pcaps-bucket-setup/).
+
+:::note
+
+Packet captures are available for Advanced Magic Firewall users. For access, contact your account team.
+
+:::
+
+## Send a packet capture request
+
+Currently, when a packet capture is requested, packets flowing at Cloudflare's global network through the Magic Transit system are captured. The default API field for this is `"system": "magic-transit"`, both for the request and response.
+
+:::note[Note]
+
+For help determining which data center to select for a packet capture, go to [https://cloudflare.com/cdn-cgi/trace](https://cloudflare.com/cdn-cgi/trace) and refer to the `colo` field. Note some data centers can be regional such as `ORD` while other names may be more specific like `ord02`. Either of these names can be used for this same field.
+
+:::
+
+### Packet capture limits
+
+**Sample and full**
+
+- `time_limit`: The minimum value is `1` seconds and maximum value is `300` seconds.
+- `packet_limit`: The minimum value is `1` packet and maximum value is `10000` packets.
+
+**Full**
+
+- `byte_limit`: The minimum value is `1` byte and maximum value is `1000000000` bytes.
+
+
+
+1. In the Cloudflare dashboard, go to the **Packet captures** page in Magic Transit or Magic WAN.
+
+ To set up a packet capture in Magic Transit:
+
+ To set up a packet capture in Magic WAN:
+
+2. In **Captures**, select **Start a capture**.
+3. Select the **Captures** tab > **Start a capture**.
+4. Choose the type of capture you want to perform, and select **Next**.
+5. Fill out the required fields to begin the capture and then select **Start**.
+
+The main **Packet captures** page displays a list of captures.
+
+
+
+The PCAPs API needs both `system` and `type` to be specified to start a capture. A PCAP's `system` is the product or logical subsystem where packets are captured, and a PCAP's `type` is how the captured packets are built into a PCAP file.
+
+Currently, you can only send one collect request per minute for sample PCAPs, and you can only have one running or pending full PCAP at a time.
+
+
+
+For full PCAP requests, refer to the required parameters listed at [Create full PCAP requests](/api/resources/magic_transit/subresources/pcaps/methods/create/). Note that full packet captures require two more parameters than sample packets.
+
+The full PCAP request endpoint also contains optional fields you can use to limit the amount of packets captured. Both full and sample packet requests contain an optional `filter_v1` parameter you can use to filter packets by IPv4 Source address, for example. For a full list of the filter options, refer to the parameter lists above.
+
+Leave `filter_v1` empty to collect all packets without any filtering.
+
+```bash title="Full PCAP example request"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "filter_v1": {},
+ "time_limit": 300,
+ "packet_limit": 10000,
+ "byte_limit": 100000000,
+ "type": "full",
+ "colo": "ORD",
+ "system": "magic-transit",
+ "destination_conf": "${BUCKET}"
+}'
+```
+
+While the collection is in progress, the response returns the `status` field as `pending`. You must wait for the PCAP collection to complete before downloading the file. When the PCAP is ready to download, the status changes to `success`.
+
+```json title="Full PCAP example response"
+{
+ "result": {
+ "id": "7d7c88382f0b4d5daa9587aa45a1a877",
+ "submitted": "2022-06-02T18:38:22.269047Z",
+ "filter_v1": {},
+ "time_limit": 300,
+ "status": "pending",
+ "type": "full",
+ "system": "magic-transit",
+ "packet_limit": 10000,
+ "byte_limit": 100000000,
+ "colo": "ORD",
+ "destination_conf": "gs://" // Ensure you use a bucket that you created and registered in the Cloudflare dashboard
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+
+
+
+
+To create a sample PCAP request, send a JSON body with the required parameter listed at [Create sample PCAP request](/api/resources/magic_transit/subresources/pcaps/methods/create/).
+
+Leave `filter_v1` to collect all packets without any filtering.
+
+```bash title="Sample PCAP example request"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "filter_v1": {
+ "source_address": "1.2.3.4",
+ "source_port": 123,
+ "destination_address": "5.6.7.8",
+ "destination_port": 80,
+ "protocol": 6
+ },
+ "time_limit": 300,
+ "packet_limit": 10000,
+ "type": "simple",
+ "system": "magic-transit"
+}'
+```
+
+The response is a JSON body that contains the details of the job running to build the packet capture. The response contains a unique identifier for the packet capture request along with the details sent in the request.
+
+```json title="Sample PCAP example response"
+{
+ "result": {
+ "id": "6d1f0aac13cd40e3900d29f5dd0e8a2b",
+ "submitted": "2021-12-20T17:29:20.641845Z",
+ "filter_v1": {
+ "source_address": "1.2.3.4",
+ "source_port": 123,
+ "destination_address": "5.6.7.8",
+ "destination_port": 80,
+ "protocol": 6
+ },
+ "time_limit": 60,
+ "status": "pending",
+ "packets_remaining": 0,
+ "type": "simple",
+ "system": "magic-transit"
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+
+
+
+
+## Check packet capture status
+
+
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Network visibility** > **Diagnostics**.
+2. In **Captures**, select **Start a capture**.
+3. Select between **Full packet capture** or **Sample packet capture**, then fill in the information.
+4. Once you filled all the information, select **Start**.
+
+
+
+To check the status of a running job, send a request to the endpoint and specify the PCAP identifier. The PCAP identifier is received in the response of a collect request as shown in the previous step.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/{pcap_id} \
+--header 'X-Auth-Email: ' \
+--header 'X-Auth-Key: '
+```
+
+The response will be similar to the one received when requesting a PCAP collection.
+
+```json title="Sample PCAP example result"
+{
+ "result": {
+ "id": "6d1f0aac13cd40e3900d29f5dd0e8a2b",
+ "submitted": "2021-12-20T17:29:20.641845Z",
+ "filter_v1": {
+ "source_address": "1.2.3.4",
+ "source_port": 123,
+ "destination_address": "5.6.7.8",
+ "destination_port": 80,
+ "protocol": 6
+ },
+ "time_limit": 120,
+ "status": "success",
+ "packets_remaining": 0,
+ "type": "simple",
+ "system": "magic-transit"
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+
+
+The capture status displays one of the following options:
+
+- **Complete:** The capture request is done and ready for download.
+- **In progress:** The capture request was captured but still processing.
+- **Failure:** The capture failed. If this occurs, verify your ownership information.
+
+## Download packet captures
+
+After your request finishes processing, you can download your packet captures.
+
+
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Network visibility** > **Diagnostics**.
+2. In **Packet captures**, select **Start a capture**.
+3. Locate your packet capture you want to download, and select **Download**.
+
+Packet captures are available to download when the **Status** displays **Success**.
+
+
+
+For more information on how to process multiple saved capture files into a single output file, refer to [Wireshark's mergecap documentation](https://www.wireshark.org/docs/man-pages/mergecap.html).
+
+**Full PCAPs**
+
+To obtain full PCAPs, download the files from the bucket specified in `destination_conf` after the PCAP's status is `success`. You may find multiple files named `pcap_.pcap` per capture as captures can occur across multiple machines.
+
+**Sample PCAPs**
+
+Once the sample PCAP collection is complete, you can download the PCAP by specifying the PCAP identifier used earlier.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps/{pcap_id}/download \
+--header 'X-Auth-Email: ' \
+--header 'X-Auth-Key: ' \
+--output download.pcap
+```
+
+
+
+## List packet captures
+
+
+
+1. In the Cloudflare dashboard, go to the **Packet captures** page in Magic Transit or Magic WAN.
+
+ To set up a packet capture in Magic Transit:
+
+ To set up a packet capture in Magic WAN:
+2. In **Packet captures**, select **Start a capture**.
+3. Select the **Captures** tab.
+
+The list of packet captures associated with your account displays.
+
+
+
+To view a list of sent requests, use the following command:
+
+```bash title="List request example"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/pcaps \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: "
+```
+
+The response returns an array that includes up to 50 sent requests, which includes completed and ongoing requests.
+
+```json title="List response example"
+{
+ "result": [
+ {
+ "id": "43adab5adeca4dab9c51f4b7f70f2ec3",
+ "submitted": "2021-12-15T03:04:09.277394Z",
+ "filter_v1": {},
+ "time_limit": 120,
+ "status": "success",
+ "packets_remaining": 0,
+ "type": "simple",
+ "system": "magic-transit"
+ }
+ ],
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/insights/network-visibility/index.mdx b/src/content/docs/cloudflare-one/insights/network-visibility/index.mdx
new file mode 100644
index 000000000000000..024e4e6c473fa40
--- /dev/null
+++ b/src/content/docs/cloudflare-one/insights/network-visibility/index.mdx
@@ -0,0 +1,8 @@
+---
+title: Network visibility
+pcx_content_type: how-to
+sidebar:
+ order: 2
+ group:
+ hideIndex: true
+---
diff --git a/src/content/docs/cloudflare-one/reusable-components/list-types.mdx b/src/content/docs/cloudflare-one/reusable-components/list-types.mdx
new file mode 100644
index 000000000000000..04db275bdc7bf54
--- /dev/null
+++ b/src/content/docs/cloudflare-one/reusable-components/list-types.mdx
@@ -0,0 +1,18 @@
+---
+title: List types
+pcx_content_type: concept
+---
+
+## Threat intelligence
+
+Cloudflare handles millions of HTTP requests each second and blocks billions of cyber threats each day. Cloudflare uses that data to detect malicious actors on the Internet and turns that information into a list of known malicious IP addresses. Cloudflare also integrates with a number of third-party vendors to augment the coverage.
+
+The threat intelligence feed categories are described in [Managed IP Lists](/waf/tools/lists/managed-lists/#managed-ip-lists). All of these lists are compatible with Magic Firewall.
+
+## IP lists
+
+Use [IP lists](/waf/tools/lists/custom-lists/#ip-lists) to group services in networks, like web servers, or for lists of known bad IP addresses to make managing good network endpoints easier. IP lists are helpful for users with very expansive firewall rules with many IP lists. By default, you can add up to 10,000 IPs across all lists. Refer to [Use an IP list](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#use-an-ip-list) to check an example of how to use an IP list.
+
+## Geo-blocking
+
+Geo-blocking enables you to selectively allow or block traffic to any country. Refer to [Block a country](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#block-a-country) to check an example of how to block a country.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/reusable-components/packet-filtering-fields.mdx b/src/content/docs/cloudflare-one/reusable-components/packet-filtering-fields.mdx
new file mode 100644
index 000000000000000..3e4761bb2665fff
--- /dev/null
+++ b/src/content/docs/cloudflare-one/reusable-components/packet-filtering-fields.mdx
@@ -0,0 +1,309 @@
+---
+title: Packet filtering (Magic Firewall) fields
+pcx_content_type: reference
+head:
+ - tag: title
+ content: Packet filtering fields
+---
+
+import { Type } from "~/components";
+
+:::note
+Some Magic Firewall fields are available only to customers who purchased Magic Firewall's advanced features. Refer to [Magic Firewall plans](/magic-firewall/plans/) for more information.
+:::
+
+## `cf.colo.name`
+
+`cf.colo.name`
+
+The data center that is handling this traffic.
+
+Example value: `sfo06`
+
+---
+
+## `cf.colo.region`
+
+`cf.colo.region`
+
+Region of the data center that is handling this traffic.
+
+Example value: `WNAM`
+
+---
+
+## `icmp`
+
+`icmp`
+
+The raw ICMP packet as a list of bytes. It should be used in conjunction with the bit_slice function when other structured fields are lacking.
+
+---
+
+## `icmp.type`
+
+`icmp.type`
+
+The [ICMP type](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#header_type). Only applies to ICMP packets.
+
+Example value: `8`
+
+---
+
+## `icmp.code`
+
+`icmp.code`
+
+The [ICMP code](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#header_code). Only applies to ICMP packets.
+
+Example value: `2`
+
+---
+
+## `ip`
+
+`ip`
+
+The raw IP packet as a list of bytes. It should be used in conjunction with the bit_slice function when other structured fields are lacking.
+
+---
+
+## `ip.dst`
+
+`ip.dst`
+
+The destination address as specified in the IP packet.
+
+Example value: `192.0.2.2`
+
+---
+
+## `ip.dst.country`
+
+`ip.dst.country`
+
+Represents the 2-letter country code associated with the server IP address in [ISO 3166-1 Alpha 2](https://www.iso.org/obp/ui/#search/code/) format.
+
+Example value: `GB`
+
+For more information on the ISO 3166-1 Alpha 2 format, refer to [ISO 3166-1 Alpha 2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) on Wikipedia.
+
+---
+
+## `ip.src.country`
+
+`ip.src.country`
+
+Represents the 2-letter country code associated with the client IP address in [ISO 3166-1 Alpha 2](https://www.iso.org/obp/ui/#search/code/) format.
+
+Example value: `GB`
+
+For more information on the ISO 3166-1 Alpha 2 format, refer to [ISO 3166-1 Alpha 2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) on Wikipedia.
+
+For Magic Firewall, the `ip.geoip.country` field (which is deprecated) will match on either source or destination address. The `ip.geoip.country` field is still available for new and existing rules, but you should use the `ip.src.country` and/or `ip.dst.country` fields instead.
+
+---
+
+## `ip.hdr_len`
+
+`ip.hdr_len`
+
+The length of the IPv4 header in bytes.
+
+Example value: `5`
+
+---
+
+## `ip.len`
+
+`ip.len`
+
+The length of the packet including the header.
+
+Example value: `60`
+
+---
+
+## `ip.opt.type`
+
+`ip.opt.type`
+
+The first byte of [IP options field](https://en.wikipedia.org/wiki/IPv4#Options), if the options field is set.
+
+Example value: `25`
+
+---
+
+## `ip.proto`
+
+`ip.proto`
+
+The transport layer for the packet, if it can be determined.
+
+Example values: `icmp`, `tcp`
+
+---
+
+## `ip.src`
+
+`ip.src`
+
+The source address of the IP Packet.
+
+---
+
+## `ip.src.country`
+
+`ip.src.country`
+
+Represents the 2-letter country code associated with the client IP address in [ISO 3166-1 Alpha 2](https://www.iso.org/obp/ui/#search/code/) format.
+
+Example value: `GB`
+
+For more information on the ISO 3166-1 Alpha 2 format, refer to [ISO 3166-1 Alpha 2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) on Wikipedia.
+
+---
+
+## `ip.ttl`
+
+`ip.ttl`
+
+The time-to-live of the IP Packet.
+
+Example values: `54`
+
+---
+
+## `sip`
+
+`sip`
+
+Determines if packets are valid L7 protocol [SIP](https://datatracker.ietf.org/doc/html/rfc2543). Requires UDP packets to operate.
+
+Use a guard clause as shown below to ensure the packet is UDP (wirefilter):
+
+`ip.proto == "udp"`
+
+---
+
+## `tcp`
+
+`tcp`
+
+The raw TCP packet as a list of bytes. It should be used in conjunction with the bit_slice function when other structured fields are lacking.
+
+---
+
+## `tcp.flags`
+
+`tcp.flags`
+
+The numeric value of the TCP flags byte.
+
+---
+
+## `tcp.flags.ack`
+
+`tcp.flags.ack`
+
+TCP acknowledgment flag.
+
+---
+
+## `tcp.flags.cwr`
+
+`tcp.flags.cwr`
+
+TCP congestion window reduced flag.
+
+---
+
+## `tcp.flags.ecn`
+
+`tcp.flags.ecn`
+
+TCP ECN-Echo flag.
+
+---
+
+## `tcp.flags.fin`
+
+`tcp.flags.fin`
+
+TCP flag indicating this is the last packet from sender.
+
+---
+
+## `tcp.flags.push`
+
+`tcp.flags.push`
+
+TCP push flag.
+
+---
+
+## `tcp.flags.reset`
+
+`tcp.flags.reset`
+
+TCP reset flag.
+
+---
+
+## `tcp.flags.syn`
+
+`tcp.flags.syn`
+
+TCP synchronize flag.
+
+---
+
+## `tcp.flags.urg`
+
+`tcp.flags.urg`
+
+TCP urgent flag.
+
+---
+
+## `tcp.srcport`
+
+`tcp.srcport`
+
+Source port number of the IP packet. Only applies to TCP packets.
+
+---
+
+## `tcp.dstport`
+
+`tcp.dstport`
+
+Destination port number of the IP packet. Only applies to TCP packets.
+
+---
+
+## `udp`
+
+`udp`
+
+The raw UDP packet as a list of bytes. It should be used in conjunction with the bit_slice function when other structured fields are lacking.
+
+---
+
+## `udp.dstport`
+
+`udp.dstport`
+
+Destination port number of the IP packet. Only applies to UDP packets.
+
+---
+
+## `udp.srcport`
+
+`udp.srcport`
+
+Source port number of the IP packet. Only applies to UDP packets.
+
+---
+
+_GeoIP is the registered trademark of MaxMind, Inc._
diff --git a/src/content/docs/cloudflare-one/reusable-components/use-rules-list.mdx b/src/content/docs/cloudflare-one/reusable-components/use-rules-list.mdx
new file mode 100644
index 000000000000000..efded354a74f5c2
--- /dev/null
+++ b/src/content/docs/cloudflare-one/reusable-components/use-rules-list.mdx
@@ -0,0 +1,81 @@
+---
+title: Use IP lists
+pcx_content_type: how-to
+sidebar:
+ order: 3
+head:
+ - tag: title
+ content: Define an IP list
+---
+
+[IP lists](/waf/tools/lists/custom-lists/#ip-lists) are a part of Cloudflare's custom lists. Custom lists contain one or more items of the same type — IP addresses, hostnames or ASNs — that you can reference in rule expressions.
+
+IP lists are defined at the account level and can be used to match against `ip.src` and `ip.dst` fields. Currently, Magic Firewall only supports IPv4 addresses in these lists, not IPv6.
+
+To use this feature:
+
+## 1. Create a [new IP list](/api/resources/rules/subresources/lists/methods/create/).
+
+For example:
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rules/lists \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "name": "iplist",
+ "description": "This contains IPs that should be allowed.",
+ "kind": "ip"
+}'
+```
+
+## 2. Add IPs to the list
+
+Next, [create list items](/api/resources/rules/subresources/lists/subresources/items/methods/create/). This will add elements to the current list.
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rules/lists/{list_id}/items \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '[
+ {"ip":"10.0.0.1"},
+ {"ip":"10.10.0.0/24"}
+]'
+```
+
+## 3. Use the list in a rule
+
+Finally, add a Magic Firewall rule referencing the list into an existing ruleset:
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets/{ruleset_id}/rules \
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "action": "skip",
+ "action_parameters": {
+ "ruleset": "current"
+ },
+ "expression": "ip.src in $iplist",
+ "description": "Allowed IPs from iplist",
+ "enabled": true
+}'
+```
+
+## Managed lists
+
+:::note
+Available for customers with a Magic Firewall Advanced plan.
+:::
+
+You can create rules with managed lists. Managed IP Lists are [lists of IP addresses](/waf/tools/lists/managed-lists/#managed-ip-lists) maintained by Cloudflare and updated frequently.
+
+You can access these managed lists when you create rules with either _IP destination address_ or _IP source address_ in the **Field** dropdown, and _is in list_ or _is not in list_ in the **Operator** dropdown.
+
+For example:
+
+| Field | Operator | Value |
+| ------------------------ | ------------ | ------------- |
+| _IP destination address_ | _is in list_ | _Anonymizers_ |
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/enable-ids.mdx b/src/content/docs/cloudflare-one/traffic-policies/enable-ids.mdx
new file mode 100644
index 000000000000000..907b2846b4afee3
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/enable-ids.mdx
@@ -0,0 +1,90 @@
+---
+title: Enable IDS
+pcx_content_type: how-to
+sidebar:
+ order: 5
+head:
+ - tag: title
+ content: Enable Intrusion Detection System (IDS)
+---
+
+import { TabItem, Tabs, DashButton } from "~/components";
+
+Cloudflare's IDS takes advantage of the threat intelligence powered by our global network and extends the capabilities of the Cloudflare Firewall to monitor and protect your network from malicious actors.
+
+You can enable IDS through the dashboard or via the API.
+
+:::note
+This feature is available for Advanced Magic Firewall users. For access, contact your account team.
+:::
+
+
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies**.
+2. Select **Policy settings** and turn on **IDS**.
+
+
+
+To start using IDS via the API, first create a new ruleset in the `magic-transit-ids-managed` phase with a rule which is enabled.
+
+1. Follow instructions in the [Rulesets Engine Page](/ruleset-engine/basic-operations/view-rulesets/) to view all rulesets for your account. You must see a ruleset with phase `magic-transit-ids-managed` and kind `managed`. If not, please contact your account team. The managed ruleset ID will be used in the next step.
+
+2. Create a new root ruleset with a single rule in the `magic_transit_ids_managed` phase by running:
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets \
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "name": "IDS Execute ruleset",
+ "description": "Ruleset to enable IDS",
+ "kind": "root",
+ "phase": "magic_transit_ids_managed",
+ "rules": [
+ {
+ "enabled": true,
+ "expression": "true",
+ "action": "execute",
+ "description": "enable ids",
+ "action_parameters": {
+ "id": "${managed_ruleset_id}"
+ }
+ }
+ ]
+}'
+```
+
+With this ruleset added, IDS will start inspecting packets and report any anomalous traffic. Next, you can [configure Logpush](/magic-firewall/how-to/use-logpush-with-ids/) to start receiving details about the anomalous traffic.
+
+3. Use the rule created in the previous step to enable or disable IDS. The Rulesets API documentation describes [how to patch a rule](/ruleset-engine/rulesets-api/update-rule/).
For example, the following patch request to set the `enabled` field to `false` will disable IDS. The ruleset and rule ID from the ruleset created in the previous step are used below.
+
+```bash
+curl --request PATCH \
+https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets/{root_ruleset_id}/rules/{rule_id} \
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "enabled": false,
+ "expression": "true",
+ "action": "execute",
+ "action_parameters": {
+ "id": "${managed_ruleset_id}"
+ }
+}'
+```
+
+Similarly, sending a patch request with the `enabled` field set to `true` will enable IDS.
+
+
+
+## IDS rules
+
+IDS rules are run on a subset of packets. IDS also supports the current flows:
+
+- Magic WAN to Magic WAN.
+- Magic Transit ingress traffic (when egress traffic is handled through direct server return).
+- Magic Transit ingress and egress traffic when Magic Transit has the [Egress option enabled](/reference-architecture/architectures/magic-transit/#magic-transit-with-egress-option-enabled).
+
+## Next steps
+
+You must configure Logpush to log detected risks. Refer to [Configure a Logpush destination](/magic-firewall/how-to/use-logpush-with-ids/) for more information. Additionally, all traffic that is analyzed can be accessed via [network analytics](/analytics/network-analytics/). Refer to [GraphQL Analytics](/magic-firewall/tutorials/graphql-analytics/) to query the analytics data.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/ids.mdx b/src/content/docs/cloudflare-one/traffic-policies/ids.mdx
new file mode 100644
index 000000000000000..fe85c9f08217fd0
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/ids.mdx
@@ -0,0 +1,15 @@
+---
+title: IDS
+pcx_content_type: concept
+
+---
+
+Cloudflare's Intrusion Detection System (IDS) is an Advanced Magic Firewall feature you can use to actively monitor for a wide range of known threat signatures in your traffic. An IDS expands the security coverage of a firewall to analyze traffic against a broader threat database, detecting a variety of sophisticated attacks such as ransomware, data exfiltration, and network scanning based on signatures or “fingerprints” in network traffic.
+
+With Cloudflare's global anycast network, you get:
+
+- Cloudflare's entire global network capacity is now the capacity of your IDS.
+- Built in redundancy and failover. Every server runs Cloudflare's IDS software, and traffic is automatically attracted to the closest network location to its source.
+- Continuous deployment for improvements to Cloudflare's IDS capabilities.
+
+Refer to [Enable IDS](/cloudflare-one/traffic-policies/enable-ids) for more information on enabling IDS and creating new rulesets. After IDS is enabled, your traffic will be scanned to find malicious traffic. The detections are logged to destinations that can be configured from the dashboard. Refer to [Use Logpush with IDS](/magic-firewall/how-to/use-logpush-with-ids/) for instructions on configuring a destination to receive the detections. Additionally, all traffic that is analyzed can be accessed via [network analytics](/analytics/network-analytics/). Refer to [GraphQL Analytics](/magic-firewall/tutorials/graphql-analytics/) to query the analytics data.
diff --git a/src/content/docs/cloudflare-one/traffic-policies/index.mdx b/src/content/docs/cloudflare-one/traffic-policies/index.mdx
index 0cd3225dfbbae06..6cf1854a623acf1 100644
--- a/src/content/docs/cloudflare-one/traffic-policies/index.mdx
+++ b/src/content/docs/cloudflare-one/traffic-policies/index.mdx
@@ -9,6 +9,7 @@ import { Render, Stream } from "~/components";
Cloudflare Gateway, our comprehensive [Secure Web Gateway](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/), allows you to set up policies to inspect DNS, Network, HTTP, and Egress traffic.
+- **Packet filtering** inspect and filter unwanted traffic based on packet attributes. Packet filtering policies block threats regardless of user or session context. Traffic is matched in the order the configured rules.
- **DNS policies** inspect DNS queries. You can block domains and IP addresses from resolving on your devices. For more information on DNS filtering, refer to our [Learning Center article](https://www.cloudflare.com/learning/access-management/what-is-dns-filtering/).
- **Network policies** inspect individual TCP/UDP/GRE packets. You can block access to specific ports on your origin server, including non-HTTP resources.
- **HTTP policies** inspect HTTP requests. You can block specific URLs from loading, not just the domain itself. For more information on URL filtering, refer to our [Learning Center article](https://www.cloudflare.com/learning/access-management/what-is-url-filtering/).
diff --git a/src/content/docs/magic-firewall/how-to/add-rules.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/add-rules.mdx
similarity index 87%
rename from src/content/docs/magic-firewall/how-to/add-rules.mdx
rename to src/content/docs/cloudflare-one/traffic-policies/packet-filtering/add-rules.mdx
index 9ddb400dc10b0f9..a17e52888f6b199 100644
--- a/src/content/docs/magic-firewall/how-to/add-rules.mdx
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/add-rules.mdx
@@ -2,7 +2,7 @@
title: Add rules
pcx_content_type: how-to
sidebar:
- order: 1
+ order: 3
---
@@ -14,11 +14,8 @@ By default, you can create a maximum of 200 rules. We recommend you create lists
## Add a rule
-1. In the Cloudflare dashboard, go to the **Magic Firewall** page.
-
-
-
-2. In the **Custom rules** tab, select **Add a Rule**.
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Firewall policies**.
+2. In the **Packet Filtering** tab, select **Add a policy** > **Add custom policy**.
3. Fill out the information for your new rule. All existing rules apply to IPv4. You can use a managed [IP list](https://www.cloudflare.com/en-gb/ips/) when populating the **Value**.
4. When you are done, select **Add new rule**.
@@ -32,12 +29,9 @@ To disable an existing rule, from the **Magic Firewall Rules** page, set the **E
## Update a rule
-1. In the Cloudflare dashboard, go to the **Magic Firewall** page.
-
-
-
-2. In the **Custom rules** tab, locate the rule you want to edit and select the three dots > **Edit**.
-3. Update the rule with your changes and select **Save rule**.
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Firewall policies**.
+2. In the **Packet Filtering** tab, locate the rule you want to edit and select the three dots > **Edit**.
+3. Update the rule with your changes and select **Save**.
## Delete an existing rule
@@ -143,4 +137,4 @@ curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets \
## Next steps
-Refer to [Form expressions](/magic-firewall/how-to/form-expressions/) for more information on how to write rule expressions.
+Refer to [Form expressions](/cloudflare-one/traffic-policies/packet-filtering/form-expressions/) for more information on how to write rule expressions.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset.mdx
new file mode 100644
index 000000000000000..84d5fca78ae5cb7
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset.mdx
@@ -0,0 +1,148 @@
+---
+title: Extended ruleset
+pcx_content_type: configuration
+sidebar:
+ order: 3
+head:
+ - tag: title
+ content: Extended suggested ruleset
+---
+
+If you are unable to export your current perimeter firewall rules, consider identifying categories of systems or user groups that reside on your Magic Transit prefixes. For example:
+
+- [Endpoints (user devices)](#endpoints-user-devices)
+- [Internal routers](#internal-routerfirewall-ip-addresses)
+- [Web servers](#web-servers)
+- [Non-web servers](#non-web-servers)
+
+For each item above, consider the requirements in terms of their permitted Internet access. For example, permit what is required for legitimate traffic and block the rest.
+
+## Create lists for using Magic Firewall rules
+
+For more information on lists, refer to [Use rule lists](/cloudflare-one/reusable-components/use-rules-list/).
+
+You can also create a list from the dashboard from **Configurations** > **Lists** on your **Account Home**.
+
+## Endpoints (User devices)
+
+Endpoint devices do not operate as servers, which means:
+
+- They receive traffic from standard common ports — for example `80` or `443` — towards their ephemeral ports, above `32768` in modern operating systems (above `1025` in older Windows Server 2003 and Windows XP).
+- Connections flow outwards, not inwards, and therefore do not receive TCP SYN or ACK packets.
+- They typically only need client TCP and UDP, with no requirement for ingress ICMP.
+
+For example, you can create a list for the combination of generic client TCP and client UDP that allows external pings or traceroutes and a catchall rule for all other protocols and traffic.
+
+Create a list named **Endpoints** and specify the list of endpoints or user IP addresses to reference within the rules.
+
+:::note
+Rule 10 in the example ruleset below is acting as a catch-all to block all traffic not permitted in rules 1-3 towards your list of Endpoint IP addresses. If you want to permit other traffic to these destination IP addresses, the new rule must be added before rule 10.
+
+:::
+
+### Suggested rules
+
+**Rule ID**: 1
+**Description**: Endpoints (clients) will receive traffic destined for ephemeral ports. Blocks inbound SYN-only traffic. (meaning SYN-ACKs are permitted)
+**Match**: `ip.proto eq "tcp" and ip.dst in $endpoints and tcp.dstport in {32768..60999} and not (tcp.flags.syn and not tcp.flags.ack)`
+**Action**: Allow
+
+**Rule ID**: 2
+**Description**: Endpoints (clients) will receive traffic destined for ephemeral ports
+**Match**: `ip.proto eq "udp" and ip.dst in $endpoints and udp.dstport in {32768..60999}`
+**Action**: Allow
+
+**Rule ID**: 3
+**Description**: Permits ICMP traffic to destination IP addresses in `$endpoints` list with ICMP Types:
+
+- Type 0 = Echo Reply
+- Type 3 = Destination Unreachable
+- Type 11 = Time Exceeded
+
+**Match**: `ip.proto eq "icmp" and ip.dst in $endpoints and (icmp.type eq 0 or icmp.type eq 3 or icmp.type eq 11)`
+**Action**: Allow
+
+**Rule ID**: 10
+**Description**: Otherwise deny all traffic to IP’s in `$endpoints` list
+**Match**: `ip.dst in $endpoints`
+**Action**: Block
+
+## Internal router/Firewall IP addresses
+
+Follow the best practices for internal routers or firewall interface IP addresses on your MT prefixes below.
+
+1. Create [an IP list](/waf/tools/lists/custom-lists/#ip-lists), **Internal routers** for example, with your IP addresses.
+2. Block ICMP if it is not needed.
+3. Permit GRE/ESP as needed if the devices have GRE/IPsec tunnels via the Internet.
+
+### Suggested rules
+
+**Rule ID**: 1
+**Description**: Permit limited ICMP traffic inbound, including:
+
+- Type 0 - Echo Reply
+- Type 3 - Destination Unreachable
+- Type 8 - Echo
+- Type 11 - Time Exceeded
+
+**Match**: `ip.proto eq "icmp" and ip.dst in $internal_routers and ( (icmp.type eq 0 or icmp.type eq 3) or (icmp.type eq 11) or (icmp.type eq 8) )`
+**Action**: Allow
+
+**Rule ID**: 2
+**Description**: Block all other traffic destined to these IP addresses
+**Match**: `ip.dst in $internal_routers`
+**Action**: Block
+
+## Web Servers
+
+Web servers require careful consideration of necessary traffic flows. Traffic for the **web server** functionality is required in addition to traffic flows where the web server is acting as a client.
+
+Where possible, permit the required destination IP addresses and ports for web servers and block everything else. Additional services, for example NTP/DNS, may be required along with the ports for the web traffic.
+
+The following is an example of suggested rules, but you should only make changes based on your specific requirements. For example, if you are not proxied by Cloudflare Layer 7 protection and you expect traffic sourced from the web towards your web servers:
+
+1. Create [an IP list](/waf/tools/lists/custom-lists/#ip-lists), **web servers** for example, to list IP addresses for your web servers.
+2. Permit traffic for the web server traffic inbound from the Internet.
+3. Permit traffic for the infrastructure or client traffic flows from the Internet, for example DNS and NTP.
+4. Block all other traffic destined for the web server IP addresses.
+
+### Suggested rules
+
+**Rule ID**: 1
+**Description**: Allows inbound HTTP/S traffic from the Internet with SYN-only or ACK-only flag (not SYN/ACKs)
+**Match**: `ip.proto eq "tcp" and tcp.srcport in {32768..60999} and ip.dst in $web_servers and tcp.dstport in {80 443} and not (tcp.flags.syn and tcp.flags.ack)`
+**Action**: Allow
+
+**Rule ID**: 2
+**Description**: Allows UDP replies for DNS and NTP to web servers
+**Match**: `ip.dst in $web_servers and ip.proto eq "udp" and udp.srcport in {53 123} and udp.dstport in {1024..65535}`
+**Action**: Allow if necessary but Disable if under attack
+
+**Rule ID**: 3
+**Description**: Catch-all to block all other traffic destined for web server IP addresses
+**Match**: `ip.dst in $web_servers`
+**Action**: Block
+
+Alternatively, if you have Cloudflare Layer 7 protection, the Cloudflare Public IP addresses can be permitted as the source IP addresses to the destination IP addresses for the HTTP/HTTPS inbound traffic. This recommendation effectively replaces Rule 1 in the example above.
+
+For a list of Cloudflare's IP addresses, refer to [Cloudflare's IP addresses](https://www.cloudflare.com/ips/).
+
+### Suggested rules for Cloudflare proxied traffic
+
+**Description**: Allow inbound HTTP/S traffic from Cloudflare with SYN or ACK
+**Match**: `ip.proto eq "tcp" and ip.dst in $web_servers and tcp.dstport in {80 443} and not (tcp.flags.syn and tcp.flags.ack) and ip.src in {173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22}`
+**Action**: Allow
+
+## Non-web servers
+
+Restrict the source based on whether the server is expecting traffic from the general Internet or from only specific users.
+
+1. Apply rules based on source IP or ports if possible.
+2. Restrict permitted destination ports to only those that are required.
+3. Block incoming SYN to the closed ports.
+
+### Suggested rules
+
+- `IP Destination Address { non-web server } and TCP dst port in \ — Permit`
+- `IP Destination Address { non-web server } and UDP dst port in \ — Permit`
+- `IP Destination Address { web server } — Block`
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/index.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/index.mdx
new file mode 100644
index 000000000000000..0caefecfebbbca6
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/index.mdx
@@ -0,0 +1,15 @@
+---
+title: Best practices
+pcx_content_type: concept
+sidebar:
+ order: 10
+
+---
+
+import { DirectoryListing } from "~/components"
+
+By default, Magic Firewall permits all ingress traffic that has passed through Cloudflare's core DDoS mitigations. To proactively mitigate attacks and minimize your attack surface and leakage of attack traffic into your environment, we recommend implementing your Magic Firewall rules using the following guidelines.
+
+The best approach is to replicate your current ingress perimeter firewall rules in Magic Firewall. If you are unable to export your current perimeter firewall rules, contact your Implementation Manager for help translating the rules into Magic Firewall rules.
+
+
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/magic-transit-egress.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/magic-transit-egress.mdx
new file mode 100644
index 000000000000000..9d7d8587c3edcf5
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/magic-transit-egress.mdx
@@ -0,0 +1,16 @@
+---
+pcx_content_type: concept
+title: Magic Transit egress
+sidebar:
+ order: 4
+
+---
+
+The suggestions in the [Minimal ruleset](/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset) and [Extended ruleset](/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset) are recommendations for ingress traffic.
+
+For Magic Transit egress traffic, consider the following information:
+
+* The Magic Firewall rules will apply to both Magic Transit ingress and egress traffic passing via Cloudflare.
+* Magic Firewall is not stateful for your Magic Transit egress traffic.
+* Magic Firewall is not stateful in both directions after DDoS mitigations.
+* If you have a Magic Firewall "default drop" catchall rule for ingress traffic, you will need to add an earlier rule to permit traffic sourced from your Magic Transit prefix with the destination as **any** to allow outbound egress traffic.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset.mdx
new file mode 100644
index 000000000000000..e272b7c8133b3be
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset.mdx
@@ -0,0 +1,74 @@
+---
+title: Minimal ruleset
+pcx_content_type: configuration
+sidebar:
+ order: 2
+head:
+ - tag: title
+ content: Minimal suggested ruleset
+---
+
+The suggested minimal ruleset blocks some known common vectors for DDoS attacks and permits all other ESP, TCP, UDP, GRE and ICMP traffic.
+
+This is a suggested list and not an exhaustive list. Review your environment and add more rules as necessary.
+
+## Recommended rules
+
+**Rule ID**: 1
+**Description**: Single rule that blocks all traffic with UDP source ports which are used in attacks or invalid in Magic Transit ingress.
+**Match**: `(udp.srcport in {1900 11211 389 111 19 1194 3702 10001 20800 161 162 137 27005 520 0})`
+**Action**: Block
+
+**Rule ID**: 2
+**Description**: Blocks TCP traffic with source port `0` and common ports used in TCP SYN/ACK reflection attacks.
+**Match**: `(tcp.srcport in {21 0 3306})`
+**Action**: Block
+
+**Rule ID**: 3
+**Description**: Blocks HOPOPT (protocol 0) or else blocks if protocol not in `{ESP, TCP, UDP, GRE, ICMP}`. Note that this is only an example. Permit the relevant protocols for your environment.
+**Match**: `(ip.proto eq "hopopt") or (not ip.proto in {"esp" "tcp" "udp" "gre" "icmp"})`
+**Action**: Block
+
+## Traffic and port types
+
+The information below covers traffic type, how the port is used, and reasons for blocking the port.
+
+| Traffic | Port use | Reason to block |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
+| UDP source port `0` | Reserved port. Should not be used by applications. | Invalid as a legitimate traffic source port. Commonly used in DDoS attacks. |
+| UDP source port `1900` | Simple Service Discovery Protocol (SSDP). Allows universal plug and play devices to send and receive information. | [SSDP DDoS attacks](https://www.cloudflare.com/learning/ddos/ssdp-ddos-attack/) exploit Universal Plug and Play protocols. |
+| UDP source port `11211` | Memcached. A database caching system designed to speed up websites and networks. | [Memcached DDoS Attacks](https://www.cloudflare.com/learning/ddos/memcached-ddos-attack/). |
+| UDP source port `389` | Connection-less Lightweight Directory Access Protocol (CLDAP). | [Used in reflection attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
+| UDP source port `111` | SunRPC | Common attack vector. [Used in reflection attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
+| UDP source port `19` | CHARGEN | [Amplification attack vector](https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/). |
+| UDP source port `1194` | OpenVPN | Unless this is an authorized VPN in your environment, this common VPN should be blocked. |
+| UDP source port `3702` | Web Services Dynamic Discovery Multicast discovery protocol (WS-Discovery) | Vulnerable to exploiting for DDoS attacks. |
+| UDP source port `10001` | Ubiquiti UniFi discovery protocol | Ubiquiti devices were exploited and used to conduct DDoS attacks on this port. |
+| UDP source port `20800` | Call of Duty | [Commonly used in attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
+| UDP source ports `161` and `162` | SNMP | Vulnerable to exploiting for DDoS attacks. |
+| UDP source port `137` | NetBIOS | NetBIOS allows file sharing over networks. If configured improperly, can expose file systems. |
+| UDP source port `27005` | SRCDS | Used in [amplication attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
+| UDP source port `520` | Routing Information Protocol (RIP) | Internal routing protocol. Not required on Internet WAN access. |
+| TCP source port `0` | Reserved port. Should not be used by applications. | Commonly used in DDoS attacks. Invalid as a legitimate traffic source port. |
+| TCP source port `0` | FTP | Commonly used for attacks. |
+| TCP source port `3306` | MYSQL open source database | Used as attack vector in DDoS attacks. |
+
+## Other common traffic to consider
+
+The list below is a common list of traffic types you should also consider blocking or restricting inbound.
+
+* SFTP, TFTP
+* SSH, Telnet
+* RDP
+* RCP
+* SMCP
+* NTP
+ * Common vector for reflection attacks. Consider using [Cloudflare Gateway](/web3/), [1.1.1.1's DNS over HTTPS (DoH)](/1.1.1.1/), or an internal DNS service if possible. Consider restricting your firewall rules to only allow the source and destination of DNS traffic.
+* MS-SQL
+ * Common vector and [increasingly used as vector for DDoS attacks](https://blog.cloudflare.com/ddos-attack-trends-for-2021-q4/). Block if unused or consider restricting only to the required source IP addresses.
+* HTTP and HTTPS
+ * If you only have servers on your Magic Transit prefixes, consider blocking ingress traffic on TCP source ports 80 and 443 from outside. If you have endpoints on your Magic Transit prefixes, you can allow traffic on the source ports but consider creating a disabled rule you can activate to respond to reflection attacks as needed.
+
+If relevant to your environment, consider blocking based on geolocation data, which blocks traffic based on the country or user when an end user's IP address is registered in the geolocation database.
+
+If you are interested in participating in the beta for [Session Initiation Protocol (SIP) Validation](https://blog.cloudflare.com/programmable-packet-filtering-with-magic-firewall/), contact your Implementation Manager.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/create-rate-limiting-rules.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/create-rate-limiting-rules.mdx
new file mode 100644
index 000000000000000..0d70528e8d882fb
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/create-rate-limiting-rules.mdx
@@ -0,0 +1,47 @@
+---
+pcx_content_type: how-to
+title: Create Rate Limiting rules (beta)
+sidebar:
+ label: Create Rate Limiting rules
+ badge:
+ text: Beta
+ order: 4
+---
+
+import { DashButton } from "~/components";
+
+Rate limiting rules (beta) allow you to manage incoming traffic to your network for specific locations.
+
+This guide will teach you how to create a rule for when incoming packets match, and in cases where your rate exceeds a certain value (in packets or bits).
+
+:::note
+For Advanced Magic Firewall customers, rate limiting (beta) is available by request through the account team.
+:::
+
+## Add a rule
+
+To add a rule:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Packet filtering**.
+2. Select **Add a policy** > **Add rate limiting policy**.
+3. Fill out the information for your new rule:
+ - Select the **Field**: At the moment, you can only choose a [colo name](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/magic-firewall/).
+ - Select the **Operator**: Choose among **equals** or **is in**.
+ - Select the **Value**.
+4. When you are done, select **Add new rule**.
+
+## Edit an existing rule
+
+To edit a rule:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Packet filtering**.
+2. Locate the rule you want to edit in the list and select **View**.
+3. Edit the rule with your changes and select **Add new rule**.
+
+## Delete an existing rule
+
+To delete an existing rule:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Packet filtering**.
+2. Locate the rule you want to edit in the list and select **Delete**.
+3. Select **Delete** again to confirm deletion.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/enable-managed-rulesets.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/enable-managed-rulesets.mdx
new file mode 100644
index 000000000000000..a5eb86a40f0114d
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/enable-managed-rulesets.mdx
@@ -0,0 +1,161 @@
+---
+title: Enable Managed Rulesets
+pcx_content_type: how-to
+sidebar:
+ order: 5
+---
+
+import { DashButton } from "~/components";
+
+With [managed rulesets](/ruleset-engine/managed-rulesets/), you can quickly deploy rules maintained by Cloudflare, and you can use Magic Firewall to control which rules are enabled.
+
+:::note[Note:]
+Before you can begin using managed rulesets with Magic Firewall, your account must first be entitled to use managed rulesets. Contact your account team for access.
+:::
+
+To enable or disable a rule, you can specify which properties should be overridden. The overrides occur in the Managed phase, root kind ruleset. Currently, you can only have one rule in the root ruleset, but a single rule can contain multiple overrides.
+
+You have multiple options for enabling rules:
+
+* Select an individual rule and enable it.
+* Enable multiple rules by enabling by category in the `magic-transit-phase`.
+* Enable an entire ruleset.
+
+## API
+
+### 1. Create a Managed phase Managed kind ruleset
+
+To create a managed ruleset, you must first build a request with the following:
+
+* `managed_ruleset_id`: The ID of the Managed phase Managed kind ruleset that contains the rule you want to enable.
+* `managed_rule_id`: The ID of the rule you want to enable.
+
+Additionally, you need the properties you want to override. The properties you can override include:
+
+* `enabled`: This value can be set to `true` or `false`. When set to `true`, the rule matches packets and applies the rule's default action if the action is not overridden. When set to `false`, the rule is disabled and does not match any packets.
+* `action`: The value can be set to `log` so the rule only produces logs instead of applying the rule's default action.
+
+The `enabled` and `action` properties for a rule are set in the Managed phase Managed kind ruleset. All rules in the Managed phase are currently disabled by default.
+
+The example below contains a request for a Managed phase Managed Kind ruleset.
+
+```bash title="Example request - Create a Managed phase Managed Kind ruleset"
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "name": "execute ruleset",
+ "description": "Ruleset containing execute rules",
+ "kind": "root",
+ "phase": "magic_transit_managed",
+ "rules": [
+ {
+ "expression": "true",
+ "action": "execute",
+ "description": "Enable one rule ",
+ "action_parameters": {
+ "id": "",
+ "version": "latest",
+ "overrides": {
+ "rules": [
+ {
+ "id": "",
+ "enabled": true,
+ "action": "log"
+ }
+ ]
+ }
+ }
+ }
+ ]
+}'
+```
+
+### 2. Patch a Managed phase Managed kind ruleset
+
+To ensure a root kind ruleset only contains one rule, patch the rule to enable new managed rules.
+
+Building off the example from the previous step, the example below enables a category to select multiple rules instead of a single rule. The category will be set to `log` mode, which means the rule can produce logs but will not accept or drop packets.
+
+```bash title="Example request - Patch a Managed phase Managed kind ruleset"
+curl --request PATCH \
+https://api.cloudflare.com/client/v4/accounts/{account_id}/rulesets/{root_kind_ruleset}/rules/{root_kind_rule} \
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "expression": "true",
+ "action": "execute",
+ "action_parameters": {
+ "id": "",
+ "version": "latest",
+ "overrides": {
+ "rules": [
+ {
+ "id": "",
+ "enabled": true
+ }
+ ],
+ "categories": [
+ {
+ "category": "simple",
+ "enabled": true,
+ "action": "log"
+ }
+ ]
+ }
+ }
+}'
+```
+
+### 3. Enable all rules
+
+To enable the complete ruleset or enable all rules, send the request below.
+
+```bash title="Example request to enable all rules"
+curl --request PATCH \
+https://api.cloudflare.com/client/v4/accounts/{account_id}{account_id}/rulesets/{root_kind_ruleset}/rules/{root_kind_rule} \
+--header "Authorization: Bearer " \
+--header "Content-Type: application/json" \
+--data '{
+ "expression": "true",
+ "action": "execute",
+ "action_parameters": {
+ "id": "",
+ "version": "latest",
+ "overrides": {
+ "enabled": true
+ }
+ }
+}'
+```
+
+### 4. Delete a ruleset
+
+To delete a ruleset, refer to [Delete a rule in a ruleset](/ruleset-engine/rulesets-api/delete-rule/).
+
+## Cloudflare dashboard
+
+### Enable rules
+
+You can also use the dashboard to enable managed rulesets:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Firewall policies**.
+2. Select **Packet filtering** and go to **Managed**. This is where the dashboard lists all your managed rules.
+3. To enable a rule, turn **Status** on.
+
+## Edit rules
+
+To edit a rule:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Firewall policies**.
+2. Select **Packet filtering** and go to **Managed**. This is where the dashboard lists all your managed rules.
+3. Select the three dots > **Edit**.
+4. Make the necessary changes, then select **Save**.
+
+## View rules
+
+To view basic information about your rules:
+
+1. In the [Cloudflare One](https://one.dash.cloudflare.com) dashboard, go to **Traffic policies** > **Firewall policies**.
+2. Select **Packet filtering** and go to **Managed**. This is where the dashboard lists all your managed rules.
+3. Locate your managed rule, select the three dots > **View**.
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/form-expressions.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/form-expressions.mdx
new file mode 100644
index 000000000000000..425f87b5761ea84
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/form-expressions.mdx
@@ -0,0 +1,47 @@
+---
+title: Form expressions
+pcx_content_type: concept
+sidebar:
+ order: 6
+head:
+ - tag: title
+ content: Form an expression
+
+---
+
+import { GlossaryTooltip } from "~/components"
+
+Rules are written as using the Cloudflare Rules language - a domain-specific language (DSL) intended to mimic Wireshark semantics. For more information, refer to the [Rules language](/ruleset-engine/rules-language/) documentation.
+
+To start with a simple case, review below how you would match a source IP:
+
+```txt
+ip.src == 192.0.2.0
+```
+
+Expressions can be more complex by joining multiple clauses via a logical operator:
+
+```txt
+ip.src == 192.0.2.1 && (tcp.flags.push || tcp.flags.reset)
+```
+
+## Capabilities
+
+You can use Magic Firewall to skip or block packets based on source or destination IP, source or destination port, protocol, packet length, or bit field match.
+
+## Restrictions
+
+Wirefilter comparisons support CIDR notation, but only inside sets. For example:
+
+```txt
+ip.src == 192.0.2.0/24 # bad
+ip.src in { 192.0.2.0/24 } # good
+```
+
+Expressions have a complexity limit that is easily reached when many joined or nested clauses are in the expression. Here's an example:
+
+```txt
+(tcp.dstport == 1000 || tcp.dstport == 1001) && (tcp.dstport == 1002 || tcp.dstport == 1003) && (tcp.dstport == 1004 || tcp.dstport == 1005) && (tcp.dstport == 1006 || tcp.dstport == 1007) && (tcp.dstport == 1008 || tcp.dstport == 1009) && (tcp.dstport == 1010 || tcp.dstport == 1011) && (tcp.dstport == 1012 || tcp.dstport == 1013) && (tcp.dstport == 1014 || tcp.dstport == 1015) && (tcp.dstport == 1016 || tcp.dstport == 1017)
+```
+
+If the limit is reached, the response will have a `400` status code and an error message of `ruleset exceeds complexity constraints`. Split the expression into multiple rules and try again.
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/index.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/index.mdx
new file mode 100644
index 000000000000000..164cd49cb231371
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/index.mdx
@@ -0,0 +1,8 @@
+---
+pcx_content_type: configuration
+title: Packet filtering
+sidebar:
+ order: 1
+ group:
+ hideIndex: true
+---
\ No newline at end of file
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/magic-firewall-overview.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/magic-firewall-overview.mdx
new file mode 100644
index 000000000000000..22be314acacb894
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/magic-firewall-overview.mdx
@@ -0,0 +1,43 @@
+---
+title: Overview
+pcx_content_type: overview
+sidebar:
+ order: 2
+head:
+ - tag: title
+ content: Overview
+---
+
+import { Description, Feature, GlossaryTooltip, Plan, RelatedProduct } from "~/components"
+
+
+Protect your cloud infrastructure or network offices with advanced, scalable firewall-as-a-service protection.
+
+
+
+
+Magic Firewall is a firewall-as-a-service (FWaaS) delivered from the Cloudflare global network to protect office networks and cloud infrastructure with advanced, scalable protection. With Magic Firewall, you can apply filter rules on a variety of criteria, such as protocol and packet length, to filter unwanted traffic before it reaches your network.
+
+Magic Firewall uses Wireshark syntax, a domain-specific language (DSL) common in the networking world and the same syntax used across our other products. With this syntax, you can easily craft powerful rules to precisely allow or deny any traffic in or out of your network.
+
+Magic Firewall is available with the purchase of [Magic Transit](/magic-transit/) or [Magic WAN](/magic-wan/).
+
+***
+
+## Features
+
+
+Actively monitor for a wide range of known threat signatures in your traffic.
+
+
+***
+
+## Related products
+
+
+Secure your network from incoming Internet traffic, and improve performance at Cloudflare scale.
+
+
+
+Improve security and performance for your entire corporate networking, reducing cost and operation complexity.
+
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/protocol-validation-rules.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/protocol-validation-rules.mdx
new file mode 100644
index 000000000000000..c4fd4b03663c631
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/protocol-validation-rules.mdx
@@ -0,0 +1,12 @@
+---
+title: Protocol validation rules
+pcx_content_type: concept
+sidebar:
+ order: 7
+---
+
+Magic Firewall supports [Session Initiation Protocol (SIP)](https://datatracker.ietf.org/doc/html/rfc2543) to inspect traffic validity and enforce a positive security model.
+
+You can use the `sip` field when creating a rule to determine if packets are valid SIP Layer 7 (L7) protocol. Refer to [Magic Firewall fields](/cloudflare-one/reusable-components/packet-filtering-fields/), specifically the `sip` field, for more information on this topic.
+
+Contact your account manager if you need Magic Firewall to support additional protocols.
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/ruleset-logic.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/ruleset-logic.mdx
new file mode 100644
index 000000000000000..de3d897b0ecbb5e
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/ruleset-logic.mdx
@@ -0,0 +1,50 @@
+---
+title: Ruleset logic
+pcx_content_type: concept
+sidebar:
+ order: 8
+---
+
+import { GlossaryTooltip } from "~/components"
+
+Magic Firewall rules are performed after Cloudflare's DDoS mitigations have been applied. The two systems are independent, and therefore, permitting traffic inside Magic Firewall does not allow it within our DDoS mitigations. Traffic can still be blocked by DDoS mitigations that are applied first in the flow through Cloudflare's systems.
+
+By default, Magic Firewall policies allow all traffic until explicitly blocked by a rule. If no policy is configured, all traffic is permitted after Cloudflare's DDoS mitigations have been applied.
+
+## Security policy
+
+You have two options for configuring a security policy:
+
+* Enforce a positive security model and only permit required traffic and block everything else.
+* Begin with a minimal ruleset to block specific traffic and, by default, everything else is permitted.
+
+Traffic is matched in order of the configured rules. As soon as traffic is matched by an enabled rule, it is no longer validated against the later rules, and traffic will pass through disabled rules. In the dashboard under **Traffic policies** > **Magic Firewall**, rule order begins from the top and flows down your list of rules.
+
+For example, permitting all TCP traffic in a rule #4 would mean all TCP traffic is permitted. A rule #5 to block traffic for IP address `x.x.x.x` would not be checked.
+
+For best practices when configuring your security policy, refer to [Best practices](/magic-firewall/best-practices/).
+
+## Packet filtering policies and Magic Transit endpoint health checks
+
+Cloudflare-sourced traffic is also subject to the Magic Firewall rules you configure. If you block all ICMP traffic, you will also block Cloudflare's endpoint health checks. When blocking ICMP traffic, ensure your rules first allow ICMP sourced from Cloudflare public IPs to your prefix endpoint IPs before applying a block ICMP rule.
+
+For a list of Cloudflare's public IPs, refer to [IP Ranges](https://www.cloudflare.com/ips/).
+
+## Magic Firewall phases
+
+Magic Firewall processes traffic in two phases: in the first phase, Magic Firewall policies match packets against rules in the Custom phase. In the second phase, Magic Firewall match packets against rules in the Managed phase.
+
+### Custom phase ruleset
+
+Custom phase is a set of rules defined by the user. The expression, order, and actions of those rules can be customized by the user.
+
+Additionally, users can add a rule in this custom phase to override the behavior of a rule in the Managed phase.
+
+### Managed phase ruleset
+
+Managed phase rulesets are updated and maintained by Cloudflare, and Cloudflare creates these rules based on best practices, known malicious patterns, and other criteria.
+
+Cloudflare maintains the expressions and order of execution for rules in the Managed phase. Rules
+can be enabled, disabled, or made to log matching packets.
+
+Refer to [Enable managed rulesets](/cloudflare-one/traffic-policies/packet-filtering/enable-managed-rulesets/) for more information.
diff --git a/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/traffic-types.mdx b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/traffic-types.mdx
new file mode 100644
index 000000000000000..2cd3ddbcfb132c0
--- /dev/null
+++ b/src/content/docs/cloudflare-one/traffic-policies/packet-filtering/traffic-types.mdx
@@ -0,0 +1,14 @@
+---
+title: Traffic types
+pcx_content_type: concept
+sidebar:
+ order: 9
+---
+
+import { GlossaryTooltip } from "~/components"
+
+Magic Firewall enables you to allow or block traffic on a variety of packet characteristics, such as source and destination IP, source and destination port, protocol, packet length, and bit field match.
+
+Magic Firewall supports layers three and four — network and transport — protocols such as TCP, UDP, and ICMP. Any type of layer three or four protocols can go through Magic Firewall and then be matched on those protocols.
+
+To view the list of available fields, refer to [Magic Firewall fields](/magic-firewall/reference/magic-firewall-fields/).
diff --git a/src/content/docs/cloudflare-one/tutorials/graphql-analytics.mdx b/src/content/docs/cloudflare-one/tutorials/graphql-analytics.mdx
new file mode 100644
index 000000000000000..eb71350e18cb710
--- /dev/null
+++ b/src/content/docs/cloudflare-one/tutorials/graphql-analytics.mdx
@@ -0,0 +1,182 @@
+---
+title: GraphQL Analytics
+pcx_content_type: tutorial
+tags:
+ - GraphQL
+sidebar:
+ order: 1
+head:
+ - tag: title
+ content: GraphQL Analytics
+reviewed: 2022-03-02
+difficulty: Medium
+description: >-
+ Use the GraphQL Analytics API to review data for Magic Firewall network traffic related to rules matching your traffic.
+---
+
+import { DashButton } from "~/components";
+
+Use the GraphQL Analytics API to review data for Magic Firewall network traffic related to rules matching your traffic. This contains both rules you configured in the Magic Firewall dashboard, and the rules managed by Cloudflare as a part of [Magic Firewall Managed rules](/magic-firewall/how-to/enable-managed-rulesets/) and [Magic Firewall IDS](/magic-firewall/about/ids/) features.
+
+Before you begin, you must have an [API token](/analytics/graphql-api/getting-started/authentication/). For additional help getting started with GraphQL Analytics, refer to [GraphQL Analytics API](/analytics/graphql-api/).
+
+## Obtain Cloudflare Account ID
+
+To construct a Magic Firewall GraphQL query for an object, you will need a Cloudflare Account ID
+
+### Obtain your Cloudflare Account ID
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/), and select your account.
+2. The URL in your browser's address bar should show `https://dash.cloudflare.com/` followed by a hex string. The hex string is your Cloudflare Account ID.
+
+### Obtain the rule ID for a firewall rule
+
+To construct queries to gather analytics for a particular rule, you need the rule ID for each firewall rule.
+
+1. In the Cloudflare dashboard, go to the **Magic Firewall** page.
+
+
+
+2. In the **Custom rules** tab, locate the rule you need the rule ID for from the list and select the three dots > **Edit**.
+3. Locate the **Rule ID** and select the copy button.
+4. Select **Cancel** to return to the **Magic Firewall** page.
+
+## Explore GraphQL schema with Magic Firewall query example
+
+In this section, you will run a test query to retrieve a five minute count of all configured Magic Firewall rules within five minute intervals. You can copy and paste the code below into GraphiQL.
+
+For additional information about the Analytics schema, refer to [Explore the Analytics schema with GraphiQL](/analytics/graphql-api/getting-started/explore-graphql-schema/).
+
+```graphql graphql-api-explorer
+query MagicFirewallExample($accountTag: string!, $start: Time, $end: Time) {
+ viewer {
+ accounts(filter: { accountTag: $accountTag }) {
+ magicFirewallSamplesAdaptiveGroups(
+ filter: { datetime_geq: $start, datetime_leq: $end }
+ limit: 2
+ orderBy: [datetimeFiveMinute_DESC]
+ ) {
+ sum {
+ bits
+ packets
+ }
+ dimensions {
+ datetimeFiveMinute
+ ruleId
+ }
+ }
+ }
+ }
+}
+```
+
+## Example queries for Magic Firewall
+
+### Obtain analytics for a specific rule
+
+Use the example below to display the total number of packets and bits for the top ten suspected malicious traffic streams within the last hour. After receiving the results, you can sort by packet rates with a five minute average.
+
+For each stream, display the:
+
+- Source and destination IP addresses
+- Ingress Cloudflare data centers that received it
+- Total traffic volume in bits and packets received within the hour
+- Actions taken by the firewall rule
+
+```graphql graphql-api-explorer
+query MagicFirewallObtainRules(
+ $accountId: string!
+ $ruleId: string
+ $start: Time
+ $end: Time
+) {
+ viewer {
+ accounts(filter: { accountTag: $accountId }) {
+ magicFirewallNetworkAnalyticsAdaptiveGroups(
+ filter: { ruleId: $ruleId, datetime_geq: $start, datetime_leq: $end }
+ limit: 10
+ orderBy: [avg_packetRateFiveMinutes_DESC]
+ ) {
+ sum {
+ bits
+ packets
+ }
+ dimensions {
+ coloCity
+ ipDestinationAddress
+ ipSourceAddress
+ outcome
+ }
+ }
+ }
+ }
+}
+```
+
+### Obtain IDS analytics
+
+Use the example below to display the total number of packets and bits for the top 10 traffic streams that Magic Firewall IDS has detected in the last hour.
+
+By setting `verdict` to `drop` and `outcome` as `pass`, we are filtering for traffic that was marked as a detection (i.e. verdict was drop) but was not dropped (for example, outcome was `pass`). This is because currently, Magic Firewall IDS only detects malicious traffic but does not drop the traffic.
+
+For each stream, display the:
+
+- Source and destination IP addresses.
+- Ingress Cloudflare data centers that received it.
+- Total traffic volume in bits and packets received within the hour.
+
+```graphql graphql-api-explorer
+query MagicFirewallObtainIDS($accountTag: string!, $start: Time, $end: Time) {
+ viewer {
+ accounts(filter: { accountTag: $accountTag }) {
+ magicIDPSNetworkAnalyticsAdaptiveGroups(
+ filter: {
+ datetime_geq: $start
+ datetime_leq: $end
+ verdict: drop
+ outcome: pass
+ }
+ limit: 10
+ orderBy: [avg_packetRateFiveMinutes_DESC]
+ ) {
+ sum {
+ bits
+ packets
+ }
+ dimensions {
+ coloCity
+ ipDestinationAddress
+ ipSourceAddress
+ }
+ }
+ }
+ }
+}
+```
+
+Alternatively, to inspect all traffic that was analyzed, but grouped into malicious traffic and other traffic, the example below can be used. The response will contain two entries for each five minute timestamp. `verdict` will be set to `drop` for malicious traffic, and `verdict` will be set to `pass` for traffic that did not match any of the IDS rules.
+
+```graphql graphql-api-explorer
+query MagicFirewallTraffic($accountTag: string!, $start: Time, $end: Time) {
+ viewer {
+ accounts(filter: { accountTag: $accountTag }) {
+ magicIDPSNetworkAnalyticsAdaptiveGroups(
+ filter: { datetime_geq: $start, datetime_leq: $end }
+ limit: 10
+ orderBy: [avg_packetRateFiveMinutes_DESC]
+ ) {
+ sum {
+ bits
+ packets
+ }
+ dimensions {
+ coloCity
+ ipDestinationAddress
+ ipSourceAddress
+ verdict
+ }
+ }
+ }
+ }
+}
+```
diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx
index 023baa0084188d0..31546b14248cc71 100644
--- a/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx
+++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx
@@ -106,7 +106,7 @@ A false negative is a lack of identification. In the case of DDoS protection, th
To address a false negative:
- If you are a WAF/CDN customer, follow the steps in the [Respond to DDoS attacks](/ddos-protection/best-practices/respond-to-ddos-attacks/) page, which guides you on enabling the _Under Attack_ mode and creating rate limiting rules and WAF custom rules as needed.
-- If you are a Magic Transit customer, [use Magic Firewall rules](/magic-firewall/how-to/add-rules/) to help mitigate the attack.
+- If you are a Magic Transit customer, [use Magic Firewall rules](/cloudflare-one/traffic-policies/packet-filtering/add-rules/) to help mitigate the attack.
### Incomplete mitigations
diff --git a/src/content/docs/magic-firewall/about/list-types.mdx b/src/content/docs/magic-firewall/about/list-types.mdx
index f7fa55a7dfe60f6..97a95228d05f0b2 100644
--- a/src/content/docs/magic-firewall/about/list-types.mdx
+++ b/src/content/docs/magic-firewall/about/list-types.mdx
@@ -11,8 +11,8 @@ The threat intelligence feed categories are described in [Managed IP Lists](/waf
## IP lists
-Use [IP lists](/waf/tools/lists/custom-lists/#ip-lists) to group services in networks, like web servers, or for lists of known bad IP addresses to make managing good network endpoints easier. IP lists are helpful for users with very expansive firewall rules with many IP lists. By default, you can add up to 10,000 IPs across all lists. Refer to [Use an IP list](/magic-firewall/how-to/add-rules/#use-an-ip-list) to check an example of how to use an IP list.
+Use [IP lists](/waf/tools/lists/custom-lists/#ip-lists) to group services in networks, like web servers, or for lists of known bad IP addresses to make managing good network endpoints easier. IP lists are helpful for users with very expansive firewall rules with many IP lists. By default, you can add up to 10,000 IPs across all lists. Refer to [Use an IP list](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#use-an-ip-list) to check an example of how to use an IP list.
## Geo-blocking
-Geo-blocking enables you to selectively allow or block traffic to any country. Refer to [Block a country](/magic-firewall/how-to/add-rules/#block-a-country) to check an example of how to block a country.
+Geo-blocking enables you to selectively allow or block traffic to any country. Refer to [Block a country](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#block-a-country) to check an example of how to block a country.
diff --git a/src/content/docs/ruleset-engine/reference/phases-list.mdx b/src/content/docs/ruleset-engine/reference/phases-list.mdx
index f71353deb83fb2a..d453cfa47908619 100644
--- a/src/content/docs/ruleset-engine/reference/phases-list.mdx
+++ b/src/content/docs/ruleset-engine/reference/phases-list.mdx
@@ -16,7 +16,7 @@ The following tables list the [phases](/ruleset-engine/about/phases/) of Cloudfl
| Phase name | Used in product/feature |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `ddos_l4` | [Network-layer DDoS Attack Protection](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/) |
-| `magic_transit` | [Magic Firewall](/magic-firewall/how-to/add-rules/) |
+| `magic_transit` | [Magic Firewall](/cloudflare-one/traffic-policies/packet-filtering/add-rules/) |
| `magic_transit_managed` | [Magic Firewall managed rulesets](/magic-firewall/how-to/enable-managed-rulesets/) |
| `magic_transit_ratelimit` | [Magic Firewall rate limiting rules](/magic-firewall/how-to/create-rate-limiting-rules/) |
| `magic_transit_ids_managed` | [Magic Firewall Intrusion Detection System (IDS)](/magic-firewall/about/ids/) |