Authenticate ephemeral key exchange At the moment I'm designing a crytosystem for a VPN server. One of the requirements is Perfect Forward Secrecy, but I'n not sure how to implement authentication on the ephemeral key exchange.

If both parties possess a signed public key (signed by a CA or common trusted party) and exchange this, they can verify the identity of each other through the CA's public key. To implement perfect forward secrecy, both parties have to generate an ephemeral keypair and send each other the public key. Since these keys are not signed, how can one authenticate the other to guarantee that the keys were not altered/switched? Even if the keys are exchanged over an verified channel (for example using the signed and trusted public keys) that doesn't automatically ensure the ephemeral keys were generated by the same party. Also calculating a MAC over the public ephemeral key does not lead to a secure cryptoscheme since the public key could have been created by an man-in-the-middle in the first place. Is there any way the ephemeral key exchange can be authenticated?
I think you're confusing some things here.

The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly.

And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't compromise secrecy of future sessions if a long-term key is leaked, meaning PFS won't protect you against man-in-the-middle attacks if your long-term key is compromised, but very well against passive eavesdroppers.

So the usual key-exchange protocol makes use of the Diffie-Hellman protocol to let both parties agree on a common secret. The values exchanged for this sub-protocol are called public keys and if not authenticated may be subject to a man-in-the-middle attack, but the use of DH prevents passive eavesdropping, thereby yieldin the requested forward secrecy. Those public keys are also completely random (not a random bitstring though).

Now to prevent man-in-the-middle attacks each party signs their DH public keys using the key corresponding to the one in their valid CA signed certificate. If this key is leaked, the contents of future communication are not leaked unless the attacker uses a MitM attack, so PFS is preserved and MitM are prevented if the signature key is not compromised.

TL;DR: There are two public keys, one is long-term and one is short-term, the long-term one is CA authenticated and authenticates the short-term one thereby preventing MitM attacks and the short-term one yields the desired PFS property.