2.5.0 and 2.4.9 interoperability issue (MPPE key miscalculation when using radius to authenticate)

[jkroonza]

Connecting using pptp as well as l2tp (less so on l2tp) gives lots of problems.

Debugging still to be done, just want to get this raised and logged in case someone else has run into and fixed this, or such that we can collaborate on the debug effort. Will post debug logs as soon as possible.

Problems are always with 2.5.0 on the "server" side, and 2.4.9 or windows built-in on the client. This leads me to believe that the problem resides on the server side of 2.5.0.

When connecting using 2.5.0 from the "client" side all seems fine.

2.4.9 outputs messages like "Protocol-Reject for unsupported protocol 'RTP IPHC Compressed TCP' (0x63)"

[jkroonza]

server side log:

Plugin radius.so loaded.
RADIUS plugin initialized.
Plugin radattr.so loaded.
RADATTR plugin initialized.
pppd 2.5.0 started by root, uid 0
using channel 282
Using interface ppp2
Script /etc/ppp/net-init started (pid 1974)
Script /etc/ppp/net-init finished (pid 1974), status = 0x1
Connect: ppp2 <--> /dev/pts/0
sent [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x6909628d> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x6909628d> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1200> <asyncmap 0x0> <magic 0x68ec8ab4> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1200> <asyncmap 0x0> <magic 0x68ec8ab4> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x6909628d]
sent [CHAP Challenge id=0x90 <e8280b07bd91bc0118bc61bb2160f1ce>, name = "pptpd"]
rcvd [LCP EchoReq id=0x0 magic=0x68ec8ab4]
sent [LCP EchoRep id=0x0 magic=0x6909628d]
rcvd [LCP EchoRep id=0x0 magic=0x68ec8ab4]
rcvd [CHAP Response id=0x90 <6e375b5cd0a30dd4d30a703c5507908100000000000000006d75f088086d22829623b5068a0cf698be71ad41a6c1eb0900>, name = "jkroon"]
RADATTR plugin wrote 8 line(s) to file /var/run/radattr.ppp2.
sent [CHAP Success id=0x90 "S=6B01D1DAE8D308F1A13FF4C0F1E4ED147A9538CE"]
peer from calling number 154.73.32.4 authorized
Script /etc/ppp/auth-up started (pid 2023)
Script /etc/ppp/net-pre-up started (pid 2024)
Script /etc/ppp/net-pre-up finished (pid 2024), status = 0x1
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Script /etc/ppp/auth-up finished (pid 2023), status = 0x1
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.85.76.83>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.85.76.83>]
rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>]
sent [IPCP ConfNak id=0x2 <addr 192.168.0.10>]
rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 192.168.0.10>]
sent [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 192.168.0.10>]
Script /etc/ppp/ip-pre-up started (pid 2095)
Script /etc/ppp/ip-pre-up finished (pid 2095), status = 0x1
Cannot determine ethernet address for proxy ARP
local  IP address 10.85.76.83
remote IP address 192.168.0.10
Script /etc/ppp/ip-up started (pid 2139)
Script /etc/ppp/ip-up finished (pid 2139), status = 0x1
rcvd [proto=0xe867] 23 6b a9 30 38 5f 28 78 dc 30 b2 ae 22 da 8c 45 66 9a ac 25 ad 4b b3 d0 84 b7 16 78 90 1d e6 33 ...
Unsupported protocol 0xe867 received
sent [LCP ProtRej id=0x2 e8 67 23 6b a9 30 38 5f 28 78 dc 30 b2 ae 22 da 8c 45 66 9a ac 25 ad 4b b3 d0 84 b7 16 78 90 1d ...]
rcvd [proto=0x36e2] d0 42 0f fe 89 48 2b 62 8c 18 89 e6 01 70 f1 2b a6 ab 3f f0 88 1d b2 79 86 5e fc 0f 82 e3 26 b0 ...
Unsupported protocol 0x36e2 received
sent [LCP ProtRej id=0x3 36 e2 d0 42 0f fe 89 48 2b 62 8c 18 89 e6 01 70 f1 2b a6 ab 3f f0 88 1d b2 79 86 5e fc 0f 82 e3 ...]
rcvd [proto=0xb41d] e2 67 52 db c6 86 0b 79 8a d3 20 3d 40 2c b5 a3 1d 52 a6 b9 57 b4 f7 59 1b f1 5b 0a 3c 37 8a 51 ...
Unsupported protocol 0xb41d received
sent [LCP ProtRej id=0x4 b4 1d e2 67 52 db c6 86 0b 79 8a d3 20 3d 40 2c b5 a3 1d 52 a6 b9 57 b4 f7 59 1b f1 5b 0a 3c 37 ...]
rcvd [proto=0xe641] 63 0c 5b 01 22 ee e8 a7 87 63 9c f6 d8 bf 79 6e 9b d2 88 21 a1 b5 dd 87 d8 83 b7 1c 18 75 e5 0a ...
Unsupported protocol 0xe641 received
sent [LCP ProtRej id=0x5 e6 41 63 0c 5b 01 22 ee e8 a7 87 63 9c f6 d8 bf 79 6e 9b d2 88 21 a1 b5 dd 87 d8 83 b7 1c 18 75 ...]
rcvd [proto=0xbabc] a2 b9 76 55 63 1a 3f c6 e6 a7 8b f7 8c 4c c3 ac c9 96 0b 20 e8 0f 02 74 20 ab 46 db 19 0a 7a ca ...
Unsupported protocol 0xbabc received
sent [LCP ProtRej id=0x6 ba bc a2 b9 76 55 63 1a 3f c6 e6 a7 8b f7 8c 4c c3 ac c9 96 0b 20 e8 0f 02 74 20 ab 46 db 19 0a ...]
rcvd [proto=0xfb] 2a ab 66 38 3e 2f 84 c1 b7 a9 ce 40 af b0 cb af 77 35 4a ec b1 66 eb d7 4c 26 18 f5 50 f5 78 f2 ...
Unsupported protocol 'single-link compression' (0xfb) received
sent [LCP ProtRej id=0x7 00 fb 2a ab 66 38 3e 2f 84 c1 b7 a9 ce 40 af b0 cb af 77 35 4a ec b1 66 eb d7 4c 26 18 f5 50 f5 ...]
rcvd [proto=0xaf] 7b 24 41 b8 84 0b ae 5d 36 7d 5d 7e 5d 69 6f aa 7a f8 19 f7 1d cb 27 2c 86 f3 c1 98 bf 35 33 37 ...
Unsupported protocol 0xaf received
sent [LCP ProtRej id=0x8 00 af 7b 24 41 b8 84 0b ae 5d 36 7d 5d 7e 5d 69 6f aa 7a f8 19 f7 1d cb 27 2c 86 f3 c1 98 bf 35 ...]
Modem hangup
Script /etc/ppp/auth-down started (pid 4647)
Connect time 0.6 minutes.
Sent 0 bytes, received 590 bytes.
Script /etc/ppp/ip-down started (pid 4683)
MPPE disabled
sent [LCP TermReq id=0x9 "MPPE disabled"]
Script /etc/ppp/net-down started (pid 4684)
Connection terminated.
Script /etc/ppp/auth-down finished (pid 4647), status = 0x1
Script /etc/ppp/ip-down finished (pid 4683), status = 0x1
Script /etc/ppp/net-down finished (pid 4684), status = 0x1
Fatal signal 11

(Fatal signal 11 described in #454)

Client side log:

using channel 182
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <mru 1200> <asyncmap 0x0> <magic 0x68ec8ab4> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x6909628d> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x6909628d> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1200> <asyncmap 0x0> <magic 0x68ec8ab4> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 1200> <asyncmap 0x0> <magic 0x68ec8ab4> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x68ec8ab4]
rcvd [LCP EchoReq id=0x0 magic=0x6909628d]
sent [LCP EchoRep id=0x0 magic=0x68ec8ab4]
rcvd [CHAP Challenge id=0x90 <e8280b07bd91bc0118bc61bb2160f1ce>, name = "pptpd"]
added response cache entry 0
sent [CHAP Response id=0x90 <6e375b5cd0a30dd4d30a703c5507908100000000000000006d75f088086d22829623b5068a0cf698be71ad41a6c1eb0900>, name = "jkroon"]
rcvd [LCP EchoRep id=0x0 magic=0x6909628d]
rcvd [CHAP Success id=0x90 "S=6B01D1DAE8D308F1A13FF4C0F1E4ED147A9538CE"]
response found in cache (entry 0)
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.85.76.83>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.85.76.83>]
rcvd [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 192.168.0.10>]
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 192.168.0.10>]
rcvd [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 192.168.0.10>]
Script /etc/ppp/ip-pre-up started (pid 30120)
Script /etc/ppp/ip-pre-up finished (pid 30120), status = 0x0
local  IP address 192.168.0.10
remote IP address 10.85.76.83
Script /etc/ppp/ip-up started (pid 30157)
Script /etc/ppp/ip-up finished (pid 30157), status = 0x0
rcvd [LCP ProtRej id=0x2 e8 67 23 6b a9 30 38 5f 28 78 dc 30 b2 ae 22 da 8c 45 66 9a ac 25 ad 4b b3 d0 84 b7 16 78 90 1d ...]
Protocol-Reject for unsupported protocol 0xe867
rcvd [LCP ProtRej id=0x3 36 e2 d0 42 0f fe 89 48 2b 62 8c 18 89 e6 01 70 f1 2b a6 ab 3f f0 88 1d b2 79 86 5e fc 0f 82 e3 ...]
Protocol-Reject for unsupported protocol 0x36e2
rcvd [LCP ProtRej id=0x4 b4 1d e2 67 52 db c6 86 0b 79 8a d3 20 3d 40 2c b5 a3 1d 52 a6 b9 57 b4 f7 59 1b f1 5b 0a 3c 37 ...]
Protocol-Reject for unsupported protocol 0xb41d
rcvd [LCP ProtRej id=0x5 e6 41 63 0c 5b 01 22 ee e8 a7 87 63 9c f6 d8 bf 79 6e 9b d2 88 21 a1 b5 dd 87 d8 83 b7 1c 18 75 ...]
Protocol-Reject for unsupported protocol 0xe641
rcvd [LCP ProtRej id=0x6 ba bc a2 b9 76 55 63 1a 3f c6 e6 a7 8b f7 8c 4c c3 ac c9 96 0b 20 e8 0f 02 74 20 ab 46 db 19 0a ...]
Protocol-Reject for unsupported protocol 0xbabc
rcvd [LCP ProtRej id=0x7 00 fb 2a ab 66 38 3e 2f 84 c1 b7 a9 ce 40 af b0 cb af 77 35 4a ec b1 66 eb d7 4c 26 18 f5 50 f5 ...]
Protocol-Reject for unsupported protocol 'single-link compression' (0xfb)
rcvd [LCP ProtRej id=0x8 00 af 7b 24 41 b8 84 0b ae 5d 36 7d 5d 7e 5d 69 6f aa 7a f8 19 f7 1d cb 27 2c 86 f3 c1 98 bf 35 ...]
Protocol-Reject for unsupported protocol 0xaf
^CTerminating on signal 2
Modem hangup
Connect time 0.6 minutes.
Sent 588 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 32274)
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
Connection terminated.
Script /etc/ppp/ip-down finished (pid 32274), status = 0x0
Waiting for 1 child processes...
  script /usr/sbin/pptp arthur.iewc.co.za --nolaunchpppd, pid 30102
sending SIGTERM to process 30102

The Protocol-Reject approximately co-incides with the ping command I ran to get traffic on the link.

Could be related to GRE. encapsulation/decapsulation but afaik that's handled in-kernel.

I've got a few theories, pending on how accurately we can reproduce on l2tp (which I was told we can but I'm no longer convinced), looks like this could be a crypto key issue for MPPE possibly. Possibly in collaboration with radius authentication. More work required.

Downgrading the server ONLY works, ie, 2.4.9 on the server then everything works as expected, client can be either 2.4.9 OR 2.5.0.

Will get confirmation on L2TP situation as soon as possible.

[Neustradamus]

@enaess, @paulusmack: What do you think?

[jkroonza]

This somehow relates to radius authentication, if I use /etc/ppp/chap-secrets to authenticate the client everything works as expected.

[Neustradamus]

@paulusmack, @enaess, @tisj, @jjkeijser, @Sander80, @EasyNetDev, @rustylife, @sthibaul: What do you think?

[jjkeijser]

Impossible to tell for sure without adding debug statements to the code, but the whole PPP_Digest_* rewrite seems to be the cause; especially the fact that without Radius it does work, seems to suggest to me that the function mppe_set_enc_types is the culprit, as that is called from within the Radius plugin. I'd begin by adding debug statements there in both the 2.4.9 tree and the 2.5.0 tree.

[enaess]

Yeah, my hunch would likely be in the configuration of wrong mppe keys for decryption / encryption in this case. When I did this refactoring, I had no way to test radius code paths. Probably, my fault and also a regression. Should be fixed before 2.5.1 goes out the door IMO

[enaess]

How can I configure using radius authentication with PPP @jkroonza ?

[jkroonza]

@enaess do you have a static IP I can permit you to send radius from?

The ppp configuration side is fairly easy (extracts as needed, tried to trim this down, we also use radattr.so):

options file:

plugin radius.so

radius-config-file /etc/ppp/radius-lns.conf

avpair NAS-Identifier=some_hostname_here
map-to-ifname

ppp radius only sends one of NAS-Identifier (and usually gets it wrong) or NAS-IP-Address, we want both, so the above generally gets it right. Don't recall why we needed/wanted map-to-ifname, but it changed something that ended up being more in line with some other major setup which also auths against our radius servers.

radius-lns.conf

auth_order      radius

login_tries     4
login_timeout   15

authserver a.b.c.d:1812
acctserver a.b.c.d:1813

servers     /etc/ppp/radius/server-secrets
dictionary  /etc/ppp/radius/dictionary.uls

radius_timeout  5
radius_retries  2

seqfile         /var/run/radius.seq
mapfile         /etc/ppp/radius/port-id-map

Note that a.b.c.d we use 127.0.0.1 which runs into freeradius that can load balance against a set of remote radius servers, or in some cases, authenticate locally, and a few other options.

server-secrets:

a.b.c.d  secrethere

and dictionary-uls:

INCLUDE /etc/ppp/radius/dictionary

ATTRIBUTE   Framed-Route                22      string
ATTRIBUTE   Framed-Pool                 88      string

ATTRIBUTE   Operator-Name               126     string
ATTRIBUTE   Delegated-IPv6-Prefix-Pool  171     string
ATTRIBUTE   DNS-Server-IPv6-Address     169     ipv6addr

VENDOR      Ascend  529
ATTRIBUTE   Ascend-Data-Rate        197 integer Ascend

VENDOR      Mikrotik    14988
ATTRIBUTE   Mikrotik-Rate-Limit         8       string  Mikrotik

Don't see anything there that you specifically need for auth, so you can just point directly at /etc/ppp/radius/dictionary.

The above I think we merely have so that radattr will place more sensible name=value pairs in the radattr file, so for this bug I highly doubt this is relevant.

I can definitely provide you with remote access to send to one of our dev servers where radius is being run if that would help, alternatively also happy to dig into the code myself, if you perhaps have some ideas of where it MAY be going wrong I can certainly add debug code to those paths - just been away on holiday until today for a little over a week, and probably going to be playing a bit of catch-up this week.

[jkroonza]

At this stage, it seems that in my specific use-case at least, the radius.c module is invoking the mppe_set_keys directly, and not via one of the two chap() mechanisms, this calculation function has been heavily refactored, so I currently believe the problem to reside in that function in radius.c - I'm just wondering if there isn't perhaps a way to simply defer this calculation to mppe.c and invoke one of the two chap setters rather?

Incidentally, there is a possible problem here in mppe.c in that they key length is assumed to be the same for send-and receive (makes logical sense). So I don't believe this to be a major issue.

[jkroonza]

When generating the key material for decrypting the second half of the MPPE key material the refactor in commit 4cb90c1 () changed the key material from MD5(Secret + Crypt) to MD5(Secret + Crypt + Salt) ...

I did a bit of a refactor to not nest as deep as well as to output more sensible errors in case of failures, if this full refactor isn't desired I'm willing to go back and perform a minimum change fix rather ... but this full change is how I found the issue.