I was digging around with sstpc and the ppp EAP-TLS patch to connect to an Azure VPN Gateway using a P2S connection and everything is working fine, except one scenario I can't explain. But first things first:
I'm using Ubuntu 18.04.2, ppp 2.4.7 (with EAP-TLS patch 1.102) and sstpc 1.0.12. I tested on two different machines, an Lenovo Thinkpad (64-Bit Intel) )and a Raspberry Pi 2.
The "logging bug"
When I connect to the SSTP host, during EAP-TLS authentication EAP will send a TLS "Client Hello". This EAP Response (CONFACK) is dumped in the logs, it tells that there are 301 bytes to send but it's content is logged as just "0x" and the whole message doesn't seem to be sent to the host at all (at least, the host won't send any further requests anymore). After commenting out the code that would output the dump (sstp-dump.c, lines 834 through 839), it is working fine. In this code, the len variable is decremented, maybe this affects the buffer itself as soon as it reaches a certain length. I don't have the skills to correct this, otherwise, I would have done so.
The protocol rejects
If I start the connection manually (usually pppd call <peer> while logged in as root, or a sudoer with sufficient privileges), everything works fine. But as soon as I start the connection using the exactly same settings in /etc/network/interfaces (defining the connection as an interface), or using a script in /etc/init.d (bypassing systemctl), the connection is established successfully, but afterwards I get protocol rejects from the host when e.g. sending ICMP echo requests through the connection. This happens on both machines I've tried on so far.
Did anyone experience this kind of bahaviour before and what could be the cause? I doubt it's privileges because the SSTP host complains about an invalid protocol number - when dumping the whole traffic (--log-level 6), the data actually has this 'invalid' protocol specification in the place expected.</peer>
Thanks and best regards
Thorben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Is the EAP-TLS patch to PPPd generally available, or did you have to compile that by yourself?
I'd love to take a look at this if you are able to provide me with a setup I can test this on? Generally the SSTP protocol require a hash to be sent to server with its SSTP CONNECTED message which is computed by using the MPPE keys negotiated at the EAP protocol. The problem in the past has been to provide the pppd-plugin a way to grab these keys and send them back up to sstpc such that it can generate the correct hash it sends to the server.
The logging issue is a different one, it probably doesn't understand the EAP packets.
I was digging around with sstpc and the ppp EAP-TLS patch to connect to an Azure VPN Gateway using a P2S connection and everything is working fine, except one scenario I can't explain. But first things first:
I'm using Ubuntu 18.04.2, ppp 2.4.7 (with EAP-TLS patch 1.102) and sstpc 1.0.12. I tested on two different machines, an Lenovo Thinkpad (64-Bit Intel) )and a Raspberry Pi 2.
The "logging bug"
When I connect to the SSTP host, during EAP-TLS authentication EAP will send a TLS "Client Hello". This EAP Response (CONFACK) is dumped in the logs, it tells that there are 301 bytes to send but it's content is logged as just "0x" and the whole message doesn't seem to be sent to the host at all (at least, the host won't send any further requests anymore). After commenting out the code that would output the dump (sstp-dump.c, lines 834 through 839), it is working fine. In this code, the len variable is decremented, maybe this affects the buffer itself as soon as it reaches a certain length. I don't have the skills to correct this, otherwise, I would have done so.
The protocol rejects
If I start the connection manually (usually pppd call <peer> while logged in as root, or a sudoer with sufficient privileges), everything works fine. But as soon as I start the connection using the exactly same settings in /etc/network/interfaces (defining the connection as an interface), or using a script in /etc/init.d (bypassing systemctl), the connection is established successfully, but afterwards I get protocol rejects from the host when e.g. sending ICMP echo requests through the connection. This happens on both machines I've tried on so far.
Did anyone experience this kind of bahaviour before and what could be the cause? I doubt it's privileges because the SSTP host complains about an invalid protocol number - when dumping the whole traffic (--log-level 6), the data actually has this 'invalid' protocol specification in the place expected.</peer>
I think I can provide you with an environment to run tests against - which parts do you need? Do you have an Azure Gateway in place? Otherwise, I can create one and send you an options/peer file and certificates?
Thanks again and best regards
Thorben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you talked to the pppd guys to see if they'd be interested in picking up these patches in e.g. pppd via http://ppp.samba.org?
I think that'd be the place to start in order to get the mainstream pppd fixed for all Linux platforms. The other issue is that Apple's pppd does implement EAP authentication, but you can't build pppd for Apple less you have the appropriate privileges (and source code).
Having that said, if someone does happen to have a working pppd with the patches it would be nice if the pppd-plugin that sstpc provides wouldn't require this patched pppd but gladly "detect" the patched version and fail gracefully if otherwise -- that can be tricky ..
If you have a dummy account, configuration and certificates, I'd be happy to take it and play with it. You can email me the information to: eivnaes [at] yahoo.com. Also, some instructions on how to quickly build that version of pppd.
Regards,- Eivind
På onsdag 19. juni 2019, 16:36:34 PDT skrev KeyBits <thorbenw@users.sourceforge.net> følgende:
I think I can provide you with an environment to run tests against - which parts do you need? Do you have an Azure Gateway in place? Otherwise, I can create one and send you an options/peer file and certificates?
I set up a testing/development environment and sent you the according information and files.
I agree it would be more than nice to have the patch generally available, but I can't tell why this hasn't yet happened and I'm not the maintainer - but I'll forward this suggestion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I was digging around with sstpc and the ppp EAP-TLS patch to connect to an Azure VPN Gateway using a P2S connection and everything is working fine, except one scenario I can't explain. But first things first:
I'm using Ubuntu 18.04.2, ppp 2.4.7 (with EAP-TLS patch 1.102) and sstpc 1.0.12. I tested on two different machines, an Lenovo Thinkpad (64-Bit Intel) )and a Raspberry Pi 2.
The "logging bug"
When I connect to the SSTP host, during EAP-TLS authentication EAP will send a TLS "Client Hello". This EAP Response (CONFACK) is dumped in the logs, it tells that there are 301 bytes to send but it's content is logged as just "0x" and the whole message doesn't seem to be sent to the host at all (at least, the host won't send any further requests anymore). After commenting out the code that would output the dump (sstp-dump.c, lines 834 through 839), it is working fine. In this code, the len variable is decremented, maybe this affects the buffer itself as soon as it reaches a certain length. I don't have the skills to correct this, otherwise, I would have done so.
The protocol rejects
If I start the connection manually (usually pppd call <peer> while logged in as root, or a sudoer with sufficient privileges), everything works fine. But as soon as I start the connection using the exactly same settings in /etc/network/interfaces (defining the connection as an interface), or using a script in /etc/init.d (bypassing systemctl), the connection is established successfully, but afterwards I get protocol rejects from the host when e.g. sending ICMP echo requests through the connection. This happens on both machines I've tried on so far.
Did anyone experience this kind of bahaviour before and what could be the cause? I doubt it's privileges because the SSTP host complains about an invalid protocol number - when dumping the whole traffic (--log-level 6), the data actually has this 'invalid' protocol specification in the place expected.</peer>
Thanks and best regards
Thorben
Hello,
Is the EAP-TLS patch to PPPd generally available, or did you have to compile that by yourself?
I'd love to take a look at this if you are able to provide me with a setup I can test this on? Generally the SSTP protocol require a hash to be sent to server with its SSTP CONNECTED message which is computed by using the MPPE keys negotiated at the EAP protocol. The problem in the past has been to provide the pppd-plugin a way to grab these keys and send them back up to sstpc such that it can generate the correct hash it sends to the server.
The logging issue is a different one, it probably doesn't understand the EAP packets.
Cheers,- Eivind
På onsdag 19. juni 2019, 13:45:57 PDT skrev KeyBits thorbenw@users.sourceforge.net følgende:
Hello all,
I was digging around with sstpc and the ppp EAP-TLS patch to connect to an Azure VPN Gateway using a P2S connection and everything is working fine, except one scenario I can't explain. But first things first:
I'm using Ubuntu 18.04.2, ppp 2.4.7 (with EAP-TLS patch 1.102) and sstpc 1.0.12. I tested on two different machines, an Lenovo Thinkpad (64-Bit Intel) )and a Raspberry Pi 2.
The "logging bug"
When I connect to the SSTP host, during EAP-TLS authentication EAP will send a TLS "Client Hello". This EAP Response (CONFACK) is dumped in the logs, it tells that there are 301 bytes to send but it's content is logged as just "0x" and the whole message doesn't seem to be sent to the host at all (at least, the host won't send any further requests anymore). After commenting out the code that would output the dump (sstp-dump.c, lines 834 through 839), it is working fine. In this code, the len variable is decremented, maybe this affects the buffer itself as soon as it reaches a certain length. I don't have the skills to correct this, otherwise, I would have done so.
The protocol rejects
If I start the connection manually (usually pppd call <peer> while logged in as root, or a sudoer with sufficient privileges), everything works fine. But as soon as I start the connection using the exactly same settings in /etc/network/interfaces (defining the connection as an interface), or using a script in /etc/init.d (bypassing systemctl), the connection is established successfully, but afterwards I get protocol rejects from the host when e.g. sending ICMP echo requests through the connection. This happens on both machines I've tried on so far.
Did anyone experience this kind of bahaviour before and what could be the cause? I doubt it's privileges because the SSTP host complains about an invalid protocol number - when dumping the whole traffic (--log-level 6), the data actually has this 'invalid' protocol specification in the place expected.</peer>
Thanks and best regards
Thorben
Protocol rejects and logging bug
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/sstp-client/discussion/1499218/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Hello Eivind,
first of all, thanks for your reply!
Unfortunately, the EAP-TLS patch doesn't seem to be generally available - I downloaded it from https://www.nikhef.nl/~janjust/ppp/index.html and compiled everything myself.
I think I can provide you with an environment to run tests against - which parts do you need? Do you have an Azure Gateway in place? Otherwise, I can create one and send you an options/peer file and certificates?
Thanks again and best regards
Thorben
Have you talked to the pppd guys to see if they'd be interested in picking up these patches in e.g. pppd via http://ppp.samba.org?
I think that'd be the place to start in order to get the mainstream pppd fixed for all Linux platforms. The other issue is that Apple's pppd does implement EAP authentication, but you can't build pppd for Apple less you have the appropriate privileges (and source code).
Having that said, if someone does happen to have a working pppd with the patches it would be nice if the pppd-plugin that sstpc provides wouldn't require this patched pppd but gladly "detect" the patched version and fail gracefully if otherwise -- that can be tricky ..
If you have a dummy account, configuration and certificates, I'd be happy to take it and play with it. You can email me the information to: eivnaes [at] yahoo.com. Also, some instructions on how to quickly build that version of pppd.
Regards,- Eivind
Hello Eivind,
first of all, thanks for your reply!
Unfortunately, the EAP-TLS patch doesn't seem to be generally available - I downloaded it from https://www.nikhef.nl/~janjust/ppp/index.html and compiled everything myself.
I think I can provide you with an environment to run tests against - which parts do you need? Do you have an Azure Gateway in place? Otherwise, I can create one and send you an options/peer file and certificates?
Thanks again and best regards
Thorben
Protocol rejects and logging bug
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/sstp-client/discussion/1499218/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
I set up a testing/development environment and sent you the according information and files.
I agree it would be more than nice to have the patch generally available, but I can't tell why this hasn't yet happened and I'm not the maintainer - but I'll forward this suggestion.