GRE и NAT – внезапно проблема [preSOLVED?]

Есть некий сервер с accel-ppp, предоставляет pptp и l2tp. И вдруг от него потребовалось, чтобы он предоставлял это не на одном IP, а на нескольких. Сам он так не умеет, так что iptables -t nat -A PREROUTING -m set --match-set $SET_VPN dst -j DNAT --to-destination $VPN_IP. Но увы, подключиться на $SET_VPN через pptp не удается:
(server.6 это $VPN_IP, на котором accel-ppp принимает pptp и l2tp, server.15 – это один из $SET_VPN)

02:51:01.181534 IP client.4147 > server.15.1723: Flags [S], seq 2758515470, win 65535, options [mss 1412,nop,nop,sackOK], length 0
02:51:01.181566 IP server.15.1723 > client.4147: Flags [S.], seq 1583048317, ack 2758515471, win 29200, options [mss 1460,nop,nop,sackOK], length 0
02:51:01.211865 IP client.4147 > server.15.1723: Flags [P.], seq 1:157, ack 1, win 65535, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) HOSTNAME() VENDOR(Microsoft Windows NT)
02:51:01.211922 IP server.15.1723 > client.4147: Flags [.], ack 157, win 30016, length 0
02:51:01.212052 IP server.15.1723 > client.4147: Flags [P.], seq 1:157, ack 157, win 30016, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
02:51:01.242265 IP client.4147 > server.15.1723: Flags [P.], seq 157:325, ack 157, win 65379, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(4147) CALL_SER_NUM(56979) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
02:51:01.242480 IP server.15.1723 > client.4147: Flags [P.], seq 157:189, ack 325, win 31088, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(38185) PEER_CALL_ID(4147) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
02:51:01.242950 IP server.6 > client: GREv1, call 4147, seq 1, length 35: LCP, Conf-Request (0x01), id 1, length 21
02:51:01.277129 IP client.4147 > server.15.1723: Flags [P.], seq 325:349, ack 189, win 65347, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(38185) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
02:51:01.279646 IP client > server.15: GREv1, call 38185, seq 0, length 34: LCP, Conf-Request (0x01), id 0, length 20
02:51:01.279723 IP server.6 > client: GREv1, call 4147, seq 2, ack 0, length 28: LCP, Conf-Reject (0x04), id 0, length 10
02:51:01.321846 IP server.15.1723 > client.4147: Flags [.], ack 349, win 31088, length 0
02:51:03.278989 IP client > server.15: GREv1, call 38185, seq 1, length 34: LCP, Conf-Request (0x01), id 1, length 20
02:51:03.279171 IP server.6 > client: GREv1, call 4147, seq 3, ack 1, length 28: LCP, Conf-Reject (0x04), id 1, length 10
02:51:04.243003 IP server.6 > client: GREv1, call 4147, seq 4, length 35: LCP, Conf-Request (0x01), id 1, length 21
02:51:06.283295 IP client > server.15: GREv1, call 38185, seq 2, length 34: LCP, Conf-Request (0x01), id 2, length 20
02:51:06.283416 IP server.6 > client: GREv1, call 4147, seq 5, ack 2, length 28: LCP, Conf-Reject (0x04), id 2, length 10
02:51:07.242993 IP server.6 > client: GREv1, call 4147, seq 6, length 35: LCP, Conf-Request (0x01), id 1, length 21
02:51:10.243174 IP server.6 > client: GREv1, call 4147, seq 7, length 35: LCP, Conf-Request (0x01), id 1, length 21
02:51:10.288690 IP client > server.15: GREv1, call 38185, seq 3, length 34: LCP, Conf-Request (0x01), id 3, length 20
02:51:10.288771 IP server.6 > client: GREv1, call 4147, seq 8, ack 3, length 28: LCP, Conf-Reject (0x04), id 3, length 10

вгетпаста, то же самое

сразу бросается в глаза, что DNAT для контрольного соединения работает верно (client <> server.15.1723), однако с GRE не совсем мне понятно. Глядя другим глазом (мне как-то совсем лень изучать RFC) в удачное pptp соединение на «основной» IP server.6, я вижу, что оба конца посылают Conf-Request пока видимо не договорятся о length.
Для данного же случая я вижу интереснейшую вещь:

client > server.15: GREv1, call 38185, seq 0, length 34: LCP, Conf-Request (0x01), id 0, length 20
server.6 > client: GREv1, call 4147, seq 2, ack 0, length 28: LCP, Conf-Reject (0x04), id 0, length 10
…
client > server.15: GREv1, call 38185, seq 2, length 34: LCP, Conf-Request (0x01), id 2, length 20
server.6 > client: GREv1, call 4147, seq 5, ack 2, length 28: LCP, Conf-Reject (0x04), id 2, length 10

Conf-Reject от сервера не «натится», а уходит с «оригинальным» IP. Разумеется, эти ответы не проходит через nat, за которым находится client – так же как и Conf-Request в ту же сторону. Собственно, это и есть вопрос.

----

дальнейшие расследования: (PPTP успешно подключен к server.6):

# conntrack -L -s client -d server.6
gre      47 25 src=client dst=server.6 srckey=0x0 dstkey=0x954d [UNREPLIED] src=server.6 dst=client srckey=0x954d dstkey=0x0 mark=0 use=1
tcp      6 51 ESTABLISHED src=client dst=server.6 sport=4192 dport=1723 src=server.6 dst=client sport=1723 dport=4192 [ASSURED] mark=0 use=1

----

вроде бы починено? работает, но вопросы остались, комментарии в теме.

+ -t raw -A PREROUTING -i $OINTERFACE -d $VPN_IP -p tcp --dport 1723 -j CT --helper pptp
+ -t raw -A PREROUTING -i $OINTERFACE -m set --match-set $SET_VPN dst -p tcp --dport 1723 -j CT --helper pptp
- -A allow-vpn-traffic-in-in -p gre -j ACCEPT
+ -A allowed-connection -m conntrack --ctstate RELATED -m helper --helper pptp -p gre -i $OINTERFACE -d $VPN_IP -j ACCEPT