https://m.opennet.dev/openforum/vsluhforumID1/97753.html Итак, на хосте есть две клетки, одна vpn (mpd5) с адресом 192.168.1.9, другая mail с адресом 192.168.1.4<br>К vpn-клетке через pptp подключается клиент, получающий адрес 192.168.0.130. Для того, чтобы он мог ходить по внутренним адресам 192.168.1.0/24, на хосте добавлено правило route add 192.168.0.0/24 192.168.1.9. На этом этапе все ок, win-клиент подключается по pptp к vpn-серверу, и имеет доступ к внутренней сети - нормально отрабатывают и udp (ping 192.168.1.4) и tcp (curl 192.168.1.4).<br>Поскольку идея состоит в том, чтобы пускать клиента напрямую в Инет (чертовы видеоконференции не работают нормально через прокси), то без nat не обойтись, и я моделирую ситуацию с nat-ом наружу - включаю ipfw kernel nat на vpn-сервере (eth1=192.168.1.9):<br><br>ipfw -q nat 1 config if eth1 reset<br>#NAT для входящих пакетов<br>ipfw -q add 00002 nat 1 ip4 from any to any in recv eth1<br>ipfw -q add 00010 check-state<br>ipfw add 00290 allow ip from any to any via lo0<br>#NAT для исходящих пакетов<br>ipfw -q add 00800 nat 1 ip4 from any to an https://m.opennet.dev/openforum/vsluhforumID1/97753.html#5 Wed, 11 Aug 2021 12:29:31 GMT &gt; клетки напрямую в Инет через белый ip. Теперь пакеты от клиента <br>&gt; натятся внутренним адресом vpn-сервера и к 192.168.1.4 приходят будто-бы от 192.168.1.9. <br>&gt; UDP-протокол работает без проблем, пинг отрабатывает, а вот tcp работать после <br>&gt; nat не хочет. При этом пакеты ходят в обе стороны, но <br>&gt; на клиенте команда curl 192.168.1.4 не выдает ответ, будто-бы сервер не <br>&gt; отвечает, хотя tcpdump на крайнем к клиенту интерфейсе ng0 (создается при <br>&gt; подключении) показывает что пакеты клиенту идут.<br><br>Выглядит так, что вы забыли выключить TSO на eth1.<br> https://m.opennet.dev/openforum/vsluhforumID1/97753.html#4 Wed, 07 Jul 2021 09:23:44 GMT когда я последний раз подобное смотрел у меня tcp на связке jail+ipfw nat не заработал. перенес nat в pf и забил.<br> https://m.opennet.dev/openforum/vsluhforumID1/97753.html#3 Wed, 07 Jul 2021 08:30:48 GMT подключи модули ppptp_nat и другие, инет в руки<br> https://m.opennet.dev/openforum/vsluhforumID1/97753.html#2 Wed, 07 Jul 2021 05:03:45 GMT &gt; Хм. Нихрена не понятно.<br>&gt; НАН на приватном интерфейсе?<br>&gt; Зачем в фаере чек стейт без кипа?<br>&gt; То про eth1, то про ng0.<br>&gt; И шо за манера вместо текущих правил выкидывать командник их создания?<br><br>По порядку.<br>"НАН на приватном интерфейсе?" - В итоге nat будет работать наружу в Инет с белого ip. Т.к. у vpn-клиента не работает tcp через nat, то для нахождения проблемы я смоделировал ситуацию с nat-ом на приватном интерфейсе - на нем я могу пускать клиента ко внутренним адресам и через nat, и без него, а также слушать tcpdump-ом на интерфейсе сервера к которому обращается клиент. Я убедился, что проблема именно в нате - без него работают и tcp и udp. Только включаешь nat для трафика pptp-клиента (кстати, пробовал и с L2TP/IPSEC), как tcp перестает работать в отличие от udp, пинг на стороне клиента продолжает работать.<br>"Зачем в фаере чек стейт без кипа?" & "И шо за манера вместо текущих правил выкидывать командник их создания?" - nat делал по методичке https://forums.freebsd.org/threads/ipfw-share-internet.62 https://m.opennet.dev/openforum/vsluhforumID1/97753.html#1 Tue, 06 Jul 2021 20:14:10 GMT Хм. Нихрена не понятно. <br>НАН на приватном интерфейсе?<br>Зачем в фаере чек стейт без кипа?<br>То про eth1, то про ng0.<br>И шо за манера вместо текущих правил выкидывать командник их создания?<br><br>