La question m'intéresse aussi, pour un besoin différent, rapatrier l'adresse publique attribuée par le VPS OVH sur l' interface d'une machine virtuelle avec un tunnel tap.

De plus, j'avais pensé utiliser le NAT 1:1 avec iptables, vers l'IP du (des) client NATé sur Pfsense, ce qui revient au même que sur ta machine virtuelle, qui est le client. C'est pas de la "vraie" IP publique, mais toutes les connexions seraient alors renvoyés sur ta machine virtuelle, à la manière des "DMZ" sur les box d'opérateurs.
Et pour des besoins spécifiques on peut toujours utiliser le VPS directement.

http://www.cahilig.net/2010/10/28/how-enable-11-nat-iptables

Edit : grillé par kgersen, c'est à peu près ce que voyais

J'ai fini la configuration du VPS, OpenVPN fonctionne!

Les 2 clients sont en IP statique, 10.8.0.50 et 10.8.0.100. Pour l'instant je n'ai pas besoin d'héberger des choses derrière les IP donc pas de NAT 1:1 mais je prévois ça pour plus tard.

Voici le petit script iptables

iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport port -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -t nat -A POSTROUTING -m iprange --src-range 10.8.0.1-10.8.0.75 -j SNAT --to-source IP1
iptables -t nat -A POSTROUTING -m iprange --src-range 10.8.0.76-10.8.0.254 -j SNAT --to-source IP2

Et dans pfsense, j'ai crée 2 gateways et interfaces pour les clients.
Ensuite, une règle firewall dans chaque interface LAN pour rediriger de force la passerelle et ça fonctionne!

J'utilise conntrack pour laisser passer les connexions établies uniquement pour la chaîne "FORWARD". Pour l'instant ça fonctionne (c'est le script un peu modifié que j'utilise en prod depuis 1 an) mais si tu as une idée pour l'améliorer, je suis ouvert à toute suggestion

J'ai saisi le fonctionnement de SNAT, ici il me permet de gérer le NAT en sortie vers des IP, qui sont alias de eth0, respectivement eth0:0 et eth0:1. J'ai remarqué que iptables fonctionne par interface, donc si je fais une règle avec eth0, ça inclura toutes les IP de eth0. J'ai vu ça pour les règle d'ouverture de port, si j'autorise par exemple le port 80 sur eht0, je peut voir le site sur toutes mes IP.

Donc pour l'instant je suis obligé de spécifier l'ip de sortie. Pas très propre mais ça fonctionne !
Quand on y pense, l'ipv6 nous débarrassera de toutes ces cochonneries de NAT

Vu que dans cette configuration les premiers paquets passant par le VPN sont forcèment NEW depuis l'intérieur, j'ai pas pris la peine de l'indiquer. Mais c'est en entrée, depuis le côté public qu'il faut laisser passer que les paquets marqués ESTABLISHED, le minimum syndical de sécurité l'oblige. Dans le pire des cas j'ai toujours le routeur qui fait office de client VPN, il rajoute une couche de sécurité.

Si je me trompe pas, dans le cas du 1:1 , comme tout passera, je ne pense plus avoir besoin de gérer l'aspect stateful sur iptables, ça devient un pseudo-bridge en quelque sorte et c'est mon routeur à la maison qui fera le tri.

Mais pour du 1:1, on est bien sur une combinaison de SNAT et DNAT ?

J'avais une question à ce propos, si on "redirige" tous les ports d'une IP publique en 1:1, que se passe t-il quant aux règles iptables qui s'appliquent sur la même interface parent ? Il y a une priorité selon l'emplacement de la règle?

depuis le côté public qu'il faut laisser passer que les paquets marqués ESTABLISHED, le minimum syndical de sécurité l'oblige.

Pour moi la sécurité vient du fait de ne pas avoir de serveurs non désirés sur un PC (on contrôle ce qui est installé et qui fonctionne sur le serveur), et que les serveurs qui n'ont pas vocation à être accessible depuis l'extérieur ne doivent pas avoir d'adresses Internet.

Un contrôle d'accès par filtrage sur l'adresse IP source fait avant toute autre opération est simple et robuste.