iptables - разрешить ВПН клиенту подключиться к приложению на локальном интерфейсе

Попробуй так

IPTABLES -I POSTROUTING -t nat -d $LAN -j RETURN

Правило FORWARD тут не причем, у вас локальный процесс т.е. цепочка INPUT
iptables -A INPUT -i $VPN -p tcp --dport 80 -j ACCEPT

Я всегда думал, что только loopback интерфейс не идет через forward, разве нет?

И что на счет форвардинга в ядре?

Вы путаете вариант когда пакет прилетел на машину к локальному процессу и процесс ответил. Это INPUT/OUTPUT.
FORWARD это транзитные пакеты.
Собстно все это доступно написано в iptables tutorial. :)

Все гениальное просто. Ваше решение сработало на уре! Всем спасибо, проблема решена.

iptables -A INPUT -i $VPN -p tcp --dport 80 -j ACCEPT

Если приложение слушает только интерфейс $LAN, то это не поможет.

Все гениальное просто. Ваше решение сработало на уре!

Значит, исходные условия задачи описаны неверно - Ваше приложение слушало все интерфейсы, а не только $LAN ;).

Поможет.Глубоко фиолетово какой интерфейс слушает локальный процесс

Поможет.Глубоко фиолетово какой интерфейс слушает локальный процесс

Только что проверил на Samba. При соединении телнетом на 139 порт локального интерфейса устанавливается соединение. При попытке соединиться снаружи (при выключенном файрволе) приводит к моментальному сбросу соединения (соединение устанавливается и тут же закрывается). В настройках Samba прописано работать только на локальном интерфейсе.

Так что в общем случае далеко не фиолетово.

Вы на какой IP подсоединяетесь на внешний или локальный?

Вы на какой IP подсоединяетесь на внешний или локальный?

На внешний, конечно. Samba слушает локальный адрес на локальном интерфейсе, но не слушает внешний адрес на внешнем интерфейсе.

ЧТД. А надо на тот на котором слушает. Разницу видите? В случае сабжа подключаемся на LAN:80 и профит, это локальный процесс поэтому пофигу на каком он интерфейсе. Сколько можно повторять?
ЗЫ Что бы не быть голословным раз уж такое пошло, на всякий случай перепроверил и у себя. Вводные: Локалка -> роутер с двумя внешними интерфейсами. Три варианта
1. named висит на двух внешних интерфейсах, биндинг по ip, но если я обращаюсь к нему из локалки аля host ya.ru $EXT_IP он ответит и цепочку forward это никак не затрагивает
2. IPSec. strongswan висит на одном из внешних интерфейсов, биндинг по имени интерфейса, я подключаюсь по ip внешнего интерфейса из локалки, и цепочка forward тут не участвует.
3. IPSec+L2TP strongswan висит на одном из внешних интерфейсов, биндинг по имени интерфейса, xl2tpd биндинг на ip этого интерфейса. Все тоже самое, я подключаюсь по ip внешнего интерфейса из локалки, и цепочка forward тут не участвует.
Надеюсь так понятнее?

ЗЫ Собственно это старый холивар. Когда некоторые считают что я повесил демона на внутренний ip и мне fw не надо. В целом из инета до вас не достучаться, это верно. Но соседские(по локалке) васяны прописав роутинг до вашей внутренней сети потенциально могут до вас достучаться.

Когда некоторые считают что я повесил демона на внутренний ip и мне fw не надо.

Ну, справедливости ради, я такого не говорил ;). Речь шла о том, что одного разрешения со стороны файрвола мало, нужно еще, чтобы сервис слушал определенный IP. А так да, маршрутизацией можно подобную «защиту» обходить.

Ну, справедливости ради, я такого не говорил ;)

Я не о вас, а о других «адептах» подобной защиты :)

Речь шла о том

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

Вы дважды оспорили момент что тут INPUT не поможет, однако это не верно.

Не, Вы неправильно меня поняли. В нужности цепочки с input я не сомневался. Речь шла о том, что сервис не слушает нужный IP, поэтому даже устранение FW не поможет. Просто перепутал интерфейсы, которые сервис слушает.

Плиз тогда не вводите людей в заблуждение. «А то тут и дети могут быть» :)
UPD Ещё забывают про fe80:: думая что это аналог 127. Слишком большое заблуждение.