Hello Hang Zhou, I have no clue about the tun entry. Maybe it's usable to set up a connection, but I guess it's dependent on the Fortinet appliance version.

@rain2fog Also just wondering how portable would the tun entry be on macOS? Can you shed some light on the subject?

we simulated the PPP negotiation procedure. There are 3 stages in PPP protocal.
The 1th stage is LCP. client will send Magic-Number and MRU request to fortivpn server, then will ack the server request. server will send the Magic-Number and ack the client request.
The 2th stage is IPCP. both will will send the IPCP config-request to other. client need to send the IPCP config-request Option (3) with the IP which come from the XML. then both config-request need to be ack.
The 3th stage is 0x0021. we can read and write IP packet from tun NIC. then sending data by encapsulating or decapsulating the IP packet with header 0x0021(2 Bytes) + (totolsize(2 Bytes) + 0x5050 + pppsize(2 Bytes)).
we also need send the LCP echo-request to fortinet VPN to keep the TCP connection wouldn't close.

@rain2fog We spawn pppd because when openfortivpn had been written no PPP libraries were available at the time. Nowadays GPL-compatible PPP code is available: #650 (comment). Do you mean we could use TUN and such PPP code instead of spawning pppd? I'm not sure what we should do with the above information. Do you plan on providing a patch?

@DimitriPapadopoulos you are right. This is the patch for demo. tun.patch

@rain2fog Impressive work! I'll try to test it soon. Would you agree to open a pull request to discuss the patch?

Also how would you feel about using existing PPP code to ease maintenance or even help convergence between projects? For example see - by order of preference:

• recent PPP code in OpenConnect licensed under LGPL,
• lwIP embedded TCP/IP stack available under a 3-clause BSD license,
• Contiki 1 embedded operating system licensed under the 3-clause BSD license.

On the other hand the PPP implementation is rather short.

The progress is very easy. you can read the RFC1661 and RFC1332 to get the detail protocol design. this C patch came from my co-worker not me.

Would your coworker want to create a pull request? The idea is that her/his contribution are properly recognised. Plus we can discuss implementation details.

Just a reminder for myself. This should help handle both these methods proposed in the XML configuration sent by Fortigate appliances:
<tunnel-method value='ppp' /><tunnel-method value='tun' />

@rain2fog I have been maintaining your patch in my tun branch:
https://github.com/adrienverge/openfortivpn/tree/tun

I can see a couple CodeQL alerts in your code:

• https://github.com/adrienverge/openfortivpn/security/code-scanning/30
• https://github.com/adrienverge/openfortivpn/security/code-scanning/31

Also complier warnings:

In function ‘conf_option_encode’,
    inlined from ‘conf_request’ at src/io.c:415:2:
src/io.c:337:16: warning: ‘request.tail’ may be used uninitialized [-Wmaybe-uninitialized]
  337 |         optlist->tail->type = type;
      |         ~~~~~~~^~~~~~
src/io.c: In function ‘conf_request’:
src/io.c:410:33: note: ‘request’ declared here
  410 |         struct conf_option_list request;
      |                                 ^~~~~~~
In function ‘conf_option_encode’,
    inlined from ‘ipcp_packet’ at src/io.c:984:4:
src/io.c:337:16: warning: ‘request.tail’ may be used uninitialized [-Wmaybe-uninitialized]
  337 |         optlist->tail->type = type;
      |         ~~~~~~~^~~~~~
src/io.c: In function ‘ipcp_packet’:
src/io.c:981:49: note: ‘request’ declared here
  981 |                         struct conf_option_list request;
      |                                                 ^~~~~~~
In function ‘conf_option_encode’,
    inlined from ‘ipcp_packet’ at src/io.c:1038:4:
src/io.c:337:16: warning: ‘request.tail’ may be used uninitialized [-Wmaybe-uninitialized]
  337 |         optlist->tail->type = type;
      |         ~~~~~~~^~~~~~
src/io.c: In function ‘ipcp_packet’:
src/io.c:1035:49: note: ‘request’ declared here
 1035 |                         struct conf_option_list request;
      |                                                 ^~~~~~~