So, I'm experimenting with running a Mailu instance on my home server but proxying all of the relevant traffic through a WireGuard tunnel to my VPS. I'm currently using NGINX Proxy Manager streams to redirect the traffic and it all seems to be working.
The only problem is that, all connections appear to come from the VPS. It's really screwing with the spam filter. I'm trying to figure out if there's a way to retain the source IP while still tunneling the traffic.
The only idea I have, and I don't know if it's a bad one, is to us iptables to NAT the ports inbound on the VPS and on my home router (opnsense) route all outbound traffic from that IP back through the VPS instead of the default gateway. This way I shouldn't need to rewrite the destination port on the VPS side.
It sound a bit hacky tho, and I'm open to better suggestions.
Thanks
Edit: I think I need to clarify my post as there's some confusion in the comments. I would like the VPS to masquerade/nat for my mailu system accessible over a WG tunnel so that inbound traffic to the SMTP reports it's actual public IP instead of the IP of the VPS host that's currently proxying.
After giving that some thought I think the only way this could work would be if I treated the VPS as the upstream gateway for all traffic. My current setup is below:
[VPS] <-- wg --> [opnsense] <--eth-->[mailu]
I can source route all traffic from mailu to the VPS, via wg, but I don't know how to properly configure iptables to do the masquerading as I'd only want to masquerade that one IP. I'm not concerned about mailu not having internet access when wg is down, and frankly, I think I'd prefer it didn't.
Edit 2: I got the basic masquerading working. Can ping public IPs and traceroute verifies it's taking the correct path.
iptables -A FORWARD -i wg0 -s <mailu-ip> -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s <mailu-ip> -j MASQUERADE
I think I got the port forwarding working.
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 25 -j DNAT --to-destination <mailu-ip>
iptables -A FORWARD -p tcp -d <mailu-ip> --dport 25 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
- tcpdump on the VPS eth0 shows traffic in.
- tcpdump on the VPS wg0 shows the natted traffic.
- tcpdump on mailu shows both inbound and outbound traffic.
- tcpdump on opnsense shows 2 way traffic on the vlan interface mailu is on.
- tcpdump on opnsense only shows inbound, but not outbound traffic on the wg interface.
I think the problem is now in opnsense but I'm trying to suss out why. If I initiate traffic on mailu (i.e. a ping or a web request) I see it traversing the opnsense wg interface, but I do not see any of the return SMTP traffic.
Edit 3:
I found the missing packets. They're going out the WAN interface on the router, I do not know why. Traffic I initiate from the mailu box gets routed through the WG tunnel as expected but replies to traffic sourced from the internet and routed over the WG tunnel, are going out the WAN.
The opnsense rule is pretty basic. Source: , Dest: any, gateway: wg.
Edit 4:
I ran out of patience trying to figure out what was going on in opnsense and configured a direct tunnel between the mailu vm and the VPS. That immediately solved my problems although it's not the solution I was striving for.
It was pointed out to me in the comments that my source routing rule likely wasn't configured properly. I'll need to revisit that later. If I was misconfiguring it I'd like to know that.
Not really. Your VPS's public IP is not yours to change, for obvious reasons, and it's unlikely that your hosting provider will let you send packets from your VPS using a source address that is incorrect. if they let you, then any replies to those packets will evidently get routed to the actual IP, ie your home IP. If you really want to forward SMTP to your VPS (which has less chance of being on a Blocklist by virtue of not being a residential IP), I suggest declaring your VPS as your SMTP sender in SPF, instead of declaring your home IP and trying to make that work with the VPS IP. The VPS can then be configured as an SMTP relay (this is a key feature of SMTP) to your home instance, or you could forward all traffic on the appropriate ports at the TCP level, but I don't advise doing this.
I hope you understand that if what you're asking was possible, I could rent a VPS, spoof your IP and receive traffic meant for your IP without any issues. For the same reasons, I think the other commenter mentioning x-forwarded-for headers is wrong if you're not using DKIM (and even then it's iffy). Otherwise I could just write a payload with mailto: whatever, from:you@yourdomain and x-forwarded-for: your home IP and pass SPF checks without having control over your IP.
if you're still confused about SMTP feel free to ask more questions
We have more stuff than SPF checks these days because they're wholely inadequate alone. DNSSEC, DKIM and DMARC are all important in their own right if you want a secure mail server.
That said I also don't agree with your example, because you assume a proxy for outgoing which I see no real need for. Generally speaking you proxy incoming traffic due to CGNAT making port exposure on a residential IP unfeasible. Further SPF checks will always use the actual IP source not what's in a X header.
You need a proxy for outgoing to avoid your source server being on a residential adress, which all but guarantees all mailservers using spamhaus etc will block you by default. DKIM and DMARC are needed in their own right but an SPF fail will already make your mail fall into spam.
Sure, but if you proxy both in and outgoing then your SPF record should of course point to your VPS and thus again not be a problem.
Indeed, but in that case an off-the-shelf SMTP relay works fine.