The latest UniPCemu commit has some new overrides for the support of the COM0COM signed driver.
So far managed to use the emulated modem (within UniPCemu used from a serial port on Windows 10) to connect to the server within the same application.
I see it negotiating LCP at least, but somewhere after that it fails? Using the terminal window inside Windows 10 to make it wait for the opening message before it starts sending PPP automatically fixes the PPP starting properly at least (due to Windows 10 not receiving all data once it starts doing that, thus the server can't start PPP properly because it can't start waiting for input because it's still in the output-only startup phase (asking for the username)).

The emulated serial modem seems to run at least (at least the sending to the packet server).
Edit: It seems to properly authenticate on the PPP server. But it doesn't seem to negotiate any networking protocols (Error 720)?
Edit: It seemed some weird behaviour of a (corrupted) MiniPort driver. Fixed by removing all from device manager and detecting them again.
I now see it properly authenticate and connect to the server, reaching the final state of being connected with a proper IP address on the private network (did setup the server to perform a local network for simplicity atm, but internet access and other host access (w/o broadcast addressing) is possible as well if configured for the actual network adapter of the host that connects to the real network).

Although atm for said functionality you'll have to compile the latest commit yourself (as it isn't released yet, the last release was just a few days ago after all). The only thing that changed so far is the improved PSP-style face button inputs and direct serial bugfix (it was always detecting the control port as having a value instead of detecting if it is actually set to a valid value(non-empty)) as well as this improvement (allowing detecting COM0COM without having to build the driver yourself and run windows in unsafe(unsigned) driver mode. So you can use it with Visual Studio community and build it (and SDL2+SDL2_net) yourself. Or do the same with the MinGW+MSYS2 toolchain until it's released sometime in the future.
Edit: Downgrading the COM0COM serial driver to 2.2 last version signed seems to fix installation on newer Win10 hardware (because of TPM?). The issue with the 720 error re-emerges? Perhaps I'm forgetting something else?

Edit: A FTP server works without issues. If properly configured on the machine, I can pull/put files and directories on the emulated machine from Windows 10 and change basically all files through FTP.
So a basic FTP server should work properly at least.

This is active in another forum, but I'll mention that I wrote a tool back in the 80's which I do find to be the simplest/best (for me) way to move files
on/off and between older DOS systems (real hardware and emulations):

DDLINK (available free from my site) is a tiny (16k) .COM which can move files between DOS systems over COM (serial), LPT (parallel), or LAN
(ethernet) ports.

It does not have to be "installed", does not need a NOS (or any other special software) to use LAN (it does require a Crynwr "packet driver" which are available for MANY NICs,
and are simple TSR .EXEs which can be loaded/unloaded "on the fly". It can even "bootstrap" itself to a new system over serial, requiring only the built in DOS CTTY command.

Although mainly designed as an interactive tool, after reading this thread, I've just added a new command line option to help facilitate non-interactive transfers
(ie: from BATCH files).

And though it is a DOS program, it does work well within DOSBOX, which makes it well suited to moving files to/from many more modern system types.

If you don't want the bulk of newer DOSBOX, there is an older/much-smaller one which works well - also on my site.

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)