Daniel Lenski [Tue, 19 May 2020 17:54:22 +0000 (10:54 -0700)]
add standard-based PPP framing (RFC1661, RFC1662) as reference points
- PPP_ENCAP_RFC1661: Plain PPP. “Synchronous” in the ’90s-era language,
because the start and end of the frame are known from external means.
In modern instances, this is because they arrive in a complete packet with
a known length from its lower-level encapsulation. (TLS or DTLS records in
our expected use cases.)
This is what `pppd sync` does.
- PPP_ENCAP_RFC1662: “PPP in HDLC-like framing.”
This is what `pppd` without `sync` does.
At some point, we will be able to add automated testing of our PPP
implementation's ability to communicate with `pppd`.
There's no clear rationale for using with Pulse/oNCP ESP setup (yet):
- We don't do any MTU detection
- Unlike GPST, we can start sending and receiving packets via the TLS tunnel
immediately, while attempting to connect ESP as well.
Andreas Gnau [Sun, 17 May 2020 17:46:09 +0000 (19:46 +0200)]
ppp: Reject unknown protocols
NX won't send any IPCP requests until CCP negotiation is completed.
Since we don't want to implement compression for now (or ever), reject
unknown protocols with an LCP Protocol-Reject (cf. RFC 1661, ch. 5.7).
Daniel Lenski [Sun, 17 May 2020 19:46:43 +0000 (12:46 -0700)]
make delay_tunnel consistent with delay_close
1. Decrement counter on each mainloop iteration. Protocol needs to keep setting it to get more mainloop iterations before tunnel setup / close.
2. Value ≥2 causes us to set did_work=1, resulting in no delay before we call mainloop again. Protocol should only set this if it needs to SEND something in order to move things along.
3. Value =1 causes us to set did_work=0, resulting in a delay before we call mainloop again. Protocol should only set this if it needs to RECEIVE something in order to move things along.
Daniel Lenski [Sun, 17 May 2020 20:02:31 +0000 (13:02 -0700)]
attempt to coax server to accept a larger MRU by nak-offering our MTU if it's greater than the server's MRU
We only attempt this once before giving up.
Tested on F5, and this works: we nak-offer a larger MRU, and the server
responds with a new CONFACK requesting the same value.
The F5 server often offers erroneously low MRU values, too small for IPv6
(minimum MTU of 1280), and is consistently strict about not accepting
incoming IP packets which are even 1 byte larger than its MRU, so this is
useful. 🍺
Daniel Lenski [Sun, 17 May 2020 02:31:22 +0000 (19:31 -0700)]
add delay_close and use it for clean PPP termination on cancel, pause, or server-sent termination
Whatever delay_close is set to decrements on each mainloop iteration, and
if delay_close == 1, we don't set work_done.
This allows us to set delay_close = 2 for the case where we need to send a termination request
immediately, and then wait briefly for an acknowledgment.
Daniel Lenski [Sat, 16 May 2020 01:03:45 +0000 (18:03 -0700)]
use ACK/NAK request mechanism to request IPv4 address, (IPv4) DNS/NBNS addresses, and IPv6 interface identifiers
The idea is that if we CONFREQ an all-zero value for one of these.
PPP server/peer is supposed to:
- CONFNAK with a value filled in, which we then re-CONFREQ to confirm.
- CONFREJ if it can't supply a value (e.g. NBNS servers because it's
not 1994 and we're not using Windows for Workgroups 3.11).
Tested with F5, by overriding ppp->solicit_peerns=7, ppp->out_peer_addr.s_addr=0,
ppp->out_ipv6_int_ident=0 in openconnect_ppp_new (even though F5 in fact sends these
addresses in the XML config prior to PPP tunnel).
The CONFREQ/CONFNAK/re-CONFREQ exchange is inefficient, requiring three rounds trips
(request and reject, partial re-request and nak, confirming request and ack), but it
works:
Received proto 0x8021/id 1 Configure-Reject from server
Server rejected IPCP request for NBNS[1] server
Server rejected IPCP request for DNS[1] server
Server rejected IPCP request for NBNS[0] server
...
Sending our proto 0x8021/id 2 config request to server
< 0000: f5 00 00 10 80 57 02 01 00 0e 01 0a e0 a7 1c fb |.....W..........|
< 0010: 9e 55 00 00 |.U..|
Sending PPP IPCP Configure-Request packet (id 2, 22 bytes total)
> 0000: f5 00 00 12 80 21 01 02 00 10 03 06 00 00 00 00 |.....!..........|
> 0010: 81 06 00 00 00 00 |......|
No work to do; sleeping for 3000 ms...
< 0000: f5 00 00 12 80 21 03 02 00 10 03 06 0a 00 00 17 |.....!..........|
< 0010: 81 06 5a 9b 5c d1 |..Z.\.|
Received proto 0x8021/id 2 Configure-Nak from server
Server nak-offered IPv4 address: 10.0.0.23
Server nak-offered IPCP request for DNS[0] server: 90.155.92.209
...
Sending our proto 0x8021/id 3 config request to server
Sending PPP IPCP Configure-Request packet (id 3, 16 bytes total)
> 0000: f5 00 00 0c 80 21 01 03 00 0a 03 06 0a 00 00 17 |.....!..........|
No work to do; sleeping for 3000 ms...
< 0000: f5 00 00 0c 80 21 02 03 00 0a 03 06 0a 00 00 17 |.....!..........|
Received proto 0x8021/id 3 Configure-Ack from server
PPP state transition from OPENED to NETWORK
Current PPP state: NETWORK (encap F5):
in: asyncmap=0x00000000, lcp_opts=384, lcp_magic=0x04eb81f9, peer=1.1.1.1
out: asyncmap=0x00000000, lcp_opts=422, lcp_magic=0x70ac508f, peer=10.0.0.23, solicit_peerns=0
The purpose of the IPv6 interface identifier negotiation is unclear, but the F5
server does not accept a zero value, using CONFNAK to offer a new one.
Daniel Lenski [Fri, 15 May 2020 01:48:55 +0000 (18:48 -0700)]
attempted support for concatenated packets
Plus add comments about what each variable points to and when, during packet parsing.
Tested with F5 HDLC and non-HDLC. Doesn't complain about leftover bytes, or short/incomplete packets, but NOT YET
actually tested with concatenated packets.
Daniel Lenski [Wed, 13 May 2020 21:29:41 +0000 (14:29 -0700)]
add test-fortinet-login.py
Often easier to prototype HTTPS-based authentication flows in Python, since
they're so fiddly and arbitary. So I copied `test-f5-login.py` to
`test-fortinet-login.py`. Currently only handles basic
username-and-password auth, no 2FA:
positional arguments:
endpoint Fortinet server (or complete URL, e.g.
https://forti.vpn.com/remote/login)
extra Extra field to pass to include in the login query
string (e.g. "foo=bar")
optional arguments:
-h, --help show this help message and exit
-v, --verbose
--no-verify Ignore invalid server certificate
Login credentials:
-u USERNAME, --username USERNAME
Username (will prompt if unspecified)
-p PASSWORD, --password PASSWORD
Password (will prompt if unspecified)
-r REALM, --realm REALM
Realm (empty if unspecified)
-c CERT, --cert CERT PEM file containing client certificate (and optionally
private key)
--key KEY PEM file containing client private key (if not
included in same file as certificate)
```
David Woodhouse [Tue, 12 May 2020 21:27:24 +0000 (22:27 +0100)]
Handle ConfRej for anything that needs it.
If get a ConfReq with anything we don't want or understand — and that
includes bloody VJ header compression, since I'm not completely batshit
insane — send a ConfRej.
Do this by building up the options to be rejected in an oc_text_buf as
we go, then rejecting that set if it's non-empty once we get to the end.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 12 May 2020 21:12:25 +0000 (14:12 -0700)]
Fix un-HDLC corner cases
1) The initial 0x7e is optional, the final 0x7e is not (was reversed).
2) Dangling escape can occur even when we haven't run out of buffer. 0x7d 0x7e is an invalid sequence.
While not breaking…
3) 0x7d can be the “target” of an escape (0x7d 0x7d → 0x5d)
4) 0x5d as the “target” of an escape (0x7d 0x5d → 0x7d) doesn't indicate a new escape
Daniel Lenski [Tue, 12 May 2020 06:16:34 +0000 (23:16 -0700)]
simplify PPP header checking
There's no point whatsover to checking if the server is doing ACCOMP/PFCOMP
as negotiated:
- Even if negotiated, they're optional.
- Even if *not* negotiated, they're unambiguous.
- Either way, it's much easier just to ignore the negotiated options.
“Be liberal in what you accept, and conservative in what you send.”
Some day I will acquire a time machine, travel back to 1993, and ask the
designers of PPP not to add meaningless boilerplate bytes to their protocol
in such a uniquely strange-yet-approachable way that compels future implementers to
reinvent clever ways of dealing with them hundreds of times.
David Woodhouse [Mon, 11 May 2020 12:29:28 +0000 (13:29 +0100)]
Drop hdlc and we_go_first args from openconnect_ppp_new()
We should always go first for *our* outbound ConfReqs, not wait for the
server to go first. And HDLC can be inferred from the encap mode, to
which we can add PPP_ENCAP_F5_HDLC.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
projects / users / dwmw2 / openconnect.git / log