LASSIC Media らしくメディア
pfSenseでファイアウォールを外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- pfSenseはFreeBSDベースのオープンソースファイアウォール／UTMで、ステートフル検査・NAT・VPNを標準機能として備えます。
- パッケージ拡張でIDS/IPSやトラフィックシェーピングを追加でき、CARPによる冗長構成も組めます。
- 商用UTMアプライアンスとの違いを踏まえ、構築・運用を内製するか外部パートナーへ委託するかの判断軸を解説します。
目次
pfSenseの基本構造とステートフル検査
pfSenseとは、FreeBSD上のパケットフィルタ「pf」を核に構築された、オープンソースのファイアウォール／ルーティングソフトウェアである*1。ネットワーク機器としてインストールし、ファイアウォール・ルーター・VPNゲートウェイの役割を1台で担わせられます。
公式ドキュメントによると、pfSenseのルールはデフォルトでステートフル（stateful）です*1。通過するトラフィックが許可ルールに一致すると状態テーブル（state table）にエントリが作られ、戻りの応答パケットはルールと再照合せず、この状態テーブルとの一致だけで自動的に通過が許可されます*1。状態1件あたり約1KBのRAMを要し、デフォルトでは搭載RAMの約10%が状態テーブル用に割り当てられます*1。RAM1GBの環境ではおよそ10万エントリを保持できる計算です*1。
ルール評価は先着順（first match basis）で行われ、上から順にマッチするルールを適用します*1。境界に置く機器としての基本設計は、この状態管理とルール評価にあります。
NAT・ルーティングで境界を制御する仕組み
NAT（Network Address Translation）とは、パケットのIPヘッダのアドレス情報を通過時に変換する技術で、あるIPアドレス空間を別の空間へ写し替える仕組みです*1。pfSenseではWAN側のグローバルIPアドレスとLAN側のプライベートアドレスを1対1・多対1で変換し、社内端末を外部から直接到達できない状態に保ちます。
ファイアウォールルールとNATルールは連動して評価され、ポート単位の転送（ポートフォワード）や、拠点間VPNでの1:1 NATにも対応します*2。静的ルーティングやマルチWAN構成を組み合わせれば、複数拠点や複数回線を持つ環境でも経路を柔軟に制御できます*2。
境界の制御はNAT単体では完結しません。ルール順序・エイリアス（IPアドレス群のグループ化）・ログ設計まで含めて初めて、意図した通信だけを通す構成になります。
IPsec・OpenVPN・WireGuardで拠点間とリモート接続を守る
pfSenseとは、拠点間VPNとリモートアクセスVPNの双方をIPsec・OpenVPN・WireGuardの3方式で実現できるファイアウォールを指します*3。公式ガイドは用途に応じた選び方を示しており、単純比較ではなく特性差の理解が要ります*3。
IPsecはほぼすべてのVPN対応機器に実装されているため相互接続性が高く、拠点間VPNの定番として使われます*3。一方で設定項目が多く、初めて触る場合は難度が上がります*3。OpenVPNは証明書ベースの認証を使い、ウィザードで設定を簡略化できる一方、対応する他社ファイアウォール製品は限られます*3。
WireGuardは設定項目が少なくシンプルで、Windows・macOS・Linux・Android・iOSなど幅広いOSにクライアントが存在します*3。ただしユーザー単位の認証機能は持たないため、リモートアクセス用途ではアクセス制御の設計を別途組む必要があります*3。3方式のどれを軸にするかで、運用担当者に求めるスキルセットも変わってきます。
パッケージ拡張で加えるIDS/IPSとトラフィック制御
pfSenseは、パッケージシステムを通じてSnortやSuricataといったIDS/IPS（不正侵入検知・防御システム）を追加導入できます*4。両パッケージは設計面で共通点が多く、Snort向けの設定手順の大半がSuricataにも当てはまります*4。シグネチャベースで既知の攻撃パターンを検知し、IPSモードでは該当パケットを遮断する構成に切り替えられます。
帯域制御にはトラフィックシェーパーの「リミッター」機能が使えます。リミッターはdummynetを用いた帯域制限の仕組みで、IPアドレスやネットワーク単位の帯域制限を実現する手段として提供されています*5。入り方向と出方向で1組ずつ設定するのが基本で、特定プロトコルや特定端末への帯域上限を個別に課せます*5。
これらはpfSense本体の機能ではなく追加パッケージである点が特徴です。導入すればファイアウォール専用機からUTM（Unified Threat Management、複数の脅威対策機能を統合した装置）へと役割が広がりますが、パッケージごとにシグネチャ更新や設定の保守が発生します。
CARPによる冗長構成と可用性の確保
境界に置く機器が単一障害点になる懸念には、CARP（Common Address Redundancy Protocol）による冗長化で対応します*6。pfSenseの高可用性（HA）構成は、プライマリノードが稼働系、セカンダリノードが待機系として動く、いわゆるアクティブ／パッシブ型のクラスタです*6。
各ノードはWAN・LAN・Sync（同期用）の3つのインターフェースを持ち、Syncインターフェース経由で設定情報や状態テーブルの同期（pfsync）を行います*6。CARPの死活監視はハートビート信号によって行われ、各インターフェースのCARP仮想IPごとに送信されます*6。
2ノード構成を組むにはハードウェアもライセンスも2台分が必要になり、Sync用ネットワークの設計も加わります。可用性を高める分、構築・検証の工数は単体構成より増えます。
pfSenseと商用UTMアプライアンスの違い
pfSenseは、商用UTMアプライアンスと同じ役割（ファイアウォール・VPN・IDS/IPS）を担えますが、提供形態が異なります。無償のpfSense Community Edition（CE）はオープンソースのまま提供され、商用フォークのpfSense Plusは年3回のメジャー更新とNetgateの技術サポートが付く有償・準有償の位置づけです*7。
pfSense Plus限定の機能には、OpenVPNのDCO（Data Channel Offload）やIntel IPsec Multi-Buffer、ZFSブート環境管理などが含まれます*7。CARPのユニキャストモードやEthernet（レイヤー2）フィルタ、NetFlow/IPFIX対応もPlus側の機能として位置づけられています*7。
| 比較軸 | pfSense（CE/Plus） | 商用UTMアプライアンス |
|---|---|---|
| ライセンス形態 | CEは無償・OSS。Plusは年3回更新＋サポート付き*7 | 機器購入＋年間ライセンス契約が一般的 |
| 機能拡張の方法 | パッケージ追加（Snort/Suricata等）で個別拡張*4 | ベンダーが機能を統合パッケージとして提供 |
| サポート窓口 | CEはコミュニティ中心。Plusはベンダーサポート*7 | ベンダー窓口・保守契約に基づく一次対応 |
| 構築の自由度 | 仮想基盤・汎用サーバー・Netgate機器に導入可 | 専用ハードウェアに限定される場合が多い |
構築・運用の勘所と内製が抱える負荷
pfSenseの構築を内製で完結させる場合、ネットワーク設計・pfのルール記法・NAT設計・VPN方式ごとの鍵管理・パッケージの脆弱性対応まで、幅広い知識が要ります。設定を誤ると、意図しないポート開放や戻り通信の遮断につながり、業務システムへの到達性そのものが失われる恐れがあります。
ルール設計を誤ると社内システムへの通信経路が断たれ、復旧まで業務が止まる事態も想定されます。CARP構成では、Syncの設定ミスがフェイルオーバーの遅延や状態テーブル同期の失敗に直結するため、切替動作の事前検証が欠かせません*6。
パッケージ拡張後は、シグネチャ更新・ログ監視・誤検知チューニングという継続運用が発生します。構築時点の設計品質が、その後の運用負荷を大きく左右する点は見過ごせません。
外注と内製、どちらを選ぶかの判断軸
内製で対応するには、ネットワーク設計者・ファイアウォールルールの実装者・VPN鍵管理者・IDS/IPSのチューニング担当という役割を、最低でも兼務できる体制が必要です。24時間監視や障害時の一次対応まで自社で担う場合は、当直体制の設計も避けられません。
外部パートナーに構築を委託する場合との差分は、設計レビューの有無と初期構築後の保守体制に表れます。パートナーは複数環境での構築知見を持ち、CARP構成やVPN方式の選定を要件に合わせて提案できる点が内製と異なります。
LASSICでは、境界ネットワークの要件整理からpfSenseの構築、CARPによる冗長化設計、稼働後の保守運用までを一体で請け負う体制を整えています。自社の体制で担える範囲と、外部に委ねるべき範囲を切り分けるところから、要件整理をご支援します。
まとめ：pfSense構築を検討する3つの判断軸
本稿では、pfSenseの基本構造（ステートフル検査・NAT）、VPN方式の選び方、パッケージ拡張によるIDS/IPS・トラフィック制御、CARPによる冗長化、商用UTMとの違いを整理しました。判断軸を3つに集約すると、第一に自社の通信要件に合うVPN方式とNAT設計を選べるか、第二にパッケージ拡張後のシグネチャ更新・監視を継続できる体制があるか、第三にCARP構成のような冗長化を自社で検証・維持できるかという点になります。これらの見極めが難しい場合は、外部パートナーへの相談が現実的な選択肢です。
よくある質問
pfSense CEとpfSense Plusはどちらを選ぶべきですか。
用途とサポート要件で選び分けます。pfSense CEは無償のオープンソース版で、コミュニティ中心のサポートになります*7。pfSense PlusはOpenVPNのDCOやZFSブート環境管理などの機能とベンダーサポートが付き、年3回のメジャー更新が予定されています*7。業務利用でベンダー窓口を要する場合はPlus側の検討が現実的です。
拠点間VPNとリモートアクセスVPNでは方式を分けるべきですか。
用途に応じて方式を検討する価値があります。拠点間はIPsecが幅広い機器と相互接続できる点で選ばれやすく*3、リモートアクセスはOpenVPNの証明書認証やWireGuardのクライアント対応の広さが判断材料になります*3。ユーザー認証が要るかどうかも選定に関わります*3。
IDS/IPSパッケージを入れるとパフォーマンスへの影響はありますか。
SnortやSuricataはパケットを検査するため処理負荷が加わります*4。負荷の程度は回線速度・ルール数・ハードウェア性能によって変わるため、導入前に検査対象インターフェースやシグネチャセットを絞る設計が要ります。継続運用ではシグネチャ更新と誤検知チューニングが発生します*4。
CARPによる冗長化には何が必要ですか。
プライマリ・セカンダリの2ノード構成と、設定・状態テーブル同期用のSyncインターフェースが必要です*6。CARPはハートビートで死活を監視し、障害時にセカンダリが仮想IPを引き継ぎます*6。切替動作の事前テストを行い、想定通りフェイルオーバーするかを確認する工程も欠かせません。
pfSenseの構築を外注する場合、どこまで任せられますか。
要件整理・NAT/ファイアウォールルール設計・VPN方式の選定・CARP冗長化・稼働後の保守運用まで、一体で依頼できます。自社で担う範囲と外部に委ねる範囲を最初に切り分けておくと、構築後の役割分担が明確になります。LASSICでは要件整理の段階からご支援します。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Netgate「Firewall Fundamentals – pfSense Documentation」
- *2 出典：Netgate「Firewall & NAT – pfSense Documentation」
- *3 出典：Netgate「Choosing a VPN solution – pfSense Documentation」
- *4 出典：Netgate「IDS / IPS – pfSense Documentation」
- *5 出典：Netgate「Limiters – pfSense Documentation」
- *6 出典：Netgate「High Availability – pfSense Documentation」
- *7 出典：Netgate「What is pfSense Plus Software? – pfSense Documentation」
