はじめに
AWS WAF で特定の IPv4 アドレスのみを許可する設定を入れ、自分のグローバル IP アドレスを許可リスト（IP Set）へ登録した。それでもブラウザからアクセスすると 403 Forbidden が返り、接続できない。許可リストの IP アドレスを見直しても誤りは見つからない。このような状況に直面することがあります。
原因は WAF の設定ミスではなく、IPv6 と OS のアドレス選択仕様の組み合わせにあります。意図せず IPv6 で通信が行われ、IPv4 しか登録していない許可リストにマッチせず、結果として 403 が返ります。
- WAF の IP 制限がすり抜ける原因（IPv6 優先のアドレス選択仕様）
- Windows などのクライアントが IPv6 を優先する挙動の背景
- CloudFront で IPv6 を無効化し、IPv4 接続へ一本化する手順（GUI・CLI 両対応）
結論として、CloudFront はデフォルトで IPv6 が有効なため、デュアルスタック環境のクライアントは IPv6 を優先して接続します。WAF の許可リストに IPv4 のみを登録している場合、この IPv6 通信は許可外としてブロックされます。固定のグローバル IPv4 アドレスで運用している環境では、CloudFront 側で IPv6 を無効化し、IPv4 へ一本化する対処が確実です。
原因: クライアントは IPv6 を優先して接続する
403 が返る背景には、CloudFront のデフォルト設定と OS のアドレス選択仕様が組み合わさり、意図せず IPv6 通信が発生している事情があります。順を追って整理します。
CloudFront はデフォルトで IPv6 が有効
CloudFront ディストリビューションを作成すると、初期設定で IPv6 が有効になっています。そのため DNS による名前解決を行うと、IPv4 アドレス（A レコード）に加えて IPv6 アドレス（AAAA レコード）も応答します。
クライアント環境が IPv6 に対応している
IPoE（v6 プラスなど）に対応したインターネット回線や、スマートフォンのテザリング環境では、PC に IPv6 アドレスが割り当てられていることが一般的です。この場合、クライアントは IPv4 と IPv6 の双方で通信できるデュアルスタック状態になります。IPoE 方式の仕組みについては、関連記事『IPoE（MAP-E・DS-Lite）の仕組みと PPPoE との違い｜方式の選び方と機種対応』もあわせて参照してください。
OS は IPv6 を優先する（RFC 6724）
ここが要点です。Windows 10 / 11 をはじめとする現代の OS は、通信相手が IPv6 に対応している場合、IPv4 よりも IPv6 を優先して使う仕様になっています。これは IPv6 のアドレス選択を定めた RFC 6724（2012 年に RFC 3484 を置き換えた標準）に基づく挙動です。
参考: RFC 6724 – Default Address Selection for IPv6
“the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa”
（アルゴリズムは IPv6 アドレスを IPv4 アドレスより優先することがあり、その逆もある）
https://www.rfc-editor.org/rfc/rfc6724
つまり、ブラウザに URL を入力した時点で、OS は名前解決で得た AAAA レコード（IPv6）を優先し、IPv6 での接続を試みます。利用者が明示的に IPv4 を指定しない限り、この選択は自動的に行われます。
WAF の許可リストとの不整合
ここで WAF の設定との間に不整合が生じます。
許可リスト（IP Set）には自分の IPv4 アドレスのみを登録している一方、実際の通信は IPv6 で到達します。WAF から見ると、送信元 IP は許可リストに存在しない IPv6 アドレスです。許可リストにマッチしないため、WAF ルールに従って通信はブロックされます。
これが「IPv4 を許可しているのに接続できない」現象の実態です。
対処法: CloudFront で IPv6 を無効化する
原因が「クライアントが自動的に IPv6 で接続すること」にある以上、接続先である CloudFront 側で IPv6 を無効化すれば解決します。サーバー側が IPv6 で応答しなければ、クライアントは IPv4 で接続します。設定はマネジメントコンソールと AWS CLI のいずれでも変更できます。
参考: Amazon CloudFront – DistributionConfig
“If you specify false, CloudFront responds to IPv6 DNS requests”
（false を指定すると、CloudFront は IPv6 の DNS リクエストに対して AAAA レコードを返さず応答します）
https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html
マネジメントコンソールで無効化する
コンソールでは数項目の変更で設定できます。現在のコンソールでは設定項目名が viewer 向けと origin 向けに分かれており、今回の対象は viewer 向けです。
- CloudFront コンソールを開き、対象のディストリビューションを選択します。
- 「General」タブを開き、「Settings」の「Edit」をクリックします。
- 「Enable IPv6 （viewer requests）」のチェックを外します。
- 「Save changes」をクリックして保存します。
保存後、ステータスが Deploying から Deployed に変われば反映完了です。これで DNS の応答から AAAA レコードが除かれ、クライアントは IPv4 で接続するようになります。
なお、同じ設定画面にある「Enable IPv6 for custom origins （origin requests）」は、CloudFront とオリジン間の通信に関する別設定です。今回の viewer からのアクセス制御とは対象が異なるため、変更する必要はありません。
AWS CLI で無効化する
コンソールに入らず CLI で変更する場合は、現在の設定を取得し、IsIPV6Enabled を false にして反映します。
# 1. 対象ディストリビューションの ID を確認
aws cloudfront list-distributions \
--query "DistributionList.Items[].{Id:Id,Domain:DomainName}" --output table
# 2. 現在の設定（DistributionConfig）と ETag を取得
aws cloudfront get-distribution-config \
--id <DISTRIBUTION_ID> --query "DistributionConfig" --output json > dist-config.json
ETAG=$（aws cloudfront get-distribution-config \
--id <DISTRIBUTION_ID> --query "ETag" --output text）
# 3. dist-config.json 内の "IsIPV6Enabled" を false に変更
# 4. 変更を反映（--if-match に取得した ETag を指定）
aws cloudfront update-distribution \
--id <DISTRIBUTION_ID> --if-match "$ETAG" --distribution-config file://dist-config.jsonget-distribution-config の出力をそのまま update-distribution に渡すとエラーになります。出力は ETag と DistributionConfig を含む構造になっているため、上記のように --query "DistributionConfig" で中身だけを取り出し、ETag は --if-match に分けて渡します。
参考: aws cloudfront update-distribution（AWS CLI Command Reference）
https://docs.aws.amazon.com/cli/latest/reference/cloudfront/update-distribution.html
無効化後の動作確認
AAAA レコードが除かれたかどうかは、名前解決で確認できます。
# AAAA レコードが返らないことを確認
dig AAAA <ディストリビューション名>.cloudfront.net
# Windows の場合
nslookup -type=AAAA <ディストリビューション名>.cloudfront.net
# IPv6 での接続が成立しないこと（IPv4 にフォールバックすること）を確認
curl -6 https://<ドメイン名>/AAAA レコードの応答が消えていれば、以降クライアントは IPv4 で接続します。
IPv6 無効化と WAF での IPv6 許可の選定
対処の選択肢は「CloudFront で IPv6 を無効化する」と「WAF 側で IPv6 アドレスも許可する」の二つです。WAF は IPv6 にも対応しているため、後者も技術的には成立します。
参考: AWS News Blog – IPv6 Support Update
“AWS WAF can now inspect requests that arrive via IPv4 or IPv6 addresses”
（AWS WAF は IPv4 と IPv6 のどちらで到達したリクエストも検査できます）
https://aws.amazon.com/blogs/aws/ipv6-support-update-cloudfront-waf-and-s3-transfer-acceleration/
どちらを選ぶかは、IPv6 アクセスを維持する必要があるか、許可対象の IP アドレスが安定しているかで判断します。WAF の許可リスト（IP Set）の管理方法については、関連記事[AWS WAF の IP Set 運用]（INTERNAL_LINK_WAF_IPSET）も参考になります。
| 観点 | IPv6 を無効化（IPv4 一本化） | WAF で IPv6 を許可 |
|---|---|---|
| 設定の手間 | CloudFront 側で 1 項目をオフ | IP Set に IPv6 の CIDR を追加・維持 |
| アドレスの安定性 | 固定 IPv4 なら管理が容易 | 家庭回線・モバイルの IPv6 は変動しやすい |
| 管理の複雑さ | 低い | CIDR の計算・管理が複雑になりやすい |
| IPv6 利用者への影響 | IPv4 へフォールバック | IPv6 のまま到達可能 |
| 向いているケース | 固定 IPv4 での社内向け IP 制限 | IPv6 でのアクセスを維持したい公開系 |
固定のグローバル IPv4 アドレスを持つ環境で社内向けに IP 制限する用途であれば、IPv6 を無効化して IPv4 へ一本化するほうが、管理がシンプルで確実です。
補足: 適用前に確認したい制約
IPv6 を無効化すると、IPv6 ネットワークの利用者にも IPv4 へのフォールバックを強いることになります。社内向けの IP 制限では影響は小さいものの、一般公開コンテンツでは利用者の接続性に留意してください。
また、署名付き URL・署名付き Cookie でカスタムポリシーの IpAddress を使って IP アドレスを制限する構成でも、同様の不整合が起こり得ます。この場合、AWS 公式は IPv6 を有効化しないことを推奨しています。今回の WAF による IP 制限と同じ性質の問題です。
まとめ
本記事では、AWS WAF で許可済みの IPv4 から接続しても 403 が返る事象について、原因と対処を整理しました。背景には IPv6 優先のアドレス選択仕様があり、設定ミスとは異なる視点での切り分けが求められます。固定の IPv4 アドレスで運用する環境では、CloudFront 側で IPv6 を無効化する対処が管理しやすく確実です。
- WAF の IP 制限で 403 が返る一因は IPv6 優先のアドレス選択仕様
- CloudFront はデフォルトで IPv6 が有効で AAAA レコードも応答する
- Windows などの OS は RFC 6724 に基づき IPv6 を優先する
- 許可リストに IPv4 のみを登録すると IPv6 通信は許可外となる
- 固定 IPv4 環境では CloudFront の IPv6 無効化が確実な対処
- 設定はコンソールの Enable IPv6 （viewer requests） または CLI で変更可能
- 無効化後は dig AAAA で AAAA レコードの消失を確認
以上、最後までお読みいただきありがとうございました。
