не знаю почему покеты застревают внутри хоста (проборос портов во внутрь), но по поводу l2tp выяснил такую фишку, мне очень долго не удавалось поднять l2tp клиен на линуксах/BSD, проблема оказалась в самом протоколе, он должен видеть vpn сервер всё время, решается статическим маршрутом к сети провайдера, а так же исключением в правиле NAT внутри pf. Сам так делал и работало стабильно без всяких проблем. Моё провило для нат выглядило так
Код:

nat on $vpn_if from $lan to !$isp_net -> $vpn_if
а следом правило для прова, тоже вроде как NAT (правда в моём случае второго NAT не было, потому что провайдер поставил свой Modem-router, который собственно и делал второй нат, который в моём случае и так не нужен был, но отключить возможности не было).
Код:

nat on $ext_if from $lan to $isp_net -> $ext_if
На самом деле я не знаю если сеть провайдера нужно натить...
Никакого нат в mpd я не использую, связка такая же FreeBSD90 +mpd5 + pf (w NAT) работает по сей день (правда по техническим причинам я сейчас на ADSL, но vpn клиен тот-же mpd5)
Мой mpd5.conf:
Код:

isp_l2tp:
create bundle static L2TPNV
set bundle disable compression round-robin encryption crypt-reqd bw-manage
set bundle enable ipcp
set iface disable proxy-arp
set ipcp yes vjcomp req-pri-dns req-sec-dns
set iface mtu 1492
set iface enable tee on-demand
set iface idle 0
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/up.sh
set iface down-script /usr/local/etc/mpd5/down.sh
# set iface route 212.143.206.0/24
create link static L2NV l2tp
set link action bundle L2TPNV
set link latency 0
set link max-redial 0
set link disable acfcomp check-magic protocomp shortseq
set link deny chap-msv2 chap-msv1 eap acfcomp
set link enable multilink passive
set link mtu 1492
set link keep-alive 60 180
set l2tp peer "isp.vpn.server"
set auth authname "username"
set auth password "password"
set l2tp enable length
set l2tp self xl0
open
Не могу сказать что слишком силён в настройках mpd и тонкостях l2tp тунеля, но конфиг в моём случае работал без проблем, кстати как видно я тут пытался добавлять статический маршрут в самом конфиге, но это либо не работало либо работало через раз и потом маршрут не удалялся, потому сделал отдельные скрипты. к тому же у меня была проблема с заменой default gateway mpd почему-то не хотел его менять, а в случае отключения тунеля возвращать обратно... статические маршруты я добавлял там же.
В моём случае все пробросы работали и работают по сей день без всяких проблем...
Надеюсь это немного поможет (хотя много времени прошло, может уже не актуально)
PS
я тут видел в некоторых манулах от pf: redirect указывают раньше правил NAT, не знаю если это может иметь значение, но попробуйте поменять (хотя наверное глупость)
и кстати я в редайректах указывал ещё и адрес на который приходит запрос
Код:

rdr on $vpn_if proto { tcp udp } from any to $wan_ip port { 6881:6889 } -> $nas
Да и вот, я сейчас вспомнил, я так же сталкнулся с тем что редайрект не работал на интерфейсе где не было NAT, пытался завернуть 80-ый порт на squid, но через pf, оно ни в какую нихотело работать, вернее работало, но только в одну сторону (т.е. пакеты доходили до squid, но обратной дороги не находили). Разруливал через ipfw... возможно что в этом и кроется причина ;-)