http://hostel.nstu.ru/viewtopic.php?id=109316 может поможет

Исправлено TomSafe (30.09.09 22:57)

плюс....все нормально работало...буквально утром....потом через 6 часов перестало...несмотря на то что изменений никаких не было, даже не перезагружал комп...
З.Ы. Переустановка демона и ppp, pptp не помогли.
З.З.Ы. rp_filter 0, nodefaultroute - стоят

Исправлено Ariman (01.10.09 01:29)

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

Сетевые интерфейсы туннеля

ppp0      Link encap:Point-to-Point Protocol 
          inet addr:192.168.11.150  P-t-P:192.168.11.151  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:32037 (31.2 KiB)  TX bytes:114 (114.0 b)

eth0      Link encap:Ethernet  HWaddr 00:0C:F1:A3:09:D8 
          inet addr:192.168.11.20  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20c:f1ff:fea3:9d8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4242923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2352428 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1067764455 (1018.2 MiB)  TX bytes:778647781 (742.5 MiB)

пускаю ping до 192.168.11.22 и смотрю через tcpdump.

tcpdump -nli eth0 not port openvpn and host 192.168.11.22

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:29:32.415628 arp who-has 192.168.11.151 tell 192.168.11.22
21:29:33.795934 arp who-has 192.168.11.20 tell 192.168.11.22
21:29:33.795952 arp reply 192.168.11.20 is-at 00:0c:f1:a3:09:d8
21:29:35.913581 IP 192.168.11.151 > 192.168.11.22: ICMP echo request, id 768, seq 45057, length 40
21:29:35.913939 arp who-has 192.168.11.151 tell 192.168.11.22
21:29:36.914482 arp who-has 192.168.11.151 tell 192.168.11.22

Собственно правила фаера

[root@cl5 ~]# iptables-save
# Generated by iptables-save v1.3.5 on Thu Oct  8 21:26:02 2009
*filter
:INPUT ACCEPT [1428316:451568861]
:FORWARD ACCEPT [1452570:544803229]
:OUTPUT ACCEPT [1421394:669357256]
COMMIT
# Completed on Thu Oct  8 21:26:02 2009
# Generated by iptables-save v1.3.5 on Thu Oct  8 21:26:02 2009
*nat
:PREROUTING ACCEPT [951633:155040792]
:POSTROUTING ACCEPT [43274:3363959]
:OUTPUT ACCEPT [43044:3350505]
-A POSTROUTING -s 192.168.10.0/255.255.255.0 -d 192.168.11.0/255.255.255.0 -j SNAT --to-source 192.168.11.20
-A POSTROUTING -s 192.168.11.0/255.255.255.0 -o ppp+ -j SNAT --to-source 192.168.11.20
COMMIT
# Completed on Thu Oct  8 21:26:02 2009

модули

[root@cl5 ~]# lsmod | grep pp
ip_nat_pptp             9925  0
ip_conntrack_pptp      15441  1 ip_nat_pptp
ppp_deflate             9793  0
zlib_deflate           21977  1 ppp_deflate
ppp_mppe               10437  2
ppp_async              15169  1
crc_ccitt               6337  1 ppp_async
ppp_generic            30165  7 ppp_deflate,ppp_mppe,ppp_async
slhc                   10561  1 ppp_generic
ip_nat                 20973  2 ip_nat_pptp,iptable_nat
ip_conntrack           53025  4 ip_nat_pptp,ip_conntrack_pptp,iptable_nat,ip_nat
floppy                 57125  0

и последнее

sysctl -a | grep rp_filter
net.ipv4.conf.ppp0.arp_filter = 0
net.ipv4.conf.ppp0.rp_filter = 1
net.ipv4.conf.tap0.arp_filter = 0
net.ipv4.conf.tap0.rp_filter = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 0

в чем может быть проблема?
пробовал даже так

-A POSTROUTING -s 192.168.11.0/255.255.255.0 -o eth0 -j SNAT --to-source 192.168.11.20
-A POSTROUTING -s 192.168.11.151 -j SNAT  -o eth0 --to-source 192.168.11.20

не помогает

Исправлено kai (08.10.09 22:23)

С этим все впорядке. Потому что NAT для openvpn работает. Почему для ppp не срабатывает?
# sysctl -a |grep ipv4.ip_forward
net.ipv4.ip_forward = 1

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

в OpenVPN  это просто решается, опцией push в конфиге  сервера.   Только не большие заморочки с ключами, настраивать его проще, чем ppp+pptp.