Openvpn prototype

[pincher95]

Hi Jared,

• Add new OpenVPN server endpoint /api/v1/services/openvpn/server, GET/POST/PUT/DELETE.
• Added new error responses (2098-2145).
• Updated docs (openapi)
• Added e2e tests test_api_v1_services_openvpn_server.py

[mitch40]

Hi, i would like to test OpenVPNServer functionality for one of my usecase, but i'm not very familiar with github manipulation...

To use pfsense API, i used the released package .txz, but what am i supposed to do in this case ?
"Git clone" the branch and rebuild the package, something like that?

I've seen the file tools/make_package.py, but it seems to do some works with ssh/scp ,so requires user/password, so i think this is for your own usage?

Thanks.

[pincher95]

Hi @mitch40 ,

First of all this is PR discussion and not issue/question related thread.

Second this is a PR and not yet merged to master, pending testing and evaluation by Jared, if you like to test OpenVPN Server API endpoint and share any bugs found you can clone my repo and compile the package from https://github.com/pincher95/pfsense-api/tree/openvpn_prototype.

Furthermore Jared added docs ,tools/README.md, how to compile the package from source.

Good luke.

[mitch40]

@pincher95 Thanks for your advice, I suceed to build and deploy the tarball from your source code!

I am testing using the example you provided in the documentation and just encountered an error.

The interface I want the openvpn server to listen on is not the default interface(so not "wan", but "inetbox").
This interface ("inetbox") is already configured and functional.

When I call the API, I get the following error message:
{'status': 'bad request', 'code': 400, 'return': 2101, 'message': 'Unknown OpenVPN Server/Client Interface', 'data': []}

I also tried to play with the lower/upper case, as well as the interface id (em1), I still get the same error.

Datas sended:
{ "client-id":"admin", "client-token":"pfsense", "mode":"p2p_tls", "protocol":"udp4", "authmode":"Local Database", "dev_mode":"tun", "interface":"inetbox", "local_port":1194, "description":"My VPN", "custom_options":"push \"route 10.0.0.0 255.255.255.0\";", "tls":"-----BEGIN OpenVPN Static key V1----- db8701afd882d746be67f084bae68470 54a99ef3b61864cfe1864c6c02584335 fe706df150250bf7e294b8c35911817c 133c8d9b505573ebeb65259bc54c70ae 88cc3163fd11a20f73d2c6fb3eea7cc2 fdaefcde510486adc0acbb9481b3aef4 930db91806469218b2a4f92e71787cf4 635f5b3f773fefc28d492738d2648673 8fa9b23d41e5999f58c3f0004a59ecda 119162e598764d9c8f6b99e7054f3ea4 fdb4461913d2e3273a8a0db29332406a 237bcfccca2315445ef809eaa933fa30 a9a7510d2d167033edfd3580a824f3e1 1af57da6eee89e6318ec29c67da8a19d 7c9d74c7afac6ee0f813a0278a6261d7 a28e7bdbf1743527346bda359bc92fc9 -----END OpenVPN Static key V1-----", "tls_type":"auth", "tlsauth_keydir":"default", "shared_key":"-----BEGIN OpenVPN Static key V1----- db8701afd882d746be67f084bae68470 54a99ef3b61864cfe1864c6c02584335 fe706df150250bf7e294b8c35911817c 133c8d9b505573ebeb65259bc54c70ae 88cc3163fd11a20f73d2c6fb3eea7cc2 fdaefcde510486adc0acbb9481b3aef4 930db91806469218b2a4f92e71787cf4 635f5b3f773fefc28d492738d2648673 8fa9b23d41e5999f58c3f0004a59ecda 119162e598764d9c8f6b99e7054f3ea4 fdb4461913d2e3273a8a0db29332406a 237bcfccca2315445ef809eaa933fa30 a9a7510d2d167033edfd3580a824f3e1 1af57da6eee89e6318ec29c67da8a19d 7c9d74c7afac6ee0f813a0278a6261d7 a28e7bdbf1743527346bda359bc92fc9 -----END OpenVPN Static key V1-----", "caref":"61c7fbce3a351", "crlref":"61c467cd2fd4f", "certref":"61c4121240420", "ocspcheck":false, "ocspurl":"", "dh_length":"2048", "ecdh_curve":"none", "cert_depth":"one", "strictusercn":false, "ncp_enable":false, "data_ciphers":"AES-256-GCM,AES-128-GCM,CHACHA20-POLY1305", "data_ciphers_fallback":"AES-256-CBC", "digest":"SHA256", "engine":"none", "tunnel_network":"", "tunnel_networkv6":"", "local_network":"", "local_networkv6":"", "remote_network":"", "remote_networkv6":"", "redirect_gateway":false, "redirect_gateway6":false, "serverbridge_dhcp":"", "serverbridge_interface":"none", "serverbridge_routegateway":true, "serverbridge_dhcp_start":"", "serverbridge_dhcp_end":"", "concurrent_connections":10, "allow_compression":"no", "compression":"none", "compression_push":false, "passtos":false, "client2client":false, "duplicate_cn":false, "dynamic_ip":false, "topology":"subnet", "dns_domain":"example.com", "dns_servers":"8.8.8.8, 8.8.4.4, 8.8.3.3, 8.8.2.2", "push_blockoutsidedns":false, "push_register_dns":false, "inactive_seconds":300, "ping_method":"keepalive", "keepalive_interval":10, "keepalive_timeout":60, "ping_seconds":10, "ping_action_seconds":60, "ping_push":false, "ping_action_push":false, "ping_action":"ping_restart", "username_as_common_name":false, "udp_fast_io":false, "exit_notify":"none", "sndrcvbuf":"default", "ntp_servers":"192.168.56.101, 192.168.56.102", "netbios_enable":false, "netbios_node_type":"b", "netbios_scope":"5", "create_gw":"both", "verbosity_level":"3", "wins_servers":"192.168.56.103, 192.168.56.104", "disable":false }

By curiosity, i changed interface to "wan", and i've an other error, not the same:
{'status': 'bad request', 'code': 400, 'return': 2110, 'message': 'Unknown OpenVPN Server Hardware Crypto Engine', 'data': []}

[mitch40]

The "inetbox" interface, is the old "lan" interface, it has been renamed by one of my provision script... Despite displayed name is "inetbox" throught pfsense webadmin, "lan" seems to be kept somewhere, and it's these value that you use in your script.

[mitch40]

For the 'Unknown OpenVPN Server Hardware Crypto Engine' error, i've tried to change modify the engine property with the unique existing (rdrand) in the dropdown item, but same result...

[mitch40]

@pincher95 do you have an idea how can i workaround it? Thanks

[jaredhendrickson13]

@pincher95 I've only had a quick look through this, so far it looks pretty good. I will continue to review this as time permits, but this one is quite large so it could take some time. My primary focus for the near future is bug/consistency fixes, testing enhancements, and addressing small gaps in functionality for the existing codebase to accommodate some changes that are likely coming soon. Until I know more about what those changes will look like, I am hesitant to merge in new features of this size.

In the meantime, this can be installed and tested by either building the package off the source branch, or simply patching an existing installation of the API (v1.4.1) with the changed files. Having multiple users testing this would be ideal and would definitely speed up getting this merged in.

I appreciate all the work.

Thanks!

[pincher95]

@mitch40 committed fix for engine detection.
You don't need to pass all parameters as many of them are set to default value, checkout documentation for default setting.
Regarding interface as time permits i'll add interface detection by description, the primary focus for now is bug hunting and not feature addition.

Keep up the good work.

Thanks.

[mitch40]

@pincher95 , i've rebuild package, and re-deployed my lab... IT WORKKKKKS ! Thank you for your patch !

In large lines, i've tested with

• Server Mode: SSL/TLS + User Auth
• Backend for authenticatio: Local Database

[jaredhendrickson13]

@pincher95 for the interface lookup, there is a built in API tool function you can leverage to lookup the interface by the descriptive interface name, physical interface ID (e.g. igb0), or the internal pfSense interface ID (wan, lan, opt1, etc.). Most endpoints use this for interface lookups as it allows clients to specify the interface in a more human friendly way and simplifies validation.

A usage example can be seen here:

pfsense-api/pfSense-pkg-API/files/etc/inc/api/models/APIFirewallRuleCreate.inc

Line 59 in 04947b1

$this->initial_data['interface'] = APITools\get_pfsense_if_id($this->initial_data['interface']);

This will lookup the interfaces by any of the above interface identifiers and return the internal pfSense interface ID each time. If an interface could not be found with any of those identifiers, the function will return null so it can also be used to check for the existence of an interface as well.

[pincher95]

@jaredhendrickson13 Thanks for the tip, refactored interface lookup using this function.

@mitch40 following @jaredhendrickson13 tip OpenVPN server interface lookup refactored, using interface descriptive name was added

[jaredhendrickson13]

Okay this looks pretty solid. Thanks for your patience. Since this is a larger feature, I've changed the target branch to v150 so it can be tested and released alongside other OpenVPN endpoints being staged. If you'll resolve the last conflict, I'll merge this into that branch and make an early development/test build available for v1.5.0.

[pincher95]

@jaredhendrickson13 To resolve the conflict i'll have to go over all models, framework and of course e2e tests and change all response codes, at the moment i simply don't have time for this and i don't know when i'll. For the time been you can leave the PR as is until i get around for this or close it, what ever you decide.

[pincher95]

@jaredhendrickson13 response codes fixed, please merge it.