Nat64 что это
Перейти к содержимому

Nat64 что это

  • автор:

Сеть IPv6 с доступом к IPv4 (NAT64+DNS64)

Во время перехода интернета с IPv4 на IPv6 необходимо как-то обеспечить работу сети с учётом сервисов, которые работают только по IPv4. Можно использовать дуалстэк, т.е. использовать внутри сети IPv4 и IPv6 адресации. Схема рабочая, но приводит к необходимости настраивать два протокола вместо одного, что в больших сетях может заметно добавить работы сетевым администраторам. При этом для внешних адресов IPv4, скорее всего, будет использован NAT.

Ещё один вариант перехода на IPv6 — это использовать в сети адресацию только IPv6. Все внутренние сервисы переводятся на него, а для доступа к внешним ресурсам IPv4 применяется трансляция NAT64. Схема работы незначительно отличается от первого варианта. Также используется NAT, хотя и другого типа, но при этом отпадает необходимость в настройке IPv4 во внутренней сети.

Нам необходимо как-то заставить приложения обращаться к некоторому виртуальному IPv6 адресу, который посредством NAT64 будет преобразован в IPv4 адрес. Самое простое, что можно сделать — изменить ответы DNS так, что при запросе записей типа A будут возвращаться также записи типа AAAA . Они должны указывать на адрес сервиса NAT64, который будет получать запросы и транслировать их в сеть IPv4.

Ограничения подобной схемы:

  1. При обращении по IPv4 адресу непосредственно, возникнет ошибка, т.к. протокол IPv4 не поддерживается сетевым интерфейсом хоста. У этой проблемы есть несколько решений, одно из которых установка специального сервиса непосредственно на клиентской машине, который преобразует запросы к адресам IPv4 в IPv6 по той же схеме, что используется в DNS64. Подробнее об этом читайте ниже.
  2. Если домен использует DNSSEC и не имеет записей AAAA , то наши «фейковые» AAAA записи не будут иметь корректной цифровой подписи. Это не очень критично, потому что узлов с DNSSEC и без записей AAAA (для которых будут создаваться фейковые AAAA записи) крайне мало. Если вы используете DNSSEC то вы должны обратить на это внимание и протестировать все необходимые вам внешние сервисы только с IPv4 и убедиться, что они не используют DNSSEC.

История решения задачи

Первые тесты с DNS64 и NAT64 я выполнял ещё в декабре 2022 года. При этом был использован стенд из трёх виртуальных машин на базе Virtualbox, две из которых выступали в качестве клиентов на базе Fedora 37 и Ubuntu 22.04 LTS. В качестве шлюза был использован Ubuntu 22.04 LTS. Всё необходимое ПО доступно из репозиториев, доступных в базовой поставке систем.

Сервер имеет два сетевых интерфейса, один из которых подключен к локальной сети, а второй к внутренней сети VirtualBox. Клиентские машины подключались только ко внутренней сети. Поскольку имеющийся маршрутизатор не позволял использовать выданную IPv6 адресацию от провайдера, то в качестве поставщика IPv6 использовался туннельный брокер с подключением через Wireguard. При таком подключении можно использовать как подключение виртуальной машины по умолчанию с использованием NAT, так и режим моста с сетевым интерфейсом реальной машины.

В дальнейшем я перешёл на тестирование на реальном железе. Сделать это мне позволил маршрутизатор с OpenWRT, который имеет все необходимые пакеты, чтобы обеспечить вашу сеть как режимом дуалсэк, так и полностью перевести её на IPv6.

Какой софт понадобится?

Для того, чтобы организовать вашу собственную сеть, которая использует только IPv6 протокол, нам необходимо обеспечить:

  1. преобразование записей DNS для IPv4 (типа A) в записи для IPv6 (AAAA);
  2. трансляцию адресов из IPv4 в IPv6 (NAT64):
  3. рассылку анонсов маршрутизатора в LAN.

Обеспечить преобразование записей DNS можно с помощью:

  • Bind 9;
  • Unbound;
  • публичных DNS64 серверов, но при этом имеются ограничения на варианты настройки и места размещения NAT64.

Трансляцию адресов NAT64 могут обеспечить:

TAYGA проще в установке, но при этом могут возникнуть проблемы с производительностью при большом количестве соединений. Jool требует установку модуля ядра, но при этом имеет хорошую производительность.

Рассылку объявлений маршрутизатора можно выполнить, например, с помощью сервиса radvd.

Подготовка к установке

Первое, что необходимо сделать, определиться с адресацией IPv6, которая будет использована для для механизма трансляции. Этот префикс необходимы выбирать исходя из адресации вашей сети. В качестве диапазона может быть использован глобально уникальный диапазон адресов или локально уникальный или префикс 64:ff9b::/96 . Обратите внимание, что использование префикса 64:ff9b::/96 запрещает узлам IPv6 связываться с узлами IPv4, имеющими частные (RFC1918) адреса, в соответствии с RFC 6052. Глобально уникальный диапазон адресов позволит пользоваться вашим сервисом даже за пределами вашей сети или сделать его доступным для других пользователей сети Internet. Остальное доступно только в пределах локальной сети при настройке соответствующей маршрутизации.

В дальнейшем я буду использовать диапазон 64:ff9b::/96 .

Я пользуюсь провайдером «Ростелеком» который выделяет мне сеть /56 . Однако префикс этой сети динамический, т.к. меняется периодически, арендованный маршрутизатор не умеет выдавать доступные мне подсети. Поэтому, для эксперимента я использовал туннельного брокера, который мне выделяет постоянную сеть /48 . Позднее я заменил маршрутизатор, а старый использовал в режиме моста, что позволило мне по полной задействовать выданную мне провайдером сеть.

Выделим диапазон для нашей сети, которая будет пользоваться сервисами NAT64 и DNS64. Я буду использовать 2001:db8:feee:1::/64 .

Внешний адрес сервера, который будет выполнять функции NAT64 будет 2001:db8:feee::2 . Доступ в интернет он будет иметь через IPv4 10.0.2.15 (в моём случае это был VirtualBox с NAT).

В качестве DNS64 сервера можно выбрать как публичные DNS64, так и настроить собственный на базе Unbound или Bind. В качестве транслятора NAT64 можно выбрать Tayga или Jool. В дальнейшем приведены примеры настройки для всех пакетов, но на реальной машине понадобится только один для каждой функции.

Публичные DNS64 серверы

Если вы выбрали использовать диапазон 64:ff9b::/96 , то вы можете обойтись без настройки сервера Bind и воспользоваться публичными DNS64 серверами. Их предоставляют, например, Google и Cloudflare. По сути это те же сервисы Google DNS и Cloudflare DNS, но для адресов, которые не имеют записей AAAA эти DNS предоставляют адрес из диапазона 64:ff9b::/96 .

Адреса серверов Google DNS64:

  • 2001:4860:4860::6464
  • 2001:4860:4860::64

Адреса серверов Cloudflare DNS64:

  • 2606:4700:4700::64
  • 2606:4700:4700::6400

Оба сервиса поддерживают работу через безопасный транспорт DNSoverTLS и DNSoverHTTP. Google использует для этих служб сертификат домена dns64.dns.google .

Настройка Unbound (DNS64)

Необходимо включить модуль dns64 с помощью директивы module-config и указанию префикса, который будет использован с помощью dns64-prefix . Не забываем разрешить доступ к серверу с других хостов ( interface ) путём указания адресов или имён интерфейсов. Также необходимо указать пул адресов, для которого будет доступен сервер ( access-control ), например, для всех через IPv6 ( ::/0 )

Можно просто создать файл в папке /etc/unbound/unbound.conf.d/ , например, с именем dns64.conf и разместить в нём следующую информацию:

server: module-config: "dns64 validator iterator" dns64-prefix: 64:ff9b::/96 interface: enp0s8 interface: ::1 access-control: ::/0 allow

Обратите внимание, что по умолчанию на сервере включены модули subnet , validator и iterator . При подобной конфигурации модуль subnet будет отключен.

В качестве интерфейсов указан сетевой интерфейс, который смотрит в локальную сеть и петлевой интерфейс ::1 для локальных подключений.

# nslookup > server ::1 Default server: ::1 Address: ::1#53 > habr.com Server: ::1 Address: ::1#53 Non-authoritative answer: Name: habr.com Address: 178.248.237.68 Name: habr.com Address: 64:ff9b::b2f8:ed44

Сочетание опций interface и access-control может быть изменено в зависимости от ваших предпочтений и исходя из конфигурации вашей реальной сети. Они влияют только на доступность сервера, но не на механизм DNS64.

Настройка Bind 9 (DNS64)

Настройку можно начать с DNS. Bind 9 начиная с версии 9.8 позволяет использовать специальную опцию dns64 , которую необходимо разместить в секции options :

options < . dns64 64:ff9b::/96 < suffix ::; clients < any; >; mapped < any; >; >; >;

Перезапускаем службу named . Теперь ответ от DNS сервера должен запись AAAA , которая указывает на адрес из выбранного диапазона. Проверим любой адрес, который не имеет записей AAAA в DNS, например, habr.com :

# nslookup > habr.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: habr.com Address: 178.248.237.68 Name: habr.com Address: 64:ff9b::b2f8:ed44 >

При этом, если мы запрашиваем адрес, который уже имеет записи AAAA , то ответ не модифицируется:

> tavda.info Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: tavda.info Address: 89.208.105.251 Name: tavda.info Address: 2a0e:d602:1:f8::a

Настройка radvd

Настроим radvd для анонсов маршрутизатора. Используем выбранную сеть 2001:db8:feee:1::/64 . В качестве DNS сервера будем предлагать 2001:db8:feee::2 — адрес нашего сервера-маршрутизатора.

interface enp0s8 < AdvSendAdvert on; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; prefix 2001:db8:feee:1::/64 < AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; >; RDNSS 2001:db8:feee::2 < >; >;

Включение маршрутизации

Для включения маршрутизации необходимо включить передачу пакетов через хост через sysctl . В Ubuntu можно просто создать файл /etc/sysctl.d/99-route.conf :

net.ipv6.conf.all.forwarding = 1 net.ipv4.ip_forward = 1

После создания выполните sysctl —system или перезапустите систему. После этого ваш сервер сможет маршрутизировать пакеты IPv4 и IPv6.

Настройка TAYGA (NAT64)

Файл конфигурации TAYGA в Ubuntu расположен по пути /etc/tayga.conf . В нём необходимо выделить адреса IPv4 и IPv6, которые не будут совпадать с адресами хоста, а также пул адресов IPv4, который будет использован при трансляции:

tun-device nat64 ipv4-addr 10.0.2.129 ipv6-addr 2001:db8:feee::3 prefix 64:ff9b::/96 dynamic-pool 10.0.2.128/25 data-dir /var/spool/tayga

Наиболее значимые опции, которые необходимо изменить под свою сеть:

  • ipv4-addr — адрес маршрутизатора TAYGA. Необходимо использовать отдельный адрес, отличный от IP адреса, который используется на маршрутизаторе с этим пакетом. Этот адрес можно разместить внутри dynamic-pool .
  • ipv6-addr — необходим только при использовании диапазона 64:ff9b::/96 в качестве prefix и если ipv4-addr является частным адресом.
  • prefix — используемый IPv6 префикс для трансляции IPv6 в IPv4.
  • dynamic-pool — пул адресов IPv4, который выдаётся клиентам IPv6, если они их нет в статической карте.

Настройка Jool (NAT64)

Ещё одним вариантом трансляции адресов является Jool. Он работает на уровне ядра, поэтому должен показывать большую производительность. На ОС Ubuntu начиная с 20.04 LTS и более поздних установить его можно с помощью команды

sudo apt install jool-dkms jool-tools

При этом будет установлена не самая свежая версия пакета. Можно воспользоваться репозиторием или собрать исходный код самостоятельно. Подробнее об этом можно почитать на сайте Jool. Однако версии, поставляемой с Ubuntu 22.04 LTS будет вполне достаточно для дальнейшего использования.

Запустить трансляцию адресов NAT64 вручную можно с помощью команды

sudo jool instance add "nat64" --netfilter --pool6 64:ff9b::/96

Здесь также указан диапазон 64:ff9b::/96 , который можно заменить любым другим желаемым.

jool instance remove "nat64"

Для обеспечения автоматического запуска можно использовать юнит systemd. Для этого необходимо создать файл конфигурации формата JSON по адресу /etc/jool/jool.conf :

 "comment": "Configuration for the systemd NAT64 Jool service.", "instance": "nat64", "framework": "netfilter", "global":  "comment": "Pool6 prefix", "pool6": "64:ff9b::/96" > >

После этого можно активировать и запустить юнит:

sudo systemd enable --now jool

Использование DNS64 и NAT64 на реальном железе

Самое интересное исследование мне удалось провести только после приобретения маршрутизатора, на который можно установить OpenWRT. В своей базовой поставке он вполне может обеспечить вашу сеть дуалстэком. И это первое, что вам нужно сделать. Дальнейшие модификации не повлияют на вашу сеть до тех пор, пока вы не отключите выделение IPv4 адреса. Тестировать работу режима только IPv6 вы сможете на любом вашем устройстве, которое позволяет отключить получение IPv4 адреса.

Т.к. OpenWRT базируется на ядре Linux, то в качестве NAT64 можно использовать ранее упомянутый Jool:

opkg update opkg install jool-tools-netfilter

Все настройки Jool находятся в папке /etc/jool/ . Настройки, которые касаются NAT64, расположены в файле jool-nat64.conf.json . Изначально в нём содержится пример конфигурации. Можно заменить его самым простым вариантом, например:

cat  EOF > /etc/jool/jool-nat64.conf.json < "instance": "default", \ "framework": "netfilter", \ "global": < "pool6": "64:ff9b::/96" >> EOF

Далее необходимо активировать Jool:

uci set jool.general.enabled="1" uci set jool.nat64.enabled="1" uci commit jool /etc/init.d/jool restart

После этого можно проверить на клиенте, что все настройки произведены, например, так

ping 64:ff9b::8.8.8.8

Вы должны получить ответ от сервера 8.8.8.8. Можно использовать любой другой IP, который точно доступен и отвечает вашему маршрутизатору.

Теперь можно подключить DNS64 сервер и отключить IPv4 на клиенте. Я использовал DNS64 от Google. Естественно, для NAT64 был использован диапазон 64:ff9b::/96 . Именно его подсказывает интерфейс LuCI на OpenWRT, а также он приведён в примере конфигурации. Другие устройства в сети имели доступ в интернет по обоим протоколам.

Что делать если приложению требуется IPv4

Решить эту проблему можно только непосредственно на клиенте. Для этого можно использовать компонент clatd. Он использует TAYGA при своей работе. Настраивать этот компонент почти не придётся. Достаточно прописать одну строку, где указать используемый в нашей сети префикс для трансляции NAT64. В файле /etc/clatd.conf добавим строку:

plat-prefix=64:ff9b::/96

После этого можно запустить сервис. После его запуска можно увидеть, что появился новый сетевой интерфейс clat.

# ip a . 3: clat: mtu 1500 qdisc fq_codel state UP group default qlen 500 link/none inet 192.0.0.1/32 scope global clat valid_lft forever preferred_lft forever inet6 fe80::8617:661d:4056:8be3/64 scope link stable-privacy valid_lft forever preferred_lft forever

Теперь приложения, которые не используют DNS64 или обращаются в сеть по протоколу IPv4 смогут пользоваться интернет.

Вывод по результатам тестирования

С чем могут быть проблемы? Во-первых, это те программы, которые опираются на IPv4 адреса. Ранее были проблемы с запуском Steam, но новые версии уже не жалуются на недоступность сети.

Вторая явная проблема, которую я смог выявить уже на реальном железе: если у вас нет IPv4, то вам становятся недоступны пиры IPv4 по протоколу BitTorrent. Это не означает, что вам полностью закрыт доступ к торрентам, но это ограничивает вас только IPv6 пирами. Т.е. не стоит обрезать доступ к IPv4 вашему торрент клиенту. Если вы не можете использовать IPv4 совсем, то вы вполне можете воспользоваться сервисом clatd на своей машине. В Linux его нужно устанавливать и запускать. Слышал о том, что в MacOS он включается автоматически, если вы имеете доступ в сеть только IPv6. Для Windows решений пока не искал.

Третья проблема — кривые сайты. Как ни странно, но первый кривой сайт, с которым я столкнулся, был speedtest.net . Проблема в том, что он содержит AAAA записи в DNS, но по ним недоступен. При этом www.speedtest.net имеет только A записи и даже пытается загрузиться. Но, при этом, подгружает ресурсы со своих поддоменов, где тоже есть проблема с загрузкой по IPv6. Как результат, поехавшая вёрстка и полная неработоспособность сервиса. Если вы используете дуалстэк, то ваш браузер перейдёт на IPv4 и, единственно, что вас будет беспокоить, лёгкий дискомфорт, что сайт грузится медленно. Опять таки clatd вам поможет, поскольку позволит браузеру использовать Fallback режим, когда он обращается к IPv4, если сайт недоступен через IPv6.

Заключение

Уже в текущих условиях можно пользоваться исключительно IPv6 сетью на клиентских устройствах и иметь доступ практически ко всему, но при этом ваша сеть должна быть настроена должным образом.

Проблемы есть, и они незначительные. Корпоративные сети могут без проблем строиться исключительно на IPv6, что, даже, может добавить безопасности. К тому же всегда можно организовать островок IPv4 и через него организовывать доступ к нужным ресурсам по сети IPv6. Дома использовать только IPv6 может быть дискомфортно, особенно если вы любите качать торренты или играть в Steam игры (но это, возможно, уже решено), поэтому лучшим решением будет дуалстэк.

Обратите внимание, что заметки могут обновляться со временем. Это может быть как исправление найденных ошибок, так и доработка содержания с целью более полного раскрытия темы. Информация об изменениях доступна в репозитории на github. Там же вы можете оставить в Issue ваши замечания по данной заметке.

Если данная заметка оказалась вам полезной, можете поблагодарить автора финансово на сервисе Boosty или любой суммой через сервис QIWI.

Persistent NAT and NAT64

Network Address Translators (NATs) are well known to cause very significant problems with applications that carry IP addresses in the payload. Applications that suffer from this problem include Voice Over IP and Multimedia Over IP. Persistent NAT improves NATs behavior and defines a set of NAT requirement behavior which is useful for VOIP applications working. NAT64 is a translating mechanism used to translate IPv6 packets to IPv4 packets and vice versa by translating the packet headers according to IP/ICMP Translation Algorithm.

Understanding Persistent NAT and NAT64

Persistent NAT allows applications to use the Session Traversal Utilities for NAT (STUN) protocol when passing through NAT firewalls. Persistent NAT ensures that all requests from the same internal transport address (internal IP address and port) are mapped to the same reflexive transport address (the public IP address and port created by the NAT device closest to the STUN server).

NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice versa that allows IPv6 clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. It is an enhancement of Network Address Translation-Protocol Translation (NAT-PT).

NAT64 supports the following:

  • Endpoint-independent mappings
  • Endpoint-independent filtering and address-dependent filtering

The mapping and filtering behaviors of NAT64 and persistent NAT are identical.

The following types of persistent NAT can be configured on the Juniper Networks device:

  • Any remote host—All requests from a specific internal IP address and port are mapped to the same reflexive transport address. Any external host can send a packet to the internal host by sending the packet to the reflexive transport address.
  • Target host—All requests from a specific internal IP address and port are mapped to the same reflexive transport address. An external host can send a packet to an internal host by sending the packet to the reflexive transport address. The internal host must have previously sent a packet to the external host’s IP address.
  • Target host port—All requests from a specific internal IP address and port are mapped to the same reflexive transport address. An external host can send a packet to an internal host by sending the packet to the reflexive transport address. The internal host must have previously sent a packet to the external host’s IP address and port.

Note: The target-host-port configuration is not supported for NAT64 when configured with IPv6 address.

You configure any of the persistent NAT types with source NAT rules. The source NAT rule action can use a source NAT pool (with or without port translation) or an egress interface. Persistent NAT is not applicable for destination NAT, because persistent NAT bindings are based on outgoing sessions from internal to external.

Port overloading is used in Junos OS only for normal interface NAT traffic. Persistent NAT does not support port overloading, and you must explicitly disable port overloading with one of the following options at the [ edit security nat source ] hierarchy level:

  • port-overloading off
  • port-overloading-factor 1

To configure security policies to permit or deny persistent NAT traffic, you can use two new predefined services— junos-stun and junos-persistent-nat .

Persistent NAT is different from the persistent address feature (see Understanding Persistent Addresses for Source NAT Pools). The persistent address feature applies to address mappings for source NAT pools configured on the device. The persistent NAT feature applies to address mappings on an external NAT device, and is configured for a specific source NAT pool or egress interface. Also, persistent NAT is intended for use with STUN client/server applications.

Understanding Session Traversal Utilities for NAT (STUN) Protocol

Many video and voice applications do not work properly in a NAT environment. For example, Session Initiation Protocol (SIP), used with VoIP, encodes IP addresses and port numbers within application data. If a NAT firewall exists between the requestor and receiver, the translation of the IP address and port number in the data invalidates the information.

Also, a NAT firewall does not maintain a pinhole for incoming SIP messages. This forces the SIP application to either constantly refresh the pinhole with SIP messages or use an ALG to track registration, a function that may or may not be supported by the gateway device.

The Session Traversal Utilities for NAT (STUN) protocol, first defined in RFC 3489, Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) and then later in RFC 5389, Session Traversal Utilities for NAT , is a simple client/server protocol. A STUN client sends requests to a STUN server, which returns responses to the client. A STUN client is usually part of an application that requires a public IP address and/or port. STUN clients can reside in an end system such as a PC or in a network server whereas STUN servers are usually attached to the public Internet.

Both the STUN client and STUN server must be provided by the application. Juniper Networks does not provide a STUN client or server.

The STUN protocol allows a client to:

  • Discover whether the application is behind a NAT firewall.
  • Determine the type of NAT binding being used.
  • Learn the reflexive transport address, which is the IP address and port binding allocated by NAT device closest to the STUN server. (There may be multiple levels of NAT between the STUN client and the STUN server.)

The client application can use the IP address binding information within protocols such as SIP and H.323.

Understanding NAT64 IPv6 Prefix to IPv4 Address-Persistent Translation

The NAT64 mechanism enables IPv6 clients to contact IPv4 servers by translating IPv6 addresses to IPv4 addresses (and vice versa). However, some IPv4 applications and services cannot work correctly over IPv6-only networks with standard NAT64 in a dual-translation scenario, such as . In those scenarios, address-persistent translation is required.

Figure 1 illustrates the 464XLAT architecture, whereby IPv4 packets are translated to IPv6 packets on the customer-side translator (CLAT), then go across the IPv6-only network, and are translated back to IPv4 packets on the provider-side translator (PLAT) to access global IPv4-only content in the core network. This architecture uses a combination of stateless translation on the CLAT and stateful translation on the PLAT.

Figure 1: 464XLAT Architecture

When a device functions as a PLAT, it is responsible for keeping the sticky mapping relationship between one specific IPv6 prefix and one translated IPv4 address. The device treats the IPv6 prefix as a single user. This mapping is accomplished by configuring the specific IPv6 prefix length in an IPv4 source NAT pool using the address-persistent feature.

Figure 2 illustrates a NAT rule configured in the CLAT, which translates an IPv4 address to an IPv6 address with an address-persistent prefix. With stateless NAT46 translation on the CLAT and stateful NAT64 translation on the PLAT, the traffic from IPv4 host 192.168.1.2 reaches the global server 198.51.100.1 over an IPv6-only network.

Figure 2: NAT64 Translation on the PLAT

Table 1 lists other NAT features and their compatibility with the address-persistent feature.

Table 1: NAT Feature Compatibility with the Address Persistent Feature

NAT IPv4 to IPv6

NAT IPv6 to IPv4

NAT IPv4 to IPv6

NAT IPv6 to IPv4

Persistent NAT in PAT pool

Port block allocation

Address pooling paired

(Existing ALG NAT translations , such as FTP/PPTP/RTSP/DNS/SIP from native IPv6 clients.)

Persistent NAT and NAT64 Configuration Overview

To configure persistent NAT, specify the following options with the source NAT rule action (for either a source NAT pool or an egress interface):

  • The type of persistent NAT—One of the following: any remote host, target host, or target host port.
  • (Optional) Address mapping—This option allows requests from a specific internal IP address to be mapped to the same reflexive IP address; internal and reflexive ports can be any ports. An external host using any port can send a packet to the internal host by sending the packet to the reflexive IP address (with a configured incoming policy that allows external to internal traffic). If this option is not configured, the persistent NAT binding is for specific internal and reflexive transport addresses. You can only specify the address-mapping option when the persistent NAT type is any remote host and the source NAT rule action is one of the following actions:
    • Source NAT pool with IP address shifting
    • Source NAT pool with no port translation and no overflow pool

    For interface NAT, you need to explicitly disable port overloading with one of the following options at the [ edit security nat source ] hierarchy level:

    • port-overloading off
    • port-overloading-factor 1

    Finally, there are two predefined services that you can use in security policies to permit or deny STUN and persistent NAT traffic:

    • junos-stun —STUN protocol traffic.
    • junos-persistent-nat —Persistent NAT traffic.

    For the any remote host persistent NAT type, the direction of the security policy is from external to internal. For target host or target host port persistent NAT types, the direction of the security policy is from internal to external.

    Example: Configuring Address Persistent NAT64 Pools

    This example shows how to configure address persistent NAT64 pools to ensure a sticky mapping relationship between one specific IPv6 prefix, which is calculated by the configured IPv6 prefix length, and one translated IPv4 address.

    Requirements

    Before you begin, be sure the existing NAT rules and pool configuration do not conflict with the new one.

    Overview

    In this example, you configure an IPv6 prefix length of /64 in an IPv4 source NAT pool for NAT IPv6 to IPv4 translations. Traffic matching the NAT rule and NAT pool perform address persistent translation between the IPv6 prefix and the IPv4 translated address. This configuration can be used on the provider-side translator (PLAT) in a dual-translation scenario, , to enable IPv4 services to work over IPv6-only networks.

    Configuration

    • CLI Quick Configuration
    • Procedure
    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    set security nat source pool NAT64 address 198.51.100.240/32 to 198.51.100.254/32 set security nat source pool NAT64 address-persistent subscriber ipv6-prefix-length 64 set security nat source rule-set RS1 from zone trust set security nat source rule-set RS1 to zone untrust set security nat source rule-set RS1 rule R1 match source-address 2001:db8::/32 set security nat source rule-set RS1 rule R1 match destination-address 198.51.100.198/32 set security nat source rule-set RS1 rule R1 then source-nat pool NAT64
    Procedure
    • Step-by-Step Procedure
    • Results
    Step-by-Step Procedure

    The following example requires you to navigate throughout various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

      Create a source NAT pool.

    [edit security nat source] user@host# set pool NAT64 address 198.51.100.240/32 to 198.51.100.254/32 
    [edit security nat source] user@host# set pool NAT64 address-persistent subscriber ipv6-prefix-length 64 
    [edit security nat source] user@host# set rule-set RS1 from zone trust user@host# set rule-set RS1 to zone untrust 
    [edit security nat source] user@host# set rule-set RS1 rule R1 match source-address 2001:db8::/32 user@host# set rule-set RS1 rule R1 match destination-address 198.51.100.198/32 
    [edit security nat source] user@host# set security nat source rule-set RS1 rule R1 then source-nat pool NAT64
    Results

    From configuration mode, confirm your configuration by entering the show security nat command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    [edit] user@host# show security nat source < pool NAT64 < address < 198.51.100.240/32 to 198.51.100.254/32; >address-persistent subscriber ipv6-prefix-length 64; > rule-set RS1 < from zone trust; to zone untrust; rule R1 < match < source-address 2001:db8::/32; destination-address 198.51.100.198/32; >then < source-nat < pool < NAT64; >> > > > >

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Verifying NAT Application to Traffic
    Purpose

    Verify that the same IPv6 prefix is translated to the persistent IPv4 address.

    Action

    From operational mode, enter the show security flow session command.

    Example: Supporting Network Configuration By Configuring Persistent NAT with Interface NAT

    You can configure any of the persistent types with source NAT rules. This example illustrates how to apply persistent NAT with an interface IP address and how to use an interface IP address as a NAT IP address to perform persistent NAT for a specific internal host. It also shows how to maintain persistent address behavior and persistent NAT filter behavior for the host. You must disable port overloading for interface NAT.

    Requirements

    This example uses the following hardware and software components:

    • 1 SRX Series device
    • 4 PCs

    Before you begin:

    • Understand the concepts of persistent NAT. See Persistent NAT and NAT64 Configuration Overview.

    Overview

    In a Carrier Grade NAT (CGN) network deployment, you can configure the interface IP address as a NAT address to perform persistent network address translation. In this way, the internal host can create one source NAT mapping relationship by the outgoing traffic initiated from internal to external. Then the external host sends traffic back to this internal host by sending the traffic to this interface NAT address through the shared NAT mapping relationship.

    In this example, you first configure the interface NAT rule set int1 to match traffic from interface ge-0/0/1 to interface ge-0/0/2, and then you configure the NAT rule in1 to match the specific source and destination addresses to perform persistent NAT. You configure the any remote host persistent NAT type when interface NAT is performed.

    For packets with source address 192.0.2.0/24 (internal phones) and destination address 198.51.100.0/24 (including server, proxy server, and external phones), you configure interface NAT with the any remote host persistent NAT type. Then you disable port overloading for interface NAT.

    Next, you configure a security policy to allow persistent NAT traffic from the external network (external zone) to the internal network (internal zone) for any of the remote host persistent NAT types.

    Topology

    Figure 3 shows an interface persistent NAT topology.

    Figure 3: Interface Persistent NAT Topology

    Table 2 shows the parameters configured in this example.

    Table 2: Interfaces, Zones, Servers, and IP Address Information

    Phone2 address of external network

    Phone1 address of internal network

    SIP proxy server address of external network

    STUN server address of external network

    Destination IP address

    Source IP address

    ge-0/0/1 and ge-0/0/2

    NAT interfaces for traffic direction

    Configuration

    Procedure
    • CLI Quick Configuration
    • Step-by-Step Procedure
    • Results
    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    set security nat source rule-set int1 from interface ge-0/0/1.0 set security nat source rule-set int1 to interface ge-0/0/2.0 set security nat source rule-set int1 rule in1 match source-address 192.0.2.0/24 set security nat source rule-set int1 rule in1 match destination-address 198.51.100.0/24 set security nat source rule-set int1 rule in1 then source-nat interface persistent-nat permit any-remote-host set security nat source interface port-overloading off set security policies from-zone internal to-zone external policy stun_traffic match source-address internal_phones destination-address stun_server application junos-stun set security policies from-zone internal to-zone external policy sip_proxy_traffic match source-address internal_phones destination-address sip_proxy_server application junos-sip set security policies from-zone internal to-zone external policy sip_traffic match source-address internal_phones destination-address external_phones application junos-persistent-nat set security policies from-zone internal to-zone external policy sip_traffic then permit set security policies from-zone internal to-zone external policy stun_traffic then permit set security policies from-zone internal to-zone external policy sip_proxy_traffic then permit
    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure an interface NAT rule set:

      Create a persistent NAT rule for an interface NAT.

    [edit security nat source rule-set int1] user@host# set from interface ge-0/0/1.0 user@host# set to interface ge-0/0/2.0 user@host# set rule in1 match source-address 192.0.2.0/24 user@host# set rule in1 match destination-address 198.51.100.0/24 user@host# set rule in1 then source-nat interface persistent-nat permit any-remote-host 
    [edit security] user@host# set nat source interface port-overloading off 
    [edit security policies] user@host# set from-zone internal to-zone external policy stun_traffic match source-address internal_phones destination-address stun_server application junos-stun 
    [edit security policies] user@host# set from-zone internal to-zone external policy sip_proxy_traffic match source-address internal_phones destination-address sip_proxy_server application junos-sip 
    [edit security policies] user@host# set from-zone internal to-zone external policy sip_traffic match source-address internal_phones destination-address external_phones application junos-persistent-nat user@host# set from-zone internal to-zone external policy sip_traffic then permit user@host#set from-zone internal to-zone external policy stun_traffic then permit user@host#set from-zone internal to-zone external policy sip_proxy_traffic then permit
    Results

    From configuration mode, confirm your configuration by entering the show security nat and show security policies commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

    [edit] user@host# show security nat source < interface < port-overloading off; >rule-set int1 < from interface ge-0/0/1.0; to interface ge-0/0/2.0; rule in1 < match < source-address 192.0.2.0/24; destination-address 198.51.100.0/24; >then < source-nat < interface < persistent-nat < permit any-remote-host; >> > > > > > [edit] user@host# show security policies from-zone internal to-zone external < policy stun_traffic < match < source-address internal_phones; destination-address stun_server; application junos-stun; >then < permit; >> policy sip_proxy_traffic < match < source-address internal_phones; destination-address sip_proxy_server; application junos-sip; >then < permit; >> policy sip_traffic < match < source-address internal_phones; destination-address external_phones; application junos-persistent-nat; >then < permit; >> >

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Confirm that the configuration is working properly.

    • Verifying That Rules Are Matched and Used
    • Verifying That NAT Traffic Sessions Are Established
    Verifying That Rules Are Matched and Used
    Purpose

    Verify that all the rules are matched and used.

    Action

    From operational mode, enter the show security nat source persistent-nat-table all command.

    user@host>show security nat source persistent-nat-table all Internal Reflective Source Type Left_time/Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.0.2.12 17012 udp 198.51.100.1 28153 udp interface any-remote-host 3528/3600 -/- in1 192.0.2.12 7078 udp 198.51.100.1 6133 udp interface any-remote-host -/300 1/30 in1
    Meaning

    The output displays a summary of persistent NAT information.

    Verifying That NAT Traffic Sessions Are Established
    Purpose

    Verify that the sessions are established on the device.

    Action

    From operational mode, enter the show security flow session command.

    user@host>show security flow session Session ID: 6992, Policy name: sip_proxy_traffic/5, Timeout: 16, Valid In: 192.0.2.12/17012 --> 198.51.100.45/5060;udp, If: ge-0/0/1.0, Pkts: 4, Bytes: 1850 Out: 198.51.100.45/5060 --> 198.51.100.1/28153;udp, If: ge-0/0/2.0, Pkts: 5, Bytes: 2258 Session ID: 7382, Policy name: stun_traffic/4, Timeout: 16, Valid In: 192.0.2.12/7078 --> 198.51.100.49/3478;udp, If: ge-0/0/1.0, Pkts: 20, Bytes: 1040 Out: 198.51.100.49/3478 --> 198.51.100.1/6133;udp, If: ge-0/0/2.0, Pkts: 0, Bytes: 0
    Meaning

    The show security flow session command displays active sessions on the device and each session’s associated security policy. The output shows traffic entering the device using the private source address 192.0.2.12 destined to a public host at 198.51.100.45. The return traffic from this flow travels to the translated public address 198.51.100.1.

    • Session ID —Number that identifies the session. Use this ID to get more information about the session such as policy name or number of packets in and out.
    • sip_proxy_traffic — Policy name that permitted the SIP traffic from the internal SIP phones to the external SIP proxy server.
    • In —Incoming flow (source and destination IP addresses with their respective source and destination port numbers. The session is UDP, and the source interface for this session is ge-0/0/1.0).
    • Out —Reverse flow (source and destination IP addresses with their respective source and destination port numbers. The session is UDP, and the destination interface for this session is ge-0/0/2.0).
    • stun_traffic —Policy name that permitted the STUN traffic from the internal SIP phones to the external STUN server.

    Example: Configuring Address-Dependent Filtering for IPv6 Clients

    This example shows how to configure address-dependent filtering for IPv6 clients using NAT64.

    Requirements

    Before you begin:

    • Ensure that IPv6 is enabled on the device.
    • Ensure that the existing NAT rule and pool configuration do not conflict with the new ones.

    Overview

    In this example you use NAT64 to send packets from the IPv6 internal host to the IPv4 external host and from the IPv4 external host to the IPv4 internal host.

    Topology

    Configuration

    Procedure
    • CLI Quick Configuration
    • Step-by-Step Procedure
    • Results
    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    set security nat static rule-set test_rs from interface ge-0/0/1 set security nat static rule-set test_rs rule test_rule match destination-address 2001:db8::/128 set security nat static rule-set test_rs rule test_rule then static-nat prefix 10.2.2.15/32 set security nat source pool myipv4 address 203.0.113.2 set security nat source rule-set myipv4_rs from interface ge-0/0/1 set security nat source rule-set myipv4_rs to interface ge-0/0/2 set security nat source rule-set myipv4_rs rule ipv4_rule match source-address 2001:db8::/96 set security nat source rule-set myipv4_rs rule ipv4_rule match destination-address 10.2.2.15 set security nat source rule-set myipv4_rs rule ipv4_rule then source-nat pool myipv4 set security nat source rule-set myipv4_rs rule ipv4_rule then source-nat pool persistent-nat permit target-host
    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

    To configure address-dependent filtering for IPv6 clients:

      Create a set of rules for NAT64.

    [edit security nat static] user@host# set rule-set test_rs from interface ge-0/0/1 
    [edit security nat static] user@host# set rule-set test_rs rule test_rule match destination-address 2001:db8::/128 
    [edit security nat static] user@host# set rule-set test_rs rule test_rule then static-nat prefix 10.2.2.15/32 
    [edit security nat] user@host# set source pool myipv4 address 203.0.113.2 
    [edit security nat] user@host# set source rule-set myipv4_rs from interface ge-0/0/1 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule match source-address 2001:db8::/96 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule match destination-address 10.2.2.15 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule then source-nat pool myipv4 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule then source-nat pool persistent-nat permit target-host
    Results

    From configuration mode, confirm your configuration by entering the show nat source command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    [edit security] user@host#show nat source pool myipv4 < address < 203.0.113.2/32; >> rule-set test_rs < rule test_rule < match < destination-address 2001:db8::/128; >> > rule-set myipv4_rs < from interface ge-0/0/1.0; to interface ge-0/0/2.0; rule ipv4_rule < match < source-address 2001:db8::/96; destination-address 10.2.2.15/32; >then < source-nat < pool < myipv4; persistent-nat < permit target-host; >> > > > > >

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Confirm that the configuration is working properly:

    • Verifying That the Configuration Is Enabled and Working
    • Verifying That Rules Are Matched and Used
    Verifying That the Configuration Is Enabled and Working
    Purpose

    Verify that the configuration is enabled and working.

    Action

    From operational mode, enter the following commands:

    • show security nat static rule test_rule
    • show security nat source rule ipv4_rule
    • show security nat source pool myipv4
    Verifying That Rules Are Matched and Used
    Purpose

    Verify that all the rules are matched and used.

    Action

    From operational mode, enter the show security nat source persistent-nat-table all command.

    Example: Configuring Endpoint-Independent Filtering for IPv6 Clients

    This example shows how to configure endpoint-independent filtering for IPv6 clients using NAT64.

    Requirements

    Before you begin:

    • Ensure that IPv6 is enabled on the device
    • Ensure that the existing NAT rules and pool configuration do not conflict with the new ones.

    Overview

    In this example you use NAT64 to send packets from the IPv6 internal host to the IPv4 external host and from the IPv4 external host to the IPv4 internal host.

    Topology

    Configuration

    Procedure
    • CLI Quick Configuration
    • Step-by-Step Procedure
    • Results
    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    set security nat static rule-set test_rs from interface ge-0/0/1 set security nat static rule-set test_rs rule test_rule match destination-address 2001:db8::/128 set security nat static rule-set test_rs rule test_rule then static-nat prefix 10.2.2.15/32 set security nat source pool myipv4 address 203.0.113.2 set security nat source rule-set myipv4_rs from interface ge-0/0/1 set security nat source rule-set myipv4_rs to interface ge-0/0/2 set security nat source rule-set myipv4_rs rule ipv4_rule match source-address 2001:db8::/96 set security nat source rule-set myipv4_rs rule ipv4_rule match destination-address 10.2.2.15 set security nat source rule-set myipv4_rs rule ipv4_rule then source-nat pool myipv4 set security nat source rule-set myipv4_rs rule ipv4_rule then source-nat pool persistent-nat permit any-remote-host
    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

    To configure endpoint-independent filtering for IPv6 clients:

      Create a set of rules for NAT64.

    [edit security nat static] user@host# set rule-set test_rs from interface ge-0/0/1 
    [edit security nat static] user@host# set rule-set test_rs rule test_rule match destination-address 2001:db8::/128 
    [edit security nat static] user@host# set rule-set test_rs rule test_rule then static-nat prefix 10.2.2.15/32 
    [edit security nat] user@host# set source pool myipv4 address 203.0.113.2 
    [edit security nat] user@host# set source rule-set myipv4_rs from interface ge-0/0/1 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule match source-address 2001:db8::/96 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule match destination-address 10.2.2.15 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule then source-nat pool myipv4 
    [edit security nat] user@host# set source rule-set myipv4_rs rule ipv4_rule then source-nat pool persistent-nat permit any-remote-host
    Results

    From configuration mode, confirm your configuration by entering the show security nat command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    [edit security] user@host#show security nat source < pool myipv6_prefix < address < 2001:db8::/64; >> pool myipv4 < address < 203.0.113.2/32; >> rule-set myipv6_rs < from interface ge-0/0/1.0; to interface ge-0/0/2.0; rule ipv6_rule < match < source-address 10.1.1.0/30; destination-address 2001:db8::2/96; >then < source-nat < pool < myipv6_prefix; >> > > > rule-set myipv4_rs < from interface ge-0/0/1.0; to interface ge-0/0/2.0; rule ipv4_rule < match < source-address 2001:db8::/96; destination-address 10.2.2.15/32; >then < source-nat < pool < myipv4; persistent-nat < permit target-host; >> > > > > > static < rule-set test_rs < from interface ge-0/0/1.0; rule test_rule < match < destination-address 2001:db8::/128; >then < static-nat < prefix < 10.2.2.15/32; >> > > > >

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Confirm that the configuration is working properly:

    • Verifying That the Configuration is Enabled and Working
    • Verifying That Rules Are Matched and Used
    Verifying That the Configuration is Enabled and Working
    Purpose

    Verify that the configuration is enabled and working.

    Action

    From operational mode, enter the following commands.

    • show security nat static rule test_rule
    • show security nat source rule ipv4_rule
    • show security nat source pool myipv4
    Verifying That Rules Are Matched and Used
    Purpose

    Verify that all the rules are matched and used.

    Action

    From operational mode, enter the show security nat source persistent-nat-table all command.

    Example: Setting Maximum Persistent NAT Bindings

    This example shows how to increase the persistent NAT capacity.

    Requirements

    Overview

    In this example, you enable the maximize persistent NAT capacity option. This option is supported only on Services Processing Cards (SPCs) for SRX1400 devices with SRX1K-NPC-SPC-1-10-40, SRX3000 line with SRX3K-SPC-1-10-40, and SRX5000 line devices with SRX5K-SPC-2-10-40SPC and SRX5K-SPC3. Note that for the SRX5000 line devices with SRX5K-SPC-2-10-40SPC and SPC3, the persistent NAT binding number is maximized at the cost of reducing the maximum session number.

    To enable this option, the supported central point maximum binding capacity can be approximately increased to 1/8 of the central point session capacity up to 2M and the supported SPU maximum binding capacity can be approximately increased to 1/4 of each SPU session capacity. Accordingly, the flow session capacity will decrease by 1/4 on both the CP and each of the SPU.

    By default, the persistent NAT binding capacity on both the central point and the SPU of an SRX5400, SRX5600, or SRX5800 device is 64,000. In this example, you enable the session capacity to maximum 20,000,000 on the central point and maximum 1,100,000 on each of the SPUs with maximum session configuration. If you enable the maximize-persistent-nat-capacity option, an SRX5400, SRX5600, or SRX5800 device with 4 GB of memory can support maximum 2M persistent NAT bindings on the central point and 275,000 bindings on each of the SPUs.

    Configuration

    Procedure
    Step-by-Step Procedure

    To increase the persistent NAT capacity:

      Set maximize persistent NAT capacity option.

    [edit] user@host# set security forwarding-process application-services maximize-persistent-nat-capacity 
    [edit] user@host# commit 
    [edit] user@host# request system reboot

    Note: When switching to maximize persistent NAT capacity mode or back to regular mode, you must restart the device.

    [edit] user@host# delete security forwarding-process application-services maximize-persistent-nat-capacity

    Verification

    Verifying Increased Persistent NAT Capacity
    Purpose

    Verify that you have increased the persistent NAT capacity.

    Action

    From operational mode, enter the show security forwarding-process application-services command.

    Persistent NAT Hairpinning Overview

    When traffic is sent between two hosts, the source host of the traffic may only know the destination host by its public IP address. In reality, the destination host may be in the same private address space as the source host. Hairpinning is the process of returning the traffic in the direction from where it came from as a way to get it to its destination host in a private subnetwork.

    Generally, a source host in a subnetwork may not recognize that the traffic is intended for a destination host within the same subnetwork, because it identifies the destination host only by its public IP address. The NAT analyzes the IP packets and routes the packet back to the correct host.

    NAT hairpinning support is required if two hosts on the internal network want to communicate with each other by using a binding on the NAT device. In this case, the NAT device receives a packet from the internal network and forwards it back to the internal network. If hairpinning is not supported, forwarding the packet will fail and it will be dropped.

    Hairpinning enables two endpoints (Host 1 and Host 2) on the private network to communicate even if they only use each other’s external IP addresses and ports. When Host 1 sends traffic to Host 3, a NAT binding between Host 1’s internal source IP address and port is associated in the NAT table with its external IP address and port. The same thing happens when Host 2 sends traffic to Host 3. In this way, when Host 1 and Host 2 want to communicate, they can identify each other’s external IP addresses.

    For example, if Host 1 communicates with Host 2, NAT (with hairpinning support) is used to route the packets, which contain Host 2’s external address, back to Host 2’s internal address.

    Figure 4: Persistent NAT Hairpinning

    In Figure 4, the following parameters are used:

    • Host 1 IP address — 10.10.10.2/24
    • Host 2 IP address — 10.10.10.10/24
    • Intra-zone IP address — 10.10.10.254/24
    • Host 3 IP address — 198.51.100.2/24
    • Inter-zone IP address — 198.51.100.254/24
    • Host 1 and Host 2 are in zone reht0z , and Host 3 is in reth1z zone

    Table 3 shows the binding table used in this example.

    Table 3: Persistent NAT Binding Table

    Original Source IP Address

    Translated Source IP Address

    10.10.10.2/24 to 10.10.10.11/24

    192.0.2.1/32 to 192.0.2.10/32

    Persistent NAT hairpinning applies only to any remote host persistent NAT type. To allow hairpinning, you must configure a security policy to allow traffic between endpoints in the same zone. Actually the two endpoints can be located in two different zones as well as long as either of the two hosts can only see the public address of the peer.NAT hairpinning behavior is not supported by target host persistent NAT and target host port persistent NAT. Only any remote host persistent NAT supports hairpinning behavior.

    Example: Configuring Persistent NAT Hairpinning with Source NAT Pool with Address Shifting

    This example shows how to configure persistent NAT hairpinning.

    Requirements

    Before you begin:

    • Configure network interfaces on the device. See Interfaces User Guide for Security Devices.
    • Create security zones and assign interfaces to them. See Understanding Security Zones.

    Overview

    Hairpinning allows packets from the private network to be translated and then looped back to the private network rather than being passed through to the public network. Hairpinning feature enables using a corresponding record in the NAT table to recognize that a packet is addressed to a host in the local network. Then it translates the destination IP address and sends the packet back to the local network (as well as in case of port mapping). This ensures that traffic between the two hosts work properly.

    Topology

    Hairpinning enables two endpoints (Host 1 and Host 2) on the private network to communicate even if they only use each other’s external IP addresses and ports. This is explained in Figure 5.

    When Host 1 sends traffic to Host 3, a NAT binding between Host 1’s internal source IP address and port is associated in the NAT table with its external IP address and port. The same thing happens when Host 2 sends traffic to Host 3. In this way, when Host 1 and Host 2 want to communicate, they can identify each other’s external IP addresses.

    For example, if Host 1 communicates with Host 2, NAT (with hairpinning support) is used to route the packets, which contain Host 2’s external address, back to Host 2’s internal address.

    Figure 5: Persistent NAT Hairpinning

    In Figure 5, the following parameters are used:

    • Host 1 IP address — 10.10.10.2/24
    • Host 2 IP address — 10.10.10.10/24
    • Intra-zone IP address — 10.10.10.254/24
    • Host 3 IP address — 198.51.100.2/24
    • Inter-zone IP address — 198.51.100.254/24
    • Host 1 and Host 2 are in zone reht0z , and Host 3 is in reth1z zone

    Table 4 shows the binding table used in this example.

    Table 4: Persistent NAT Binding Table

    Original Source IP Address

    Translated Source IP Address

    10.10.10.2/24 to 10.10.10.11/24

    192.0.2.1/32 to 192.0.2.10/32

    Configuration

    Procedure
    • Step-by-Step Procedure
    • Results
    Step-by-Step Procedure

    To configure persistent NAT hairpinning:

    [edit] user@host# set interfaces ge-11/0/0 unit 0 family inet address 10.10.10.254/24 user@host# set interfaces ge-11/0/1 unit 0 family inet address 198.51.100.254/24 
    [edit] user@host# set security zones security-zone reth0z host-inbound-traffic system-services all user@host# set security zones security-zone reth0z host-inbound-traffic protocols all user@host# set security zones security-zone reth0z interfaces ge-11/0/0.0 user@host# set security zones security-zone reth1z host-inbound-traffic system-services all user@host# set security zones security-zone reth1z host-inbound-traffic protocols all user@host# set security zones security-zone reth1z interfaces ge-11/0/1.0 
    [edit] user@host# set security address-book global address subnet10 10.10.10.0/24 user@host# set security address-book global address subnet20 198.51.100.0/24 user@host# set security policies from-zone reth0z to-zone reth1z policy p1 match source-address subnet10 user@host# set security policies from-zone reth0z to-zone reth1z policy p1 match destination-address subnet20 user@host# set security policies from-zone reth0z to-zone reth1z policy p1 match application any user@host# set security policies from-zone reth0z to-zone reth1z policy p1 then permit user@host# set security policies default-policy deny-all 
    user@host# set security policies from-zone reth0z to-zone reth0z policy p2 match source-address subnet10 user@host# set security policies from-zone reth0z to-zone reth0z policy p2 match destination-address subnet10 user@host# set security policies from-zone reth0z to-zone reth0z policy p2 match application any user@host# set security policies from-zone reth0z to-zone reth0z policy p2 then permit 
    [edit] user@host# set security nat source pool src1 address 192.0.2.1/32 to 192.0.2.10/32 
    [edit] user@host# set security nat source pool src1 host-address-base 10.10.10.2/24 
    [edit] user@host# set security nat source rule-set r1 from zone reth0z user@host# set security nat source rule-set r1 to zone reth1z user@host# set security nat source rule-set r1 to zone reth0z user@host# set security nat source rule-set r1 rule rule1 match source-address 10.10.10.0/24 user@host# set security nat source rule-set r1 rule rule1 match destination-address 10.10.10.0/24 user@host# set security nat source rule-set r1 rule rule1 match destination-address 198.51.100.0/24 user@host# set security nat source rule-set r1 rule rule1 then source-nat pool src1 user@host# set security nat source rule-set r1 rule rule1 then source-nat pool persistent-nat permit any-remote-host user@host# set security nat source rule-set r1 rule rule1 then source-nat pool persistent-nat inactivity-timeout 900 user@host# set security nat source rule-set r1 rule rule1 then source-nat pool persistent-nat max-session-number 20
    Results

    From configuration mode, enter the show security nat command to confirm your configuration. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    [edit] user@host# show security nat source < pool src1 < address < 192.0.2.1/32 to 192.0.2.10/32; >host-address-base 10.10.10.2/24; > rule-set r1 < from zone reth0z; to zone [ reth0z reth1z ]; rule rule1 < match < source-address 10.10.10.0/24; destination-address [10.10.10.0/24 198.51.100.0/24]; >then < source-nat < pool < src1; persistent-nat < permit any-remote-host; inactivity-timeout 900; max-session-number 20; >> > > > > >

    If you are done configuring the device, enter commit from configuration mode.

    Все в порядке, но.

    Этот текст мало кто будет читать и мы можем написать здесь все, что угодно, например.
    Вы живете в неведении. Роботы уже вторглись в нашу жизнь и быстро захватывают мир, но мы встали на светлый путь и боремся за выживание человечества. А если серьезно, то.

    В целях обеспечения безопасности сайта от кибератак нам необходимо убедиться, что вы человек. Если данная страница выводится вам часто, есть вероятность, что ваш компьютер заражен или вы используете для доступа IP адрес зараженных компьютеров.

    Если это ваш частный компьютер и вы пытаетесь зайти на сайт, например, из дома — мы рекомендуем вам проверить ваш компьютер на наличие вирусов.

    Если вы пытаетесь зайти на сайт, например, с работы или открытых сетей — вам необходимо обратиться с системному администратору и сообщить, что о возможном заражении компьютеров в вашей сети.

    • © 2005-2023, «4PDA». 4PDA® — зарегистрированный товарный знак.

    forum.lissyara.su

    Сталина давно нэт. Чтоби спасти Россию, ищитэ его внутри сэбя.

    DNS64 and NAT64

    Простые/общие вопросы по UNIX системам. Спросите здесь, если вы новичок

    Правила форума
    Убедительная просьба юзать теги [cоde] при оформлении листингов.
    Сообщения не оформленные должным образом имеют все шансы быть незамеченными.

    Первое новое сообщение • 11 сообщений • Страница 1 из 1
    pautina рядовой Сообщения: 19 Зарегистрирован: 2013-04-26 23:09:26

    DNS64 and NAT64

    Добрый день!
    В нашей компании решили развивать IPv6 в связи с окончанием IPv4, но вот стала проблема, что в сети IPv4 клиентов с IPv6 не так просто выпустить.
    Отдельно выделен сервер где крутиться IPv6 и IPv4 все работает по OSPF. С v6 проблем нет. На клиентские vlanы выделяем подсети ::/64 и дальше по DHCPv6 выдаем каждому клиенту IPv6, пока, в динамике IP версии, объявление роутера происходит при помощи RADVD с портов, встроенные rtadv почему-то не всем выдавал шлюз, естественно не все пользователи получали IPv6. Так вот вопрос, кто сталкивался и настраивал уже DNS64 and NAT64 для доступа к сетям IPv4 клиентов у которых только IPv6.

    Последний раз редактировалось f_andrey 2013-04-27 0:02:33, всего редактировалось 1 раз.
    Причина: Автору. пожалуйста, выбирайте соответствующий раздел форума, если приведёте больше логов, это повысит вероятность ответов, а не флуда

    pautina

    Хостинг HostFood.ru

    Услуги хостинговой компании Host-Food.ru

    Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
    Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
    Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
    https://www.host-food.ru/tariffs/vydelennyi-server-ds/
    Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

    pautina рядовой Сообщения: 19 Зарегистрирован: 2013-04-26 23:09:26

    Re: DNS64 and NAT64

    Данные и некоторые настройки сервера

    FreeBSD v6gate.* 9.1-STABLE FreeBSD 9.1-STABLE #0 r249796: Tue Apr 23 18:18:23 EEST 2013 root@v6gate:/usr/src/sys/amd64/compile/V6GATE amd64

    Настройки radvd.conf

    interface vlan1500 < AdvManagedFlag on; AdvSendAdvert on; AdvOtherConfigFlag on; MinRtrAdvInterval 3; MaxRtrAdvInterval 60; >;

    Конфиг dhcpd6.conf

    authoritative; default-lease-time 2592000; preferred-lifetime 604800; option dhcp-renewal-time 3600; option dhcp-rebinding-time 7200; # Enable RFC 5007 support (same than for DHCPv4) allow leasequery; # Global definitions for name server address(es) and domain search list option dhcp6.name-servers 2001:*:*:1::9; option dhcp6.domain-search "v6.*"; option dhcp6.info-refresh-time 21600; # A third subnet behind a relay agent chain subnet6 2001:*:*:b::/64
    ######################################################################################################### # WORLD-CORE ######################################################################################################### ifconfig_vlan780="inet 193.*.*.12 netmask 255.255.255.240 vlan 780 vlandev em0 description -=WORLD-CORE=-" ifconfig_vlan780_ipv6="inet6 2001:*:*::12 prefixlen 64" ######################################################################################################### # IXP-CORE ######################################################################################################### ifconfig_vlan781="inet 193.*.*.44 netmask 255.255.255.240 vlan 781 vlandev em0 description -=IXP-CORE=-" ifconfig_vlan781_ipv6="inet6 2001:*:*:1::11 prefixlen 64" ####################################################################################################### # IPv6 ######################################################################################################### ifconfig_em1="up" ######################################################################################################### # TEST-NET ######################################################################################################### ifconfig_vlan1500="vlan 1500 vlandev em1 description -=TEST\ NETWORK=-" ifconfig_vlan1500_ipv6="inet6 2001:*:*:b::1/64" ######################################################################################################### quagga_enable="YES" gateway_enable=="YES" ipv6_gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" dhcpd6_enable="YES" radvd_enable="YES"

    Кусок quagga show running-config

    interface vlan780 ipv6 nd suppress-ra ipv6 ospf6 cost 1 ipv6 ospf6 dead-interval 40 ipv6 ospf6 hello-interval 10 ipv6 ospf6 instance-id 0 ipv6 ospf6 passive ipv6 ospf6 priority 1 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 transmit-delay 1 ! interface vlan781 ipv6 nd suppress-ra ipv6 ospf6 cost 1 ipv6 ospf6 dead-interval 40 ipv6 ospf6 hello-interval 10 ipv6 ospf6 instance-id 0 ipv6 ospf6 priority 1 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 transmit-delay 1 ! interface vlan1500 ipv6 nd suppress-ra ipv6 ospf6 cost 1 ipv6 ospf6 dead-interval 40 ipv6 ospf6 hello-interval 10 ipv6 ospf6 instance-id 0 ipv6 ospf6 passive ipv6 ospf6 priority 1 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 transmit-delay 1 ! router ospf ospf router-id 193.*.*.44 redistribute kernel route-map OSPF redistribute connected route-map OSPF redistribute static route-map OSPF passive-interface em0 passive-interface em1 passive-interface vlan780 network 193.*.*.0/24 area 0.0.0.0 ! router ospf6 router-id 193.*.*.44 redistribute connected route-map OSPF-6 interface vlan781 area 0.0.0.1 ! route-map OSPF-6 permit 10 ! ipv6 forwarding
    Похожие публикации:
    1. 2 месяц по счету это какой
    2. Кто я хакер
    3. Митап что это
    4. Синьор и сеньор в чем разница

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *