Multihoming / dual public IP with VPN

Don't forget to add a nice name to /etc/iproute2/rt_tables:

echo -e "100\tvpn" >> /etc/iproute2/rt_tables

Configure policy routing on the router for the VPN connection device tun0:

ip route add default via 192.168.67.1 dev tun0
ip rule add from 192.168.66.55 table vpn
ip route flush cache # doesn't hurt

I only run a few hosts within my networks so a machine that normally has an address of 192.168.66.5 will end up having an additional IP of 192.168.6.55. This way, I can see at a glance what traffic (from/to which host) I am dealing with. This additional address obviously needs to be explicitly configured on the target host:

ip addr add 192.168.66.55/24 dev eth0

There is normally no trafic originating from 192.168.66.55 so setting additional routing for it is not necessary.

Add your favourite DNAT rules on the router behing the VPN:

for tcp in 80 443; do
        iptables -t nat -A PREROUTING -d $VPNWANIP \
        -p tcp --dport $tcp -j DNAT --to 192.168.66.55
done

Corresponding with the rules already present on your local router:

for tcp in 80 443; do
        iptables -t nat -A PREROUTING -d $WANIP \
        -p tcp --dport $tcp -j DNAT --to 192.168.66.5
done

Assuming other routing rules and NAT on both the router and VPN server are set up accordingly, the services on host 192.168.66.5/55 should be accessible through both $WANIP and $VPNWANIP public IPs.

I can't access my services aka own traffic through same PUBLIC IP problem

Normally, you can't access the 192.168.66.55 host through $VPNWANIP address from inside a network that gets NATed behind $WANIP. This is because traffic returning from 192.168.66.55 to $WANIP supposedly through the VPN connection has a destination IP same as the router and ends up treated as local traffic.

The local rule (the one that actually decides what gets consumed by the local IP stack and doesn't go anywhere further) is normally the rule number 0. You can't have a rule with negative preference (higher priority than 0) to outrun this but the local rule can be moved/de-prioritized:

ip rule add preference 1000 lookup local
ip rule delete preference 0

(command precedence is important shall you be doing this remotely)

And now our custom rule can have a higher priority than the local rule (smaller preference number):

ip rule del from 192.168.66.55 table vpn
ip rule add prefercence 999 from 192.168.66.55 table vpn

The returning traffic for our own public IP address initially targetting the VPN connection can be returned to the other end, it is no longer treated as designated for the router itself - the default via included in the vpn table takes precedence.

Simple, effective, no additional iptables SNAT magic involved!