Creating a Secure Network Environment with Soracom VPG F2 and AWS Network Firewall

Written by: Taketo Matsunaga Published: March 7, 2025 IoT Advice

Tags: cellular IoT | Iot Security | Monitoring | Security | Soracom VPG

Domain filtering, AKA DNS filtering, is a reputation filtering technique that allows managers to control the traffic that moves in and out of their networks. This allows administrators to create and manage lists of fully qualified domain names and control their inbound and outbound access to the network.

In this article, we will explore how to improve the security of your deployment via domain filtering by utilizing Amazon Web Services’ (AWS) Network Firewall in conjunction with Soracom’s recently released Virtual Private Gateway (VPG) Type-F2.

Validation Overview:

In the following example, we will create a system that permits HTTP/HTTPS access from devices to specific domains while blocking all other traffic using Soracom’s new VPG Type-F2. 

Unlike the traditional VPG Type-F, Type-F2 enables routing configuration for device-originated packets. This allows users to forward the default route (0.0.0.0/0) to their Virtual Private Cloud (VPC). This flexibility enables various network configurations, but may also make it necessary to restrict traffic from certain sources for security purposes.

To this end, we will use AWS Network Firewall as a firewall service.

While internet traffic typically passes through the VPG’s internet gateway, in this instance we will use the VPC’s Transit Gateway to route traffic through the firewall.

What is AWS Network Firewall?

AWS Network Firewall is a managed network firewall service provided by AWS. It is commonly used to protect and control traffic within a VPC. In our example, we will apply the traffic filtering to traffic coming from IoT devices.

Rule Groups and Verification Details

AWS Network Firewall uses rule groups as the mechanism for traffic control, which are categorized into two types:

1. Stateless Rule Groups:
   These use a stateless rule engine to inspect individual packets independently, without considering the direction of the traffic.
2. Stateful Rule Groups:
   These use a stateful rule engine to evaluate not just individual packets but the entire traffic flow. Once a traffic flow is dropped, no other rules are applied to that flow.

For this example, we will use a stateful domain list rule group to permit communication solely with specific domains over HTTP/HTTPS.

Stateful rules are necessary for TCP-based communications like HTTP/HTTPS because they use random ephemeral ports on the client side. This means filtering only ports :80 or :443 is insufficient and return paths must also be filtered. 

Architecture Overview

Here is an overview of the architecture and routing paths of the example implementation:

Subnet Design

In this scenario, we have defined three subnets: the Private Subnet, Firewall Subnet, and Public Subnet. The Firewall Subnet exists because AWS Network Firewall requires the creation of a dedicated subnet. While no servers are needed, the service itself is hosted within this subnet

Use of NAT Gateway

As we already mentioned, the IoT devices in this example are configured to access the internet via the AWS VPC.

According to AWS’s official documentation Enable VPC internet access using internet gateways; “… resources on the internet can initiate a connection to resources in your subnet using the public IPv4 address or IPv6 address.” When using an AWS Internet Gateway, the source IP address must fall within the VPC’s address range.

However, for IoT device traffic routed through VPG Type-F2, the source IP address will be within the devices’ IP address range, which may not match the VPC address range. As a result, if this traffic attempts to pass directly through the VPC Internet Gateway, it will be rejected.

This is where the NAT Gateway comes into play. This service allows traffic to reach the internet regardless of the source IP address, making it essential for the architecture in this implementation.

AWS Network Firewall and Routing

The key point in routing configuration is that both outgoing and incoming packets must pass through the AWS Network Firewall. If asymmetric routing (i.e. where the outgoing and return paths differ) occurs, routing will not function as expected, leading to issues.

Referring to the routing table shown in the architecture diagram, the route for outbound traffic from the device destined for 0.0.0.0/0 is:

• Device → VPG Type-F2 → Transit Gateway → Private Subnet → AWS Network Firewall Endpoint → Firewall Subnet → NAT Gateway

For inbound traffic from the internet to the device, follow the route for the transmission address 10.128.0.0/9 shown in the architecture diagram:

• Public Subnet → AWS Network Firewall Endpoint → Firewall Subnet → Transit Gateway → VPG Type-F2 → Device

Note that the return path must pass through the Public Subnet and the AWS Network Firewall Endpoint. If this is not configured, asymmetric routing will occur, and the return packets will bypass the AWS Network Firewall, resulting in uncontrolled traffic.

AWS Network Firewall Policies and Group Settings

Let’s take a look at how to configure AWS Network Firewall.

There are various ways to configure the firewall, so consider this as one example. Please refer to the official AWS Network Firewall documentation to customize the settings according to your requirements.

For this verification, we will configure the firewall to permit only HTTP/HTTPS access to specific domains. This domain filtering is achieved using the Stateful Domain List Rule Group configuration.

Stateless Default Actions

In the stateless default action settings of your firewall, configure it to forward all packets to the stateful rule group:

• Default actions for full packets: Forward to the stateful rule groups.
• Default actions for fragmented packets: Forward to the stateful rule groups.

Next, we must define the order of stateful rule evaluations and set the default action. When multiple rules are defined, they will be applied in ascending order of priority (lower numeric values are processed first). If a packet does not match any rule, it will be dropped.

• Rule order: Strict order
• Default action: Drop established (Drop only packets that are in established connections)

With this configuration, any communication to domains other than the specified permitted domains will be dropped, ensuring that only authorized traffic is allowed.

Finally, let’s dive into the details of the Stateful Domain List Rule Group. This is where you will register the domains allowed through the firewall. The domains provided here are just examples, so please adjust them to fit your environment.

Configuration Details

• Allowed Domains:
  • soracom.io
  • google.com
    (Subdomains are also permitted.)
• Traffic and Actions:
  • Allow HTTP/HTTPS communication
• Source IP:
  • 10.128.0.0/9 (Device subnet)

With this, all configurations are complete.

Verification

Now let’s proceed with testing.

First, try communicating over HTTP to the permitted domains. As you can see, all communication to these domains is successful.

pi@raspberrypi:~ $ curl -v -m 5 soracom.io
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
* Connection #0 to host soracom.io left intact
pi@raspberrypi:~ $ curl -v -m 5 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intactCode language: HTML, XML (xml)

Finally, when attempting to access a non-permitted domain, such as soracom.io, the connection times out as expected. This is because AWS Network Firewall drops the packets, resulting in a timeout behavior from the client’s perspective.

pi@raspberrypi:~ $ curl -v -m 5 soracom.io
* Trying 3.82.81.201:80...
* Connected to soracom.io (3.82.81.201) port 80 (#0)
> GET / HTTP/1.1
> Host: soracom.io
> User-Agent: curl/7.88.1
> Accept: */*
>
* Operation timed out after 5000 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 5000 milliseconds with 0 bytes receivedCode language: PHP (php)

Conclusion

While this example focused on controlling HTTP/HTTPS traffic, a wide range of network controls can be implemented by configuring the rule groups accordingly.

We encourage you to adapt and implement the setup to suit your specific use cases.

This article is a translation of a piece from our Japanese team, it has been updated to reflect a western audience.

………………

Got a question about Soracom? Whether you’re an existing customer, interested in learning more about our products and services, or want to learn about our Partner program – we’d love to hear from you!