In the realm of PPTP, TCP/1723 is a simple control channel whose sole purpose is to bring up a Microsoft specific secondary GRE (IP/47) tunnel. This GRE tunnel contains encapsulated PPP frames and is used for negotiating authentication, encryption, and passing actual data.
The negotiation is as follows. Three-way handshake followed by PPTP Start-Control-Connection-Request and Reply then Coutgoing Call Request and Reply and then following the last reply from the PPTP Public Server it should send a PPP-LCO GRE encapsulated request to the private client. It is here that the Gate-Pinhole needs to be opened by the NAT engine. So we open a PINhole for the GRE session to get initiated from the public side towards the private side.
If there is no Pinhole opened we should debug the MS-MPC / MS-MIC in order to detect why the ALG flow is not opening the respective session/flow.
Troubleshooting ALGs can start by simplifying looking at the flow/session table and grabbing the output of “show services alg statistics application-protocol”
Look at the output of the command “show services alg statistics application-protocol sip” to help troubleshoot ALG issues.
Issuing this command, you should see if your ALG is reporting decoding errors.
But without success. I added address-pooling paired;
Right, do You have MS-DPC or MS-MPC or MS-MIC? How do You load-balance between NPUs if MS-MPC? Do You have AMS or do You do FBF load-balancing between ms- interfaces? Or simply 0/0 route with multiple ms- mexthops?