Fredcapit

Насколько я понимаю на 192.168.2.20 крутится IIS.
Для того, чтобы на IIS в будущем запилить несколько сайтов нужно этой машине дать статический адрес и прикрутить в DNS адрес, например, portal.local.
На самой машине зайти в Диспетчер управления IIS и найти сайт Bitrix, если конечно он использует IIS.
В противном случае погасить дефолтный сайт, чтобы он не держал 80 порт и настроить http-сервер битрикса на 80.
ИЛИ если всё-таки Bitrix будет сидеть на IIS, то можно дефолтному сайту переназначить привязку на какой-нибудь другой порт, а Битрикс сделать на 80 и не указывать доменное имя сайта, тогда он будет отзываться как дефолтный.
ИЛИ если портал лежит в другом месте, то нужен Redirect, который возможно нужно устанавливать дополнительно как модуль.

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

"тупые" свичи в целях составления таблицы адресов (то есть в какой интерфейс отсылать далее пакет) использует MAC адрес. Есть более продвинутые свичи, где можно настроить другое поведение в зависимости от других параметров в том числе и от IP адреса.
присоединяюсь к pfg21

Прост Ethernet-протокол сейчас наиболее применяемый/единственный протокол канального уровня OSI для IP-сетей, и потому MAC-адрес так известен.
Распространился бы другой протокол, были бы известны его составляющие

У меня была такая же проблема. Вот эта документация мне помогла. Правда у меня была потребность в POST запросах с передачей JSON во вложении, а также я использовал аутентификацию, но ограничения безопасности браузеров не позволили мне этого сделать.
Короче говоря, метод DELETE нельзя использовать при Cross-domain.
Также там есть ограничения на ContentType, который может быть.
Рекомендую внимательно прочитать предложенную документацию.

Там же написано, что раздел конфигурации заблокирован на родительском уровне.
В Диспетчере служб IIS кликаете в навигационном дереве слева на сервер (верхний уровень дерева), справа находите "Редактор конфигураций" щёлкаете.
Ищете тот раздел (Справа панель "Действия" ссылка "Поиск по конфигурации...").
Переходите к этому разелу, справа будет написано действие либо "Заблокировать раздел" либо "Разблокировать раздел"
Примерно так.

Насколько я понимаю, это связано с аутентификацией.
Сначала приходит POST запрос без полей аутентификации. Сервер отвечает клиенту, что нужна аутентификация и отдает ответ с http заголовком, где указано какая аутентификация нужна. Браузер вставляет нужные значения в заголовок, отвечающий за аутентификацию и повторяет запрос. Далее запросы должны проходить нормально.
Бывает, когда на IIS настроена 2 вида аутентификации (NTLM, Kerberos к примеру) в таком случае один из видов аутентификации может не работать и в результате можно вечно получать 2 ответа от сервера.
В локальной сети может настроена аутентификация kerberos и при указании такой же на IIS, аутентификация может на работать (не знаю почему, но у меня так) и поэтому нужно оставлять только NTLM.

На ASP.NET на IIS проблем не увидел. Приложение работает под своей учётной записью. Когда приходит HTTP-запрос и на IIS включена аутентификация NTLM или Kerberos, а также строка подключения к базе данных содержит параметр "Integrated Security = true", то подключение к базе осуществляется от имени пользователя.

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

А почему не использовать POST?
Уложите данные формы в тело запроса и получайте ответ в том виде, в котором хотите.

Доверьте эту работу (вставку boundary) браузеру.

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

А может сервер всё-таки иметь один? Зачем куча экземпляров?

Если сетка локальная дома, то о шифровании можно не заботиться, всё равно через Ваш роутер и будут идти пакеты. Если у Вас корпоративная локальная сеть, то скорее всего у вас есть Active Directory, DNS сервер.
В принципе в локальной сети, если она ограничена вашими устройствами (свичи хабы и проч), то о HTTPS можно не заморачиваться. Также если у вас локальная сеть организации распределена между городами (соединенная посредством VPN), то тоже не стоит заморачиваться по поводу HTTPS, пусть о безопасности локальной сети думают админы (например, они могут использовать замудрённое шифрование VPN).
С Active Directory у вас получится очень простая модель аутентификации (NTLM или Kerberos), если конечно настроен Kerberos. В вашем проекте просто указываете, что вы хотите использовать Windows-аутентификацию ну а дальше дело техники.
Никакой регистрации не нужно, ваши пользователи и так её имеют на KDS.

Вообще то, что крутится на localhost на порту типа 56870 это предназначено для локальной отладки Вашего Web приложения. Для того, чтобы к этому приложению получили доступ другие Ваши устройства, нужно опубликовать ваш сайт на Вашем IIS (Internet Information Sevice), если конечно он у вас установлен (если нет, то это легко сделать в программах и компонентах кнопочка типа "Добавить или удалить компоненты")
Изучите как настроить iis, ну а уж опубликовать из Visual Studio это достаточно просто (кнопочка опубликовать, появится диалоговое окно и следуйте инструкциям, если что не понятно то гуглите).
После этих действий ваш сайт будет крутиться на вашем компьютере и если у вас Wifi, то в браузере телефона просто пишите локальный IP адрес Вашего ПК, нажимаем "Enter" и вуаля.

Насколько я понимаю Ваше решение написано на C# c использованием ASP.Net
Рекомендую изучить возможности настройки вашего WebConfig. Так есть возможность добавить соответствующие настройки с указанием возможности доступа к разным страницами или анонимно или после аутентификации, а также для отдельных пользователей.
Вот курс ссылка с ASP.NET

Ознакомьтесь с решение SignalR. Там как раз реализован разный тип взаимодействия клиент-сервер в зависимости от доступности того или иного метода установления соединения. Также относительно легко можно управлять подключенными клиентами, оповещать других об изменении их статуса, автоматическое переподключение при потере соединения и т.п.
На его базе очень легко реализовать веб-чат (по крайней мере на C#).
Очень интересна технология WebRTC. Это когда есть возможность устанавливать соединения между клиентами напрямую, например для реализации видео-чата. Правда в этих целях необходимы дополнительные элементы, которые позволят двум клиентам "найти" друг друга в сети.
Теоретически пакеты в сети изначально адресуются по mac адресам, но развивающиеся технологии позволяют управлять адресацией (я имею ввиду различные устройства маршрутизации свичи, хабы...) на основе и IP-адреса.