Destination NAT for PPTP failing randomly

Hello, I would like to know if anyone has experienced something similar and/or find out if this is a known issue?

The issue:

we have a policy ( untrust to trust ) to allow pptp traffic to an internal server, the rule below:

Software: 

VERSION: JUNOS Software Release [12.1X47-D20.7]

Hardware: SRX220

from-zone untrust to-zone trust {
policy server-access2 {
match {
source-address any;
destination-address server-access2;
application [ junos-pptp junos-gre ];
}
then {
permit;
}
}
}

Then the destination NAT configuration:

rule port-1723 {
match {
destination-address 185.x.x.x/32;
destination-port {
1723;
}
}
then {
destination-nat {
pool {
192.x.x.x-1723;
}
}
}
}

And most of the time it works, here a working example:

admin@FLMD> show security flow session nat destination-port 1723
Session ID: 93102, Policy name: server-access2/7, Timeout: 1792, Valid
Resource information : PPTP ALG, 6, 0
In: 81.x.x.x/49949 --> 185.x.x.x/1723;tcp, If: ge-0/0/0.0, Pkts: 579, Bytes: 28120
Out: 192.x.x.x/1723 --> 81.x.x.x/49949;tcp, If: ge-0/0/1.0, Pkts: 291, Bytes: 17576
Total sessions: 1

And here is where the fun begins, at some random times the connection fails and below is the output when this happens:

admin@FLMD> show security flow session nat destination-port 1723

Session ID: 432270, Policy name: allow-all/4, Timeout: 14, Valid
In: 46.x.x.x/50014 --> 185.x.x.x/1723;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 240
Out: 192.y.y.y/55229 --> 46.x.x.x/50014;tcp, If: ge-0/0/1.0, Pkts: 0, Bytes: 0
Total sessions: 1

First, the policy is incorrect, the policy should be server-access2 (untrust to trust), but in this case, the policy applied is allow-all, which by the way it is a policy for  ( trust to untrust), see below:

from-zone trust to-zone untrust {
policy allow-all {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}

Moreover, the traffic is sent to a different internal IP in a different port, when it should be going to: 192.x.x.x/1723; it goes to 192.y.y.y/random_port, notice that this IP changes all the time, so it can be any IP in the internal subnet.

Is this a bug? Has anyone seen anything like this?

Many thanks;

Edson