>> I'm confused here. The TCP/UDP 5678 port you mentioned above actuallly
refers to >> "Remote Replication Agent Connection" (rrac service) under the
registered ports list. >> Correct me if I'm wrong here, I don't really see
this service is related or required >> for the pptp to work. Any comments ?
At 08:10 AM 8/6/97 -0400, you wrote:
>PPTP's control connection uses TCP/UDP 1723. TCP/UDP 5678 was indicated
>in the initial draft proposal for the PPTP protocol, but NT 4.0 was
>released using the IANA assigned port number 1723.
>GRE, IP Protocol 47 (not a TCP or UDP port) is used for the data tunnel.
>Obviously if you implement a rule on FW-1 (or any Firewall) specifying
>TCP/UDP 5678 for the control channel, you're not going to be able to get
>any NT or Win95-based PPTP machines to work since they will try to set
>up their control channel over TCP1723.
>Some Front-End Processors (FEPs) may actually make the PPTP control
>connection themselves, and then relay the PPP traffic through the tunnel
>they've established. In this case, your rules need to be based on the IP
>address of the FEP, not the IP address assigned to the client by the
>If you are doing PPTP over a client network adapter, then your rules are
>based on the client's original IP address.
>IP addresses assigned by the PPTP server need to be from a subnet other
>than one existing on your PPTP server networks, otherwise your clients
>will end up with their PPTP network gateway being seen as an address on
>their physical network adapter, rather than an addressed reached through
>their virtual network adapter created by the PPTP tunnel.
>Finally, remember that GRE is *not* encryption, merely encapsulation. No
>valuable security is gained by encapsulation, so enable PPP encryption
>on the Dial-up connection on the client to obtain any security.
>R.C. Consulting, Inc. - NT/Internet Security
>owner of the NTBugTraq Mailing List - http://ntbugtraq.rc.on.ca/
"Here is my key ... lets exchange packets now."