First of all, thanks for your application. I am working on a research project and running this SSTP server. The server is running on a Ubuntu VM. I then use sstp-client (1.0.15 from Homebrew) on my Mac to connect to it:
The output seems to suggest that PPP link negotiation did not succeed because I did not see any success message; on the other hand, I also did not see any failure message. After a while, the only exchanges between the client and the server are ECHO messages.
ThuJul817:17:382021:publish_entrySCDSet()failed:Success!ThuJul817:17:382021:publish_entrySCDSet()failed:Success!ThuJul817:17:382021:usinglink0ThuJul817:17:382021:Usinginterfaceppp0ThuJul817:17:382021:Connect:ppp0<-->/dev/ttys010ThuJul817:17:382021:sent[LCPConfReqid=0x1<asyncmap0x0><magic0x36a94575><pcomp><accomp>]ThuJul817:17:382021:rcvd[LCPConfNakid=0x2<magic0xaf098377>]ThuJul817:17:382021:rcvd[LCPConfAckid=0x1<asyncmap0x0><magic0x36a94575><pcomp><accomp>]ThuJul817:17:412021:rcvd[LCPConfReqid=0x2<asyncmap0x0><magic0xa1322290><pcomp><accomp>]ThuJul817:17:412021:lcp_reqci:returningCONFACK.ThuJul817:17:412021:sent[LCPConfAckid=0x2<asyncmap0x0><magic0xa1322290><pcomp><accomp>]ThuJul817:17:412021:sent[IPCPConfReqid=0x1<compressVJ0f01><addr0.0.0.0><ms-dns10.0.0.0><ms-dns30.0.0.0>]ThuJul817:17:412021:sent[ACSCPConfReqid=0x1<routevers16777216><domainvers16777216>]ThuJul817:17:412021:rcvd[LCPEchoReqid=0x0magic=0xa1322290]ThuJul817:17:412021:sent[LCPEchoRepid=0x0magic=0x36a94575]ThuJul817:17:412021:rcvd[CCPConfReqid=0x1<deflate15><deflate(old#)15><bsdv115>]ThuJul817:17:412021:Unsupportedprotocol'Compression Control Protocol'(0x80fd)receivedThuJul817:17:412021:sent[LCPProtRejid=0x280fd0101000f1a0478001804780015032f]ThuJul817:17:412021:rcvd[IPCPConfReqid=0x1<compressVJ0f01><addr192.168.20.1>]ThuJul817:17:412021:ipcp:returningConfigure-ACKThuJul817:17:412021:sent[IPCPConfAckid=0x1<compressVJ0f01><addr192.168.20.1>]ThuJul817:17:412021:rcvd[IPCPConfNakid=0x1<addr192.168.20.2><ms-dns18.8.8.8><ms-dns38.8.4.4>]ThuJul817:17:412021:sent[IPCPConfReqid=0x2<compressVJ0f01><addr192.168.20.2><ms-dns18.8.8.8><ms-dns38.8.4.4>]ThuJul817:17:412021:rcvd[LCPProtRejid=0x3823501010010010600000001020600000001]ThuJul817:17:412021:rcvd[IPCPConfAckid=0x2<compressVJ0f01><addr192.168.20.2><ms-dns18.8.8.8><ms-dns38.8.4.4>]ThuJul817:17:412021:ipcp:upThuJul817:17:412021:localIPaddress192.168.20.2ThuJul817:17:412021:remoteIPaddress192.168.20.1ThuJul817:17:412021:primaryDNSaddress8.8.8.8ThuJul817:17:412021:secondaryDNSaddress8.8.4.4ThuJul817:17:412021:ReceivedprotocoldictionariesThuJul817:17:412021:Receivedacsp/dhcpdictionariesThuJul817:17:412021:CommittedPPPstoreThuJul817:17:412021:Receivedacsp/dhcpdictionariesThuJul817:17:412021:CommittedPPPstoreThuJul817:18:112021:rcvd[LCPEchoReqid=0x1magic=0xa1322290]ThuJul817:18:112021:sent[LCPEchoRepid=0x1magic=0x36a94575]
I used a web browser to see if VPN connection was actually successful, but I don't see any message exchanges from the console, even though I can browse websites. My guess is that packets simply do not go through VPN. I also tried to use defaultroute option instead of nodefaultroute. In that case, the client was continuously sending some SSTP packets but did not get any response from the server:
Looks like you never negotiate authentication on the link (and perhaps a failure on sstp-client part of never sending the SSTP_CONNECTED message). Also, the initial LCP negotiation doesn't seem to agree on the correct MAGIC option. Could you please check the implementation?
Eivind
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any reason for why the community needs an sstp-server written in Python? Accel-ppp project already have a high-performance sstp module that allows for VPN access on server side.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your quick response. I am not sure I completely understand your suggestion (mostly likely due to my lack of thorough understanding of this topic, so I apologize). Are you suggesting that:
1. SSTP connection was never established because sstp-client failed to send SSTP_CONNECTED message? or
2. SSTP connection was indeed established, but PPP link negotiation (through LCP I presume) did not succeed because the client and the server cannot agree on the MAGIC option?
I suspect that the server was not correctly implemented to follow the protocol, perhaps? You did mention "a failure on sstp-client part", so is it also something that might be caused by a bug in sstp-client?
Any reason for why the community needs an sstp-server written in Python? Accel-ppp project already have a high-performance sstp module that allows for VPN access on server side.
I completely agree that there is no reason to use an SSTP server written in Python! I am simply working on designing a generic framework for privacy and anonimity and my current implementation happens to be in Python. This is why I am trying to use this Python SSTP server.
Thank you!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you try it with using e.g. PAP authentication, or MSCHAPv2 authentication?
Your ppp connections seems to be fully established, it's just that I don't see a SSTP_CONNECTED message. Typically a server would not allow network traffic over the link before it is fully "connected" (and/or authenticated). sstp-client is supposed to do this during the authentication, or at ip-up (if not previously done / authenticated).
You did get an IP address (and DNS came as well). You will also need to add appropriate routes for it to permit any traffic to go over the VPN. You could try to ping the remote IP (192.168.20.1) to generate some without adding any route(s). Also the "nodefaultroute" option was specified which prevents pppd from doing so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm. I am still confused (through no fault of your explanation, of course!).
If authentication failed, why would PPP connection be established after all? From other dicussions in this forum, I saw sstp-client would output something like this:
...
May 28 04:31:33 sstpc[8073]: Sending Connected Message
May 28 04:31:33 sstpc[8073]: SSTP CRTL PKT(112)
May 28 04:31:33 sstpc[8073]: TYPE(4): CONNECTED, ATTR(1):
May 28 04:31:33 sstpc[8073]: CRYPTO BIND(3): 104
May 28 04:31:33 sstpc[8073]: Connection Established
...
I guess this is what you meant by "a SSTP_CONNECTED message", which did not exist in my case.
This is also why I suspected (perhaps incorrectly) that the PPP/SSTP connection failed.
Typically a server would not allow network traffic over the link before it is fully "connected" (and/or authenticated). sstp-client is supposed to do this during the authentication, or at ip-up (if not previously done / authenticated).
Are you implying that it is authentication that led to the missing SSTP_CONNECTED message?
I will work on using MSCHAPv2 authentication; however, since I have noauth in the option, why is it still necessary?
Regarding the nodefaultroute option, based on what you said, I guess my suspicion is correct: even though I can browse the Internet, I am not really using the VPN to route the traffic. On the other hand, why would sstp-client continue to send an infinite number of SSTP DATA PKT when I set the defaultroute option? What are those DATA PKTs and why does the server provide no response to them?
I truly appreciate your responses and willingness to help. Thank you!
Best,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the SSTP_CONNECTED message seems to be missing from your trace. I don't know how your server will react to the lack of this message (drop all traffic, ignore it, or what have you). The fact that IP-UP was executed, and the sstp-client didn't react by sending the message is a bug in itself. However, the server should by the specification terminate the connection in 60 second if it doesn't see the message.
As I suggested, if you try adding authentication to the link; you should see the connected message as a workaround. The "noauth" option is to tell pppd on the client side to not authenticate the server.
If you do set the "defaultroute" option, pppd will add a default route for all traffic to go through the VPN. Again, if sstp-client didn't send a SSTP_CONNECTED message; the server still doesn't think you are fully connected and may drop all traffic to the floor. Adding a default route should definitely cause a lot of data packets to occur (hopefully both sent and received).
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your explanation. I was able to fix the issue and establish connection!
As it turns out, it is due to lack of authentication. With some changes to the iptable I was also able to browse the Internet.
Best,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
First of all, thanks for your application. I am working on a research project and running this SSTP server. The server is running on a Ubuntu VM. I then use sstp-client (1.0.15 from Homebrew) on my Mac to connect to it:
The output seems to suggest that PPP link negotiation did not succeed because I did not see any success message; on the other hand, I also did not see any failure message. After a while, the only exchanges between the client and the server are ECHO messages.
The
tmp.logdoes not have much to say either:I used a web browser to see if VPN connection was actually successful, but I don't see any message exchanges from the console, even though I can browse websites. My guess is that packets simply do not go through VPN. I also tried to use
defaultrouteoption instead ofnodefaultroute. In that case, the client was continuously sending some SSTP packets but did not get any response from the server:I am not sure why this is the case (or if it is related to PPP link negotiation. Also, with
defaultrouteoption, I can no longer browse the internet.Any suggestion is welcome! Thank you so much!
Best,
Mike
Hi Mike,
Looks like you never negotiate authentication on the link (and perhaps a failure on sstp-client part of never sending the SSTP_CONNECTED message). Also, the initial LCP negotiation doesn't seem to agree on the correct MAGIC option. Could you please check the implementation?
Any reason for why the community needs an sstp-server written in Python? Accel-ppp project already have a high-performance sstp module that allows for VPN access on server side.
Hi Eivind,
Thank you for your quick response. I am not sure I completely understand your suggestion (mostly likely due to my lack of thorough understanding of this topic, so I apologize). Are you suggesting that:
1. SSTP connection was never established because
sstp-clientfailed to sendSSTP_CONNECTEDmessage? or2. SSTP connection was indeed established, but PPP link negotiation (through LCP I presume) did not succeed because the client and the server cannot agree on the MAGIC option?
I suspect that the server was not correctly implemented to follow the protocol, perhaps? You did mention "a failure on
sstp-clientpart", so is it also something that might be caused by a bug insstp-client?I completely agree that there is no reason to use an SSTP server written in Python! I am simply working on designing a generic framework for privacy and anonimity and my current implementation happens to be in Python. This is why I am trying to use this Python SSTP server.
Thank you!
Hi Michael,
Could you try it with using e.g. PAP authentication, or MSCHAPv2 authentication?
Your ppp connections seems to be fully established, it's just that I don't see a SSTP_CONNECTED message. Typically a server would not allow network traffic over the link before it is fully "connected" (and/or authenticated). sstp-client is supposed to do this during the authentication, or at ip-up (if not previously done / authenticated).
You did get an IP address (and DNS came as well). You will also need to add appropriate routes for it to permit any traffic to go over the VPN. You could try to ping the remote IP (192.168.20.1) to generate some without adding any route(s). Also the "nodefaultroute" option was specified which prevents pppd from doing so.
Hi Eivind,
Hmmm. I am still confused (through no fault of your explanation, of course!).
sstp-clientwould output something like this:I guess this is what you meant by "a SSTP_CONNECTED message", which did not exist in my case.
This is also why I suspected (perhaps incorrectly) that the PPP/SSTP connection failed.
Are you implying that it is authentication that led to the missing SSTP_CONNECTED message?
I will work on using MSCHAPv2 authentication; however, since I have
noauthin the option, why is it still necessary?nodefaultrouteoption, based on what you said, I guess my suspicion is correct: even though I can browse the Internet, I am not really using the VPN to route the traffic. On the other hand, why wouldsstp-clientcontinue to send an infinite number of SSTP DATA PKT when I set thedefaultrouteoption? What are those DATA PKTs and why does the server provide no response to them?I truly appreciate your responses and willingness to help. Thank you!
Best,
Mike
Hi Michael,
Yes, the SSTP_CONNECTED message seems to be missing from your trace. I don't know how your server will react to the lack of this message (drop all traffic, ignore it, or what have you). The fact that IP-UP was executed, and the sstp-client didn't react by sending the message is a bug in itself. However, the server should by the specification terminate the connection in 60 second if it doesn't see the message.
As I suggested, if you try adding authentication to the link; you should see the connected message as a workaround. The "noauth" option is to tell pppd on the client side to not authenticate the server.
If you do set the "defaultroute" option, pppd will add a default route for all traffic to go through the VPN. Again, if sstp-client didn't send a SSTP_CONNECTED message; the server still doesn't think you are fully connected and may drop all traffic to the floor. Adding a default route should definitely cause a lot of data packets to occur (hopefully both sent and received).
Hi Eivind,
Thank you for your explanation. I was able to fix the issue and establish connection!
As it turns out, it is due to lack of authentication. With some changes to the
iptableI was also able to browse the Internet.Best,
Mike