Proxy arp windows server

Привет.

Многие думают, что если протокол мелкий и незаметный, то про него не надо ничего знать. Нетрудно догадаться, что это не так, и именно детальное знание подобных низкоуровневых и “простых” технологий является тем, что отличает профессионала от гуглоиксперта или фанатика, верующего, что в его любимой ОС всё работает “само по себе и априори идеально”.

Чуть-чуть поговорим о протоколах семейства ARP – обычно они не изучаются, и лишь поверхностно проводится обзор протокола ARP, на уровне рамочного понимания функционала – ну, а мы посмотрим, какие ещё варианты бывают.

Семейка протоколов ARP

• Протокол ARP
  • Вкратце про сам протокол и формат заголовка
  • Базовые настройки и тюнинг – тайм-ауты и кэш
  • ARP и QoS
  • ARP и NLB
  • ARP и SNAP
  • ARP и NUD
  • ARP и DAD
  • ARP и WOL
  • ARP и РПГ-7
• Протокол RARP
• Протокол InARP
• Протокол UNARP
• Протокол SLARP
• Протокол DirectedARP
• Безопасность ARP
• Механизм Proxy ARP
• Что такое и как работает Gratuitous ARP
• Cisco ARP Optimization Feature – что это?

Начнём.

Как работает протокол ARP

Протокол Address Resolution Protocol (ARP) используется для простой задачи – выяснить по известному адресу сетевого уровня (IPv4) неизвестный адрес канального уровня (обычно это MAC-адрес 802.3, но возможны и другие варианты).

Данные ARP вкладываются в протокол канального уровня (что напрямую, что через SNAP-заголовок) и являются, если рассуждать по логике “уровень протокола определяется по глубине вложения”, уже не протоколом канального уровня, а вот по функционалу ARP остаётся протоколом канального уровня, т.к. работает в пределах домена широковещания. Это я к тому, что модель OSI надо знать не хорошо, а очень хорошо, и различать два варианта определения “на каком уровне работает данный протокол”.

Например протокол RIPv2 занимается передачей маршрутной информации. Данные этого протокола вкладываются внутрь UDP, и по “глубине вложения” RIP будет “внутри транспортного уровня”. Только вот решать задачу он будет сетевого уровня – маршрутизацию. А допустим его коллега OSPF будет для передачи своих данных использовать не UDP или какой-либо другой протокол транспортного уровня, а напрямую вкладывать свои данные в IP-датаграммы, имея свой личный код вложения. Но при этом заниматься опять-таки будет задачей сетевого уровня – маршрутизации.

Так что будьте внимательны в терминологии – и “протокол выполняет задачи уровня N модели OSI” – это одно, а “протокол технически реализуется как вложение уровня N модели OSI” – другое.

Продолжим про ARP. Для идентификации ARP внутри кадра (в случае с 802.3 Ethernet надо учитывать, что они – кадры – бывают разные) будет использоваться код вложения 0x0806. В состав ARP-пакета будет входить следующие интересные поля:

• Тип оборудования (длина поля – 2 байта): Код, обозначающий тип среды, в которой идёт работа. Для Ethernet’ов это будет единица, готы могут ставить 5 (для протокола Chaos), эстеты – 149.
• Тип протокола сетевого уровня, про который идёт речь в ARP-пакете (длина поля – 2 байта): Стандартный код протокола, такой же, как в 802.3, например. То есть для IPv4 – это 0x0800.
• Длина адреса канального уровня (длина поля – 1 байт): Сколько байт в адресе канального уровня. Например, для 802.3 это будет 6.
• Длина адреса сетевого уровня (длина поля – 1 байт): Сколько байт в адресе сетевого уровня. Например, для IPv4 это будет 4.
• Код операции ARP (длина поля – 2 байта): У операции ARP Request это единица, у ARP Response – двойка. Да, такой вот обильный в плане функционала протокол.
• Адрес канального уровня отправителя (SRC MAC, говоря проще) – уникастовый MAC-адрес интерфейса, с которого отправляется запрос.
• Адрес сетевого уровня отправителя (SRC IP, говоря проще) – уникастовый IP-адрес интерфейса, с которого отправляется запрос. В случае нескольких IP-адресов на интерфейсе – основной адрес интерфейса (primary).
• Искомый адрес канального уровня – в случае ARP – широковещательный 802.3 адрес вида FF-FF-FF-FF-FF-FF. Ведь очевидно, что раз делается ARP-запрос вида “я знаю только искомый IP-адрес”, то искомый адрес канального уровня неизвестен, поэтому сюда пишется “заглушка” из броадкаста. На фактическое распространение она не влияет, т.к. в самом Ethernet-кадре, в котором вложен ARP-запрос, уже указан броадкаст как DST MAC.
• Искомый адрес сетевого уровня – в случае ARP – тот самый IP-адрес, для которого надо найти соответствующий MAC.

Задачи, стоящие перед протоколом, достаточно прозрачны. Как он будет настраиваться?

Базовые настройки и операции с ARP на Windows-системах

Почистить локальный кэш ARP или удалить отдельную запись

Кэш: arp -d

Запись: arp -d ip-адрес

Добавить статическую ARP-запись

arp -s ip-адрес mac-адрес

Детально посмотреть кэш

arp -a -v

Будут видны все типы записей – и static, и dynamic, и invalid. Сам вывод будет разбит по критерию привязки записей к интерфейсам – в начале каждого раздела будет выводиться primary IP интерфейса, а потом его внутренний идентификатор (Вы можете посмотреть табличку интерфейсов и их ID командой netsh int ipv4 sh int).

Есть и более современный вариант отображения кэша:netsh interface ipv4 show nei. В этой команде вывод также разбит по интерфейсам (правда, пишутся их человеческие названия, а не primary IP), статические и системные записи будут называться Permanent, обычные – Reachable (если доступны), Unreacheable (если нет) и Stale (если запись устарела).

Базовые операции с ARP на оборудовании Cisco

Как добавить статическую запись

(config)#arp ip-адрес или “vrf имя-vrf” mac-адрес тип-вложения тип-интерфейса

Из интересного тут разве что тип вложения – можно указать, какой именно вариант вложения (из реально возможных сейчас – ARPA или SNAP) будет у записи. Параметр “Тип интерфейса” можно не указывать.

Настроить включение-выключение ARP и его тип

(config-if)#arp arpa или frame-relay или snap

Как понятно, обычно тип ARP будет ARPA и в модификации нуждаться тоже особо не будет. Внимание – типы не являются взаимоисключающими – т.е. можно сделать и arp arpa и arp snap, и это лишь покажет, что на данном интерфейсе надо обрабатывать и тот и тот варианты.

Настроить время нахождения записи в ARP-кэше

(config-if)#arp timeout секунды

Настройка идёт на интерфейсе, т.к. данный тайм-аут будет только у записей в ARP-кэше, сделанных через этот интерфейс.

Очистить кэш ARP

Весь:

#clear arp-cache

Отдельную запись:

#clear arp-cache ip-адрес

Все записи, привязанные к конкретному интерфейсу:

#clear arp-cache интерфейс

Настроить работу с incomplete ARP records

Данные настройки будут нужны, чтобы задать поведение системы в случае “Я точно знаю, что есть сосед с таким IP-адресом, но у меня нет его MAC-адреса”.

Вы можете задать общее число таких адресов, находящихся “в процессе поиска”, а также количество попыток

Включение:

(config)#ip arp incomplete enable

Количество адресов:

(config)#ip arp incomplete entries число

Количество попыток:

(config)#ip arp incomplete retry число

Базовый тюнинг ARP – тайм-ауты и кэш

В NT 6.0 сетевой стек был ощутимо изменен (приведён в соответствие с RFC 4861), поэтому то, что действовало для XP/2003, работать в большинстве своём не будет. Схема работы ARP-кэша теперь следующая:

• Есть кэш “соседей” – для IPv4 и IPv6
• Запись туда идёт после получения ARP-ответа, после чего у строки кэша появляется статус “Reachable”
• Статус теряется в случае отказа интерфейса или по тайм-ауту – если прошло более “ReachableTime” секунд, то статус меняется на “Stale”
• Если хочется отправить пакет узлу, строка кэша для которого находится в состоянии “Stale”, то предварительно надо отправить ARP-запрос

Как точнее считается время? Формула подсчёта такова:

ReachableTime = BaseReachableTime * (случайный коэффициент между MIN_RANDOM_FACTOR и MAX_RANDOM_FACTOR)

Параметры, от которых идёт вычисление, выглядят так: BaseReachableTime = 30 секунд, MIN_RANDOM_FACTOR = 0.5, а MAX_RANDOM_FACTOR – 1.5. Параметр BaseReachableTime изменяем командой:

netsh interface ipv4 set interface имя интерфейса basereachable=количество миллисекунд

Заметьте, для каждого интерфейса это устанавливается отдельно. Ранее действовавшее общесистемное значение по умолчанию в 120 секунд, таким образом, теперь не актуально. Я бы рекомендовал увеличить это значение до тех же 2х минут, что были раньше – количество трафика снизится, а минусов практически нет – узлы, которые сменят MAC за время устаревания кэша, сами об этом уведомят.

В случае работы с оборудованием Cisco, данный параметр – тайм-аут записи в ARP-кэше – задаётся на интерфейсе командой:

arp timeout время в секундах

и имеет базовое значение в 14400 (это 4 часа).

Суммарный же объём кэша IPv4-соседей можно установить так:

netsh interface ipv4 set global neighborcachelimit=количество

По умолчанию их 256. Как понятно, в случае, если соседей по среде передачи данных мало (например, есть единственный сетевой интерфейс в сеть с маской /28), этот кэш увеличивать не надо, а уменьшить вполне можно. Помните, это именно кэш ARP, т.е. явных адресов соседей по vlan плюс служебных мультикастов. Нет смысла его раздувать до огромных габаритов, если в сети банально мало узлов, нечего кэшировать особо будет.

Давайте теперь чуть углубимся.

ARP и QoS

В случае, когда сетевой интерфейс загружен трафиком, часть трафика может теряться. Увы, ни один из методов queuing не является от этого панацеей. Начиная с Cisco IOS 15.1 можно указать, что на данном интерфейсе необходимо всегда обрабатывать ARP-пакеты в первую очередь, что может значительно сократить процент потери ARP-данных. На общую загрузку это, как понятно, повлияет мало, а вот пользы может принести много. Ведь ARP-пакеты передаются без механизма подтверждения доставки и терять их не очень хорошо.

Данный механизм включается на L3-интерфейсах, командой:
arp packet-priority enable

Выключается, как понятно, no arp packet-priority enable. В Windows аналогичной процедуры нет.

ARP и NLB

Чтобы ARP дружил с NLB, он должен обрабатывать ситуацию, когда придёт ARP-запрос с не-юникастового адреса. То есть, смотрите ситуацию. Допустим, есть NLB, который работает в мультикастовом режиме. Два хоста, соответственно, прикидываются одним IP-адресом, отвечая на ARP-запросы про этот адрес общим мультикастовым MAC’ом, и потом договариваясь друг меж другом, что делать с пришедшим трафиком. Вот чтобы эта схема работала, надо, чтобы когда этот “общий виртуальный узел”, который обладает виртуальным IP и мультикастовым MAC, решил узнать через ARP чей-то MAC, ему вообще ответили. Потому что есть тонкость – у мультикастового MAC есть характерный вид, по которому понятно, что он мультикастовый. А не-юникастовые source MAC в общем-то не являются нормальной ситуацией и нуждаются в особой обработке. Соответственно, для этого надо явно включить обработку ситуации “к нам пришёл ARP-запрос от товарища, у которого обратный MAC-адрес не-юникастовый”. Делается это путём установки параметра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableBcastArpReply

в единицу. Если она будет в нуле – в ряде ситуаций поимеете проблемы с NLB.

ARP и SNAP

По умолчанию, ARP вкладывается в 802.3 кадр простым, Ethernet II способом. Это можно поменять в случае, если необходима поддержка SNAP-механизма, который, как известно, нужен для мультиплексирования потоков данных на канальном уровне. Напомню, что по RFC 1042 данные IP и ARP всегда передаются поверх 802.x сетей используя связку LLC+SNAP, за исключением обычного Ethernet (802.3), где они вкладываются напрямую (см. RFC 894).

Для этой задачи есть ключ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ArpUseEtherSNAP

По умолчанию он в нуле, установив в единицу Вы получите ситуацию, что ARP-запросы будут вкладываться в SNAP (притом в LLC+SNAP, что увеличит суммарный размер кадра на 3+5=8 байт).

ARP и NUD

NUD – это Neighbor Unreachability Detection. По умолчанию включается на интерфейсах, которые смотрят в broadcast-среды, и выключается на других. Помогает узнать о том, что сосед (что обычный, что шлюз) перешёл в нефункциональное состояние до времени, пока его запись в ARP-кэше стала Stale. Механизм полезный, поэтому его рекомендуется включать в явном виде. Делается это командой:

netsh int ipv4 set int имя интерфейса nud=enabled

ARP и DAD

DAD – это Duplicate Address Detection. То самое, что не даёт взять себе адрес, который уже есть у кого-то. Проводится путём отправки Gratuious ARP, про который чуть ниже. Тюнингуется достаточно просто, двумя параметрами:

netsh int ipv4 set int имя интерфейса retransmittime=миллисекунды

netsh int ipv4 set int имя интерфейса dadtransmits=попытки

По умолчанию retransmittime – т.е. время между попытками обнаружить соседа, который уже занял адрес – 1 секунда, количество попыток dadtransmits – 3. Можете сократить их, если уверены, что все соседи отвечают достаточно быстро, это уменьшит время инициализации интерфейса – система не будет ждать “вдруг кто проснётся и скажет, что адрес уже занят”.

ARP и WOL

Функция Wake-On-Lan, думается, хорошо Вам известна. Она нужна, чтобы узел “проснулся” в определённый момент – когда увидит на сетевом интерфейсе соответствующие неким условиям данные. Обычно это данные, напрямую идущие на данный узел, притом содержащие некую последовательность – Magic Pattern. Так вот, можно заранее указать условие – будет ли данный Magic Pattern искаться вообще во всех сетевых данных, которые попадут на нужный узел, либо только не некоторых. В частности, так как статья про ARP, есть настройка, позволяющая установить для интерфейса условие – анализировать ли на предмет наличия Magic Pattern’а пакеты протоколов ARP (для IPv4) и ND (для IPv6). Включается следующим образом:

netsh int ipv4 set int имя интерфейса forcearpndwolpattern=enabled

Как выключается, надеюсь, понятно. Рекомендуется к выключению на узлах, у которых нет задачи просыпаться по WOL, т.к. ускоряет обработку путём раннего отбрасывания механизмом поиска Magic Pattern указанных пакетов.
Теперь про RARP.

Протокол RARP

RARP – это как ARP, только наоборот. Логично. По сути, RARP – это очень сильно простой сервис по динамическому конфигурированию узлов. Он ведь отрабатывает задачу, обратную ARP.

ARP: Я знаю искомый L3-адрес, дайте мне соответствующий ему L2-адрес.
RARP: Я знаю искомый L2-адрес, дайте мне соответствующий ему L3-адрес.

У RARP-сервера есть табличка соответствий MAC и IP-адресов, из которой он берёт указанную информацию и отправляет её. Различия на технологическом уровне будут следующими: RARP-пакеты будут иметь код вложения 0x8035, плюс коды операций у них будут 3 для RARP-запроса и 4 для RARP-ответа.

Вообще, RARP сейчас практически не используется, но если хотите почитать – есть RFC 903.

Реализация RARP-сервера в Windows

Её нет. Если хочется стороннее решение, то можно скачать RARP windows server быстро бесплатно без sms.

Реализация RARP-сервера на оборудовании Cisco

Она есть. Конфигурируется в несколько этапов. По порядку:

Шаг первый: Добавляем запись для потенциального RARP-клиента (т.е. того, кто хочет получить IP-адрес). В глобальной конфигурации:

(config)#arp ip-адрес mac-адрес-клиента arpa

Шаг второй: Разрешаем на интерфейсе, в качестве параметра – тот адрес на интерфейсе, от которого отправляем RARP-ответы.

(config-if)#ip rarp-server ip-адрес

Протокол InARP (Inverse ARP)

InARP – специальная модификация ARP для не-broadcast сетей (например, Frame Relay или ATM). Суть проста – в сетях, где нет широковещания, обычный ARP работать не сможет, а задачи, которые им решаются, никуда не пропадают. Соответственно, нужна схема работы. Она будет достаточно интересна и проста. Узел, который поддерживает InARP, будет самостоятельно с указанной периодичностью отправлять в субинтерфейсы, поддерживающие InARP (например, в FR’овские), InARP-сообщения, в которых будет указано что-то вида “привет, я от узла с сетевым адресом таким-то”. Соответственно, принимающая сторона, получая такое сообщение из-под субинтерфейса с DLCI=abc, будет записывать у себя в таблицу – “За DLCI abc живёт товарищ с IP xyz“. В общем-то и всё.

Другие отличия будут состоять в использовании других кодов операций – 8 для запроса InARP, 9 для ответа. Ну и в механизме вложения – понятное дело, в Q.922 вкладываться – это не в 802.3

Протокол UnARP

Предлагался в RFC 1868. Суть проста – сам формат пакета ARP не менялся, добавлялся лишь новый тип сообщения – сообщение вида “Я ушёл из сети”. Т.е. задачей дополнения UNARP являлось то, что узлы, которые отключаются, могут послать сообщение “Стирайте меня все из ARP-кэшей”, чтобы остальные не ждали время окончания кэширования записей. К сожалению, не поддерживается (основная причина – небезопасен, т.к. такое сообщение легко подделать).

Протокол SLARP (Serial Line ARP)

Специальный субпротокол, работающий внутри цисковского варианта HDLC (который обычно cHDLC). Используемый код вложения – 0x8035. Протокол простой, но интересный тем, что может делать две штуки – проверять состояние канала, периодически передавая кадры, и назначать IPv4-адреса в случае, если с одной стороны serial link адрес IPv4 есть, а с другой – нет. Адрес назначается по логике “Если у меня последний бит адреса 1, предложить такой же, но с нулём, и наоборот”. Маска предлагается такая же, как у себя.

Формат кадра будет такой:

• Адрес (один байт) – стандартный адрес вида b1111111 из xHDLC/PPP.
• Контроль (один байт) – то же самое, опять LLC3, т.е. b00000011.
• Код протокола вложения (два байта) – личный номер SLARP, 0x8035.
• Код операции (один байт) – вариант или Address request(0x00), или address reply (0x01), или Keep-alive (0x02).
• IPv4-адрес и маска (два раза по 4 байта) – предлагаемый партнёру по serial link адрес.
• Резерв (один байт) – вечно 0xFF.
• FCS в варианте CRC-16 (два байта)
• Флаг (один байт) – стандартный флаг xHDLC вида b0111110.

Протокол DirectedARP

Протокол описан в RFC 1433. Сейчас как отдельный протокол не используется, хотя многие мысли, высказанные в этом RFC, достаточно дельные и повлияли, например, на формирование современного IPv6.

Безопасность ARP

В общем-то, в ARP нет никаких встроенных средств безопасности. Это очень простой служебный протокол, поэтому о какой-то отдельной защите его говорить трудно. Можно высказать лишь общие мысли – например, что в случае малого количества хостов проще ввести все их IP-MAC соответствия как статические – в этом случае ARP они передавать перестанут (в кэше-то записи про соседей будут всё время), а если кто-то злонамеренный специально передаст поддельный ARP-ответ, то никакого влияния он не окажет – динамически полученный ARP-ответ не перезапишет собой статическую запись.

Есть ряд дополнительных механизмов (которых достаточно много), которые могут помочь в этом вопросе. Например, на оборудовании Cisco есть команда:

arp authorized

которая, в случае включения на интерфейсе, отключит динамические записи в кэш ARP. Т.е. интерфейс перестанет слушать ARP-ответы от неизвестных клиентов и дополнять ими кэш ARP.

Для ряда моделей оборудования (например, на старших линейках маршрутизаторов – это 7600) можно задать в режиме глобальной конфигурации максимальный размер ARP-кэша для устройства (по умолчанию он не ограничен и составляет 256.000 записей):

ip arp entry learn количество

Есть, в общем-то, множество доп.механизмов безопасности ARP – тот же DAI или ARP ACL, про которые, возможно, я тоже допишу сюда.

Механизм Proxy ARP

Суть механизма Proxy ARP, детально обозначенного в RFC 1027, проста – дать возможность узлу, который в силу каких-то причин (например, у него не указан шлюз по умолчанию) не может понять, куда маршрутизировать трафик для других сетей, всё же сделать это. Притом сделать просто – используя то, что в сегменте с этим узлом присутствует добрый узел, на котором включен Proxy ARP, и который, увидев что узел пытается через ARP-запрос найти получателя трафика, “прикинется” этим получателем и ответит на запрос.

Т.е. вот есть маршрутизатор, на котором включен Proxy ARP. Он получает ARP-запрос на разрешение адреса узла, который находится в другом сегменте относительно спрашивающего и помогает – просто отвечает ему от имени этого узла. Соответственно, этот роутер и будет передавать трафик между данными узлами, а отправитель будет думать, что отправляет трафик напрямую.

Данный механизм включен “по умолчанию” на большинстве систем и нуждается в отключении – т.е. описанная ситуация, в общем-то, по производственной необходимости возникает довольно-таки редко.

Как включить Proxy ARP на оборудовании Cisco

Зайдите на нужный интерфейс и введите там команду:

(config-if)#ip proxy-arp

Выключить глобально – (config)#ip arp proxy disable.

Как включить Proxy ARP в Windows

В случае, когда у Вас используется RRaS, proxy ARP работает автоматически.

Что такое и как работает Gratuitous ARP

Это страшное слово переводится как “самопроизвольный” ARP. Суть события в следующем. Любой узел, который инициирует новый интерфейс, на котором есть поддержка ARP, должен при завершении процесса конфигурирования IP-адреса (статически ли, по DHCP, через APIPA’у – без разницы) уведомить соседей о том, что он появился. Делается это при помощи отправки одиночного ARP Reply, в котором указывается, что логично, связка “мой MAC – мой новый IP”. Т.е. выглядит этот ARP-ответ несколько странно с точки зрения классической схемы работы ARP – узел рассылает на броадкастовый MAC и свой IP информацию о своём настоящем MAC и своём же IP. Т.е. совпадают SRC IP и DST IP.

Примечание: По сути, этот механизм – это “форсированное” обновление ARP-кэша соседей новой информацией – “теперь я по этому MAC-адресу”. Заодно, именно благодаря этому механизму, происходит обнаружение дублирующихся IP-адресов – тот, кто пытается присвоить себе IP-адрес, рассылая это уведомление “засветится”.

Но, в общем-то, мы и договорились, что это – исключительная и разовая ситуация. Казалось бы, в чём проблема-то?

Проблема в том, что когда такое происходит на сервере удалённого доступа, к которому подключено несколько клиентов (более 1, по сути), то этот сервер при подключении каждого своего клиента получает от него данный стартовый запрос ARP и ретранслирует запрос далее, выступая, по сути, прокси. В результате, допустим, порт коммутатора, в который включен этот сервер, впадает в тягостные размышления о здоровье сервера, который постоянно сообщает всей сети о том, что за его MAC-адресом интерфейса (того, который воткнут в коммутатор) очень много IP-адресов, и все они разные. И каждый раз, когда клиент будет подключаться (например, VPN-канал переподключит, или другим способом вызовет переход через NCP-фазу PPP), такой ARP-ответ будет создаваться и отправляться серверу, а тот будет отдавать его дальше – чтобы уведомить сеть, что трафик на такой-то IP-адрес надо отправлять на его, сервера, MAC, а дальше он уж сам разберется.

Соответственно, в ряде ситуаций (например, много клиентов, краткие сессии) такой механизм надо отключать. Зачастую проще привязать статически целую пачку ARP-соответствий (например, когда на сервере удалённого доступа выделен пул в 20 адресов, и абоненты подключаются, делают какую-то краткую операцию и отключаются), чем постоянно форвардить в сеть эти ARP Reply.

Примечание: На самом деле, делать это надо с умом, как и всё остальное. Есть ситуации, когда gratuitous ARP является штатным и нужным. Например, у Вас сделан HSRP-балансировщик. Активный узел упал – второй становится активным. И в этот момент он тоже “просто так, внезапно” отправит gratuitous ARP – чтобы сразу уведомить всю сеть, что теперь у виртуального IP новый MAC, а не ждать, пока у всех узлов кончится тайм-аут кэша.

Как настроить Gratuitous ARP на оборудовании Cisco

Включить:

router(config)#ip gratuitous-arps

Если добавить в конце команды слово non-local, то будет обрабатываться вышеописанная ситуация с PPP.

Отключить приём всех gratuitous ARP’ов:

router(config)#ip arp gratuitous none

Включить приём только gratuitous ARP’ов, source которых из connected-сетей:

router(config)#ip arp gratuitous local

Как настроить Gratuitous ARP на Windows Server

Для указанного сценария с RRaS – никак. Ваш RRaS-сервер не будет передавать стартовый ARP-запрос, полученый от PPP-клиента, в другие сети, поэтому ситуация, описанная выше, просто не возникнет.

Управлять же Gratuitous ARP со стороны узла вполне можно. Для этого есть ключ реестра:

HKLM\System\CurrentControlSet\Services\TcpIp\Parameters

а в нём – параметр ArpRetryCount типа DWORD32. Если поставить этот параметр в нуль, то механизм будет выключен. По умолчанию Windows-хосты делают Gratuitous ARP три раза – сразу после инициализации адреса, потом через 1/2 секунды, потом через ещё 1/10 секунды. Можете поставить единицу, если уверены в качестве работы сети и её не-критичной загруженности на момент выхода ARP Reply – “сэкономите трафик”.

Примечание: Считаются фактически отправленные ARP, а не попытки. Т.е. если среда была недоступна, то все равно отправят три, просто чуть позже.

Примечание: Если поставить нуль, то вдобавок отвалится функция обнаружения конфликтов DHCP, но это будет в другой истории.

Cisco ARP Optimization Feature – что это?

Это достаточно полезное архитектурное изменение, появившееся в релизах IOS 12.0 – 12.2 и закрепившееся в более поздних. Идея проста. Устройство хранит информацию о связках IP-MAC-интерфейс в отдельной таблице. Эта таблица организована для быстрого поиска информации по известному IP-адресу. Соответственно, этот механизм эффективен, когда надо обработать единичный пакет. В ситуации же, когда интерфейс попеременно переходит из состояния включения в выключенное и наоборот (interface flapping), надо сразу же обработать в этой таблице все ARP-записи, относящиеся ко всем IP и MAC, находящимся за данным интерфейсом. Вот фича Cisco ARP Optimization как раз умеет делать эту операцию – например, очистить все записи за соответствующий интерфейс. Выигрыш – резко сниженная загрузка CPU, которому надо обработать событие “падение интерфейса”.

Как настроить Cisco ARP Optimization Feature

Никак – это просто другая структура хранения данных ARP в оперативной памяти, используемая в современных версиях IOS.

Заключение

Если я вспомню ещё что-то, или меня наведут на мысль, то обязательно напишу сюда в качестве дополнения к статье.

Платформа Windows Server остается одной из наиболее популярных серверных платформ, в том числе и для реализации решений удаленного доступа. Служба маршрутизации и удаленного доступа (RRAS) позволяет быстро и достаточно просто развернуть VPN-сервер практически для любых нужд. Сегодня мы еще раз вернемся к этому вопросу и рассмотрим, как создать на базе Windows Server PPTP или L2TP сервер для удаленного доступа, как наиболее востребованный сценарий на сегодняшний день.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Почему именно эти типы подключения? Потому что они наиболее просты в реализации и поддерживаются широким спектром клиентов что называется «из коробки». Однако следует помнить, что PPTP не является на сегодняшний день безопасным и имеет слабые алгоритмы шифрования, но при этом он наиболее производительный из VPN-протоколов и имеет минимальные накладные расходы. Кроме того, его поддержка исключена из операционных систем Apple.

Оптимальным вариантом будет использование L2TP/IPsec подключения, которое сочетает в себе простоту, поддержку практически любыми клиентскими ОС и устройствами вместе с неплохим уровнем безопасности, обеспечиваемым IPsec. А так как настройка сервера для этих видов подключений практически идентична, то мы решили объединить их в одну статью.

Установка и настройка службы маршрутизации и удаленного доступа

Для начала работы с VPN в среде Windows Server вам потребуется установить роль Удаленный доступ, это делается стандартными средствами и не должно вызвать затруднений.

Картинка с сайта: interface31.ru

В Службах ролей выбираем Маршрутизация, роль DirectAccess и VPN (RAS) будет добавлена автоматически.

Картинка с сайта: interface31.ru

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

Картинка с сайта: interface31.ru

В появившемся окне выбираем пункт Развернуть только VPN.

Картинка с сайта: interface31.ru

Затем в оснастке Маршрутизация и удаленный доступ щелкаем правой кнопкой мыши по строке с сервером и выбираем в выпадающем меню Настроить и включить маршрутизацию и удаленный доступ.

Картинка с сайта: interface31.ru

После чего появится хорошо знакомое окно мастера настройки, предлагающее сразу несколько типовых конфигураций, однако у него есть свои особенности, например, если у вашего сервера всего один сетевой интерфейс, то настроить вариант Удаленный доступ (VPN или модем) мастер вам не даст. Поэтому выбираем самый нижний пункт — Особая конфигурация.

Картинка с сайта: interface31.ru

В следующем окне достаточно поставить галочку Доступ к виртуальной частной сети (VPN) и завершить работу мастера.

Картинка с сайта: interface31.ru

После завершения работы мастера служба Маршрутизации и удаленного доступа будет запущена и можно приступить к настройке сервера удаленного доступа. Если же данная служба у вас уже установлена и настроена в иной конфигурации, то щелкните правой кнопкой по строке сервера и выберите Свойства, в открывшемся окне на закладке Общие установите опции: IPv4-маршрутизатор локальной сети и вызова по требованию и IPv4-сервер удаленного доступа.

Настройка PPTP и/или L2TP сервера удаленного доступа

Откроем оснастку Маршрутизация и удаленный доступ и перейдем к свойствам сервера через одноименный пункт в меню правой кнопки мыши, прежде всего убедимся, что настройки на закладке Общие соответствуют приведенным на скриншоте выше. Затем переключимся на закладку Безопасность и убедимся, что в качестве Поставщика службы проверки подлинности стоит Windows — проверка подлинности, а Поставщик учета — Windows-учет, еще ниже установим флаг Разрешить пользовательские политики IPsec для L2TP- и IKEv2-подключения и в поле Общий ключ укажите парольную фразу для предварительного ключа.

Картинка с сайта: interface31.ru

Нажав на кнопку Методы проверки подлинности откроем окно, в котором выберем только Протокол EAP и Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2), остальные протоколы не являются безопасными и должны быть отключены.

На закладке IPv4 укажем опцию Назначение IPv4-адресов — Статический пул адресов и добавим новый пул для выдачи адресов из него удаленным клиентам. Количество адресов должно быть не менее количества клиентов плюс один адрес, так как первый адрес из пула присваивается серверу. Что касается самого диапазона адресов, то его выбор зависит от конфигурации сети, если вы будете использовать маршрутизацию, то он не должен пересекаться с локальной сетью, если же хотите использовать ProxyARP, то наоборот, должны выделить принадлежащий локальной сети диапазон. В нашем случае используется второй вариант.

Картинка с сайта: interface31.ru

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

Картинка с сайта: interface31.ru

Также не забудьте проверить настройки брандмауэра, чтобы убедиться, что правила Маршрутизация и удаленный доступ GRE-входящий, PPTP-входящий (для PPTP) и L2TP-входящий (для L2TP) включены.

Картинка с сайта: interface31.ru

Proxy ARP

Сетевое взаимодействие в пределах одной IP-сети осуществляется на канальном (L2) уровне, в сетях Ethernet для этого используются MAC-адреса устройств. Для того, чтобы выяснить MAC-адрес узла по его IP применяется протокол ARP (Address Resolution Protocol), использующий широковещательные запросы, на которые отвечает только обладатель указанного IP-адреса. Выдавая удаленным клиентам адреса из диапазона основной сети мы как бы помещаем их в общую IP-сеть, но так как VPN — это соединение точка-точка, ARP-запросы от удаленных клиентов в сеть попадать не будут, единственный узел который их получит — сам VPN-сервер.

Для решения данной проблемы используется технология Proxy ARP, которая, как понятно из названия, представляет прокси-сервер для ARP-запросов, позволяя удаленным клиентам работать так, как будто бы они действительно находились в одной сети, без каких-либо дополнительных настроек. При использовании RRAS никаких дополнительных действий делать не нужно, Proxy ARP работает по умолчанию.

VPN-сервер за NAT

Так как мы используем Windows Server, то с большой долей вероятности он будет находиться внутри сетевого периметра и нам понадобится настроить проброс портов на маршрутизаторе. Для этого нужно четко понимать, как работает VPN-соединение и какие порты и протоколы следует передавать.

Начнем с PPTP, прежде всего клиент устанавливает управляющее TCP-соединение на порт 1723, затем, после успешной аутентификации создается соединение для передачи данных с использованием протокола GRE.

Таким образом для работы PPTP-сервера за NAT нужно:

• пробросить порт 1723 TCP
• разрешить прохождение GRE-трафика

С первым понятно, а вот с GRE могут возникнуть затруднения. Если вы используете маршрутизатор на базе Linux, то обратитесь к следующей нашей статье, если оборудование Mikrotik, настроенное по нашей инструкции, то достаточно пробросить только 1723 TCP, прохождение GRE будет разрешено конфигурацией брандмауэра, в остальных случаях следует обратиться к документации на свою модель маршрутизатора.

С L2TP сложнее, точнее не с ним самим, а с IPsec, который не поддерживает NAT. Для обхода этих ограничений используется протокол NAT-T, который инкапсулирует пакеты IPsec в UDP, позволяя успешно проходить через NAT. Поддержка данного протокола включена по умолчанию практически во всех ОС, кроме Windows. Для включения поддержки NAT-T следует внести изменения в реестр, найдите ветку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

И создайте в ней параметр DWORD c именем AssumeUDPEncapsulationContextOnSendRule и значением 2.

Это можно быстро сделать при помощи PowerShell:

Set-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Type DWORD -Value 2 -Force

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

При установлении L2TP/IPsec соединения между узлами прежде всего создается зашифрованный IPsec-канал, для этого используется протокол обмена ключами IKE (порт 500 UDP) и протокол NAT-T (порт 4500 UDP), затем уже внутри безопасного IPsec-соединения поднимается L2TP-туннель на порт 1701 UDP и происходит аутентификация пользователя.

Обратите внимание, аутентификация пользователя в L2TP, в отличии от PPTP, происходит внутри защищенного IPsec-канала, что делает данный тип соединения более безопасным.

Таким образом для работы L2TP/IPsec сервера за NAT нужно:

• пробросить порт 500 UDP
• пробросить порт 4500 UDP
• внести изменения в реестр для включения NAT-T как на сервере, так и на клиенте (только для Windows)

Вопреки распространенному заблуждению порт 1701 UDP пробрасывать не нужно.

Настройка VPN-подключения в Windows

С одной стороны это простой вопрос, с другой — имеются определенные тонкости, на которые мы как раз и обратим внимание. В Windows 10 для первичной настройки VPN-подключения служит современное приложение, которое предельно простое и не охватывает дополнительных настроек.

Картинка с сайта: interface31.ru

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

Картинка с сайта: interface31.ru

Затем на закладке Безопасность установите в Шифрование данных — обязательное, а в пункте Проверка подлинности выберите Протокол расширенной проверки подлинности (EAP).

И наконец на закладке Сеть перейдите в свойства протокола IP версии 4 (TCP/IP 4) и нажмите Дополнительно, в открывшемся окне снимите флаг Использовать основной шлюз в удаленной сети, в противном случае весь исходящий трафик будет направлен в туннель.

Картинка с сайта: interface31.ru

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

Настройка VPN-подключения в Linux

В данной части нашего материала мы будем рассматривать настройку клиентских Linux-систем при помощи графического окружения и Network Manager, настройка серверных систем выходит за рамки текущей статьи. В качестве примера мы будем использовать Ubuntu, но все сказанное будет справедливо для любых основанных на Debian систем, а с некоторыми уточнениями — для любых дистрибутивов.

Поддержка PPTP присутствует практически в любом дистрибутиве по умолчанию. Достаточно перейти в Настройки — Сеть и добавить новое VPN-подключение.

Картинка с сайта: interface31.ru

Заполняем основные настройки: адрес сервера, имя и пароль пользователя.

Картинка с сайта: interface31.ru

Затем нажимаем кнопку Дополнительно и в открывшемся окне в разделе Аутентификация оставляем только MSCHAPv2, обязательно включаем Использовать шифрование MPPE и выбираем ниже 128 бит (наиболее защищенное), также устанавливаем флаг Включить Stateful Encryption для уменьшения накладных расходов на шифрование. Флаги сжатия оставляем включенными.

Картинка с сайта: interface31.ru

Закрываем данное окно с сохранением данных и переходим на закладку IPv4, где в разделе Маршрутизация устанавливаем флаг Использовать это подключение только для ресурсов этой сети, в противном случае в туннель пойдет весь трафик узла.

Картинка с сайта: interface31.ru

На этом настройка подключения завершена, можно подключаться.

Для работы с L2TP потребуется установить дополнительные пакеты:

apt install network-manager-l2tp-gnome

После чего в доступных типах подключения появится L2TP. Основные настройки ничем не отличаются от PPTP, также адрес сервера, имя и пароль пользователя.

Картинка с сайта: interface31.ru

Затем откроем Настройки PPP, в разделе Аутентификация также выберем только MSCHAPv2, а вот опции шифрования оставляем выключенными, так как чистый L2TP шифрования не использует, для защиты канала здесь применяется IPsec. Флаги сжатия также оставляем установленными по умолчанию.

Картинка с сайта: interface31.ru

Затем переходим в Настройки IPsec, это наиболее сложная и ответственная часть настроек, так как от них напрямую зависит безопасность соединения. В поле Pre-shared key введите Общий ключ, а ниже потребуется указать используемые шифры. Большинство материалов в сети интернет копируют друг у друга откровенно старые и слабые наборы шифров, что не соответствует реалиям сегодняшнего дня, хотя соединение с такими значениями будет работать. Мы же будем использовать максимально безопасные значения, для этого в поле Phase1 Algorithms укажите aes256-sha1-ecp384, а в поле Phase2 Algorithms — aes256-sha1.

Также имеет смысл установка флага Enforce UDP Encapsulation, который принудительно включает NAT-T, в случае если вы точно знаете, что ваш сервер находится за NAT, без этой опции протокол включается автоматически при обнаружении первого устройства с NAT.

Картинка с сайта: interface31.ru

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

Картинка с сайта: interface31.ru

На этом настройка закончена, можно подключаться.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Proxy ARP is the answering of ARP Requests on behalf of another node. As RFC 925 describes, Proxy ARP is used in situations in which a subnet is divided without the use of a router. A proxy ARP device is placed between nodes on the same subnet. The proxy ARP device is aware of which nodes are available on which segment. The proxy ARP device also answers ARP Requests and facilitates the forwarding of unicast IP packets for communication between nodes on separate segments. The existence of the proxy ARP device is transparent to the nodes on the subnet. A proxy ARP device is often physically a router device; however, it is not acting as an IP router, forwarding IP datagrams between two IP subnets. Figure 3-3 shows an example of a proxy …

Introduction

Proxy ARP is a feature often used together with Network Address Translation (NAT) on an internet-facing firewall to enable access to services residing in your networks DMZ from the internet, especially if your firewall is only connected to a single Internet Service Provider (ISP) and you only have a single, small public IP-address space assigned to your network.

In this scenario, you will also need Proxy ARP if you are hiding/publishing internal servers or networks behind a public IP address that is on the SAME network as the IP address of the firewall’s internet-facing interface.

While Proxy ARP is most often used when it comes to connecting your network to the internet, the feature can also be used inside your network (although I’d argue that a properly designed network really shouldn’t need to use Proxy ARP internally).

Bigger enterprise networks usually have a dedicated transit network (often referred to as a «linknet») between the ISP’s router and the customer’s firewall’s outside interface, with public IP addresses configured on both sides. Thanks to the dedicated transit network, Proxy ARP is not needed here at all. However, in smaller networks, you sometimes can’t afford to «waste» public IP addresses by carving out a small IP network and assigning it the connection between the ISP and your firewall, and this is where Proxy ARP comes in.

Using Proxy ARP, you can instruct your firewall to act as a proxy for all traffic that is sent to IP-addresses other than the one that is configured on the actual outside interface of the firewall, and then NAT is used to make sure that the traffic ends up at the correct server on your Inside network or your DMZ network.

I am not going to go into the details of Proxy ARP, if you are unsure what this feature does I suggest reading up on it first before continuing forward with this article.

I have worked with other firewall brands than Check Point and the Proxy ARP feature has never been a big deal to set up, and it’s often done automatically; once you set up the NAT-rule that translates the public IP address to the internal IP address on the server on your inside network or in your DMZ you are usually done, but on Check Point Security Gateways the setup is a bit different as there are multiple ways to configure Proxy ARP.

Proxy ARP settings also differ depending on if you are running your gateways in «normal» mode or VSX-mode. This article only covers how to configure Proxy ARP in normal mode, not in VSX-mode.

Basic topology

Let’s take a look at how it works. We are going to test some settings based on this simple network topology:

The Inside network is 192.168.138.0/24, where the Security Management Server (“SMS”) and a Windows 10 test-PC resides.

The Outside network is 192.168.247.0/24, while this is typically not IP addresses used on the «outside» interface, it is this way because my lab environment is in VMware and not in a real, production network.

We have two gateways (SG1 and SG2) running in High Availability-mode and the virtual IP-address («VIP») used on both the Inside and the Outside network ends with .254.

At the end of this article, we will have configured the Proxy ARP/NAT below:

We will start by configuring a wider Proxy ARP/NAT-rule that all traffic from the Inside network (192.168.138.0/24) will use to be translated to outside IP-address 192.168.247.100, and after that, we will review two different ways of configuring other, more specific Proxy ARP-entries/NAT-rules for the Windows 10 test-PC and another one for the Security Management Server itself.

Create an Object with included NAT

When you create a Network or Host Object on your gateways, you can directly add NAT by clicking the NAT tab on the left side of the Object’s window.

By checking the box for Add automatic address translation rules, a NAT rule will automatically be created in the NAT section of your Security Policy.

While the outside IP address of the gateway is .254 in this lab topology, we might want to use some other IP address to NAT traffic when clients in the Inside network want to connect to the internet.

As an example, we are going to use Object NAT to “Hide NAT” our whole Inside network behind IP-address .100, as the image below shows.

Starting in R80.40, there is a Gaia CLI command called show security-gateway arp-table that shows the same output as fw ctl arp does, because fw ctl arp has actually been moved to only work in Expert-mode going forward.

And that’s it for Object NAT! The inside network is now able to connect to the internet through the gateway.

!!!! Keep in mind that Object NAT is not bound by a source- and destination interface, so if you have more than one internal interface on your gateway, traffic between these two interfaces will be translated as well, which makes packet flows hard to follow and can mess up connections that might need to go to other gateways/firewall further down that interface/zone.

In this case, you would need a manually configured so-called No-NAT rule higher up in the NAT section that disables NAT for traffic from all internal networks, to all internal networks.

Manually Configuring Proxy ARP (without Object NAT)

Personally, I am not a fan of configuring NAT directly inside Objects as it can make packet processing unclear and hard to read as you’re scrolling through your NAT rules. I must say though, configuring Proxy ARP manually is also a real hassle, unfortunately.

Luckily, if we don’t want to use NAT inside Object to do Proxy ARP, we can configure it manually in Gaia using either Clish or the web-GUI. I will leave the Object NAT-rule configured previously as it is, and now instead create Proxy ARP and NAT-settings to assign «public» IP-address to resources on the Inside network, which is my Windows 10 test-PC at IP-address 192.168.138.10 and my Security Management Server at IP-address 192.168.138.100.

To allow for the creation of manual Proxy ARP-entries, we first need to enable that type of configuration in the settings of the Security Management Server and Publish + Install Policy on the Gateways to enable the configuration on them.

head to the Global Properties inside the Security Management Server (click on the icon in the very top left of SmartConsole-application and then on Global Properties) and go to the Firewall > NAT — Network Address Translation session as per the image below.

Make sure to check the boxes for both Automatic ARP configuration and Merge manual proxy ARP configuration.

Click on OK and then Publish/Install Policy on your gateways.

We are now ready to manually create Proxy ARP-entries using either Clish or the web-GUI.

Alt.1) Manual Proxy ARP-entries using Gaia Clish

For this example, we are going to configure Proxy ARP + NAT to translate the IP address of the Windows 10 test-PC on the inside network to IP-address 192.168.247.50 as it passes through the gateway towards the internet.

In Clish there are also two ways of configuring Proxy ARP-entries: you can either configure the MAC-address used for Proxy ARP manually by typing it in (the MAC-address of your internet-facing interface) or you can simply configure the name of the interface to use for Proxy ARP and the gateway will figure out which MAC-address it has automatically. We are going to use the latter here and use the interface name simply to avoid potential errors from typing in the MAC address manually.

We will use the command add arp proxy ipv4-address <IP to Proxy ARP> interface <ethX> real-ipv4-address <real-outside-interface-IP> to add the manual Proxy ARP configuration to the Gateways.

If you are using gateways in a High Availability-mode, do note that the parameter real-ipv4-address here should be the actual IP address configured on the physical internet-facing interface, not the cluster’s virtual IP!

With that said, the commands to use in our case are:

For SG1: add arp proxy ipv4-address 192.168.247.50 interface eth1 real-ipv4-address 192.168.247.251

After the commands have been run on both Gateways, make sure to Install Policy on your gateways once again, or the configuration won’t be activated.

When the policy has been installed, you should be able to see the Proxy ARP-entry using the command fw ctl arp from earlier. You will also still see the Proxy ARP-entry we created earlier using the Object NAT (which used IP .100)

The output of the following commands will look similar if you run it on gateway SG2 as well, except with different MAC addresses and IP addresses in the end.

Notice here that you can see the Proxy ARP-entry for the outside IP-address .50 that we created earlier in Clish. However, we cannot see the Proxy ARP-entry (.100) that was automatically configured using Object NAT at the very beginning of this article. To see the Proxy ARP-entry created from the Object NAT, we still need to use the command fw ctl arp to display it.

Click on the Add button and fill in the parameters for which IP-address for Proxy ARP for, which interface this will take place, and what the real IP address of that interface is.

First, we do these steps on SG1:

Next, we need to Install Policy on the Gateways, and after that, you can see that the new Proxy ARP-entries are active by once again running the command fw ctl arp:

Create the NAT-rule in your Security Policy

After the Proxy ARP configuration is done, you can configure the actual NAT rule in your Security Policy. In my case, I made a simple Hide-NAT-rule that translates the IP-address of the Security Management Server (192.168.138.10) on my Inside network to IP-address 192.168.247.70 when it passes through the gateway and onto the internet.

Once again, we will place this rule above the wider Object NAT rule (that matches the whole Inside network 192.168.138.0/24) that we configured previously since we want the Windows 10 test PC’s traffic to hit the new rule and not the old rule.

Configuring Proxy ARP in local.arp file

The examples above have shown us how to configure Proxy ARP using either Gaia’s command line Clish or using the web-GUI, but there is also a third way to configure Proxy ARP, although it’s not the recommended way to do it in a non-VSX gateway.

If you head into command line Expert-mode and locate a file called local.arp, you can see the finished result of our previous Proxy ARP configurations.

Locate the file using the find command in Linux:

As you can see below, you are encouraged NOT to edit this file as indicated by the comments inside the file, but here you can see the configuration that resulted from both alternatives of our manual Proxy ARP configurations.

To get out of the VIM editor, simply type :q and press Enter to quit.

On gateways running in VSX-mode (at least in R80.30), it is more common to edit the local.arp-file to configure Proxy ARP (unless you are using Object NAT) since there is no Gaia web-GUI for individual virtual firewalls (VS) within the VSX-enabled gateways, but that’s an article for a different time.

Final thoughts

All in all, there are multiple ways to configure Proxy ARP and they all come with their pros and cons. While you can mix the two different methods covered in this article (automatic Proxy ARP via Object NAT or manual Proxy ARP via Gaia’s Clish/web-GUI), you should probably pick one method and stick to it to avoid confusion.