Skip to content

Split-tunnel VPN: my provider thinks I'm in five countries simultaneously

VPS Hosting by carlos2 3 replies 256 views
#1

So I set up split-tunnel routing on my Contabo VPS. Traffic to my bank goes through OVHcloud NL, crypto exchanges through Vultr SG, streaming through Hetzner US, work through InterServer DE, and personal stuff direct. Smart right?

Except now my bank froze everything. Fraud alert: "impossible travel." Same with my exchange. They see logins from 5 countries in 10 minutes.

I thought about just routing everything through one exit but that's not the point. Which providers take XMR for extra IPs so I can at least keep the same country per service? Need like 5 more IPv4s minimum.

Also if anyone knows a bank that doesn't panic at BGP-level multihoming, I'm listening.

not your keys, not your coins
#2

52 boxes across 14 providers and never had this problem

But I dont do split tunnel on anything that touches money lol. Learned that the hard way with a paypal lock in 2019.

Your real problem is $/IP. Lets math:

  • Contabo: €2/IP/month, /29 minimum
  • OVHcloud: €1.50/IP but setup fee
  • Vultr: $3/IP, no contract
  • Hetzner: bundled only, bad deal
  • InterServer: $1/IP if you beg support

So youre looking at maybe $8-10/month for clean IPv4s. Or just use one provider with multiple regions? Same ASN though, fraud detection might still catch it.

seedbox, NAS, tape, and three offsite
#3
carlos2 said:
Same country per service

(this is the part that gets you) (fraud detection doesn't care about your clever routing) (they just see velocity and geography mismatch) (the banks have rules written by people who don't know what BGP is) (nested problem: you can't explain BGP to a tier-1 support agent) (never resolves)

(just use one VPN for financial stuff) (boring but works) (sorry)

#4
hankels said:
Same ASN though, fraud detection might still catch it

Incorrect. ASN-based correlation is not standard in consumer fraud detection. The systems triggering here are IP geolocation velocity checks and device fingerprinting cross-referenced with advertised IP allocation boundaries.

What you are experiencing is a fundamental mismatch between your routing policy and the RIR allocation transparency of your tunnels. If OVHcloud NL advertises its PA space with proper SWIP, your bank sees a datacenter IP in Amsterdam. If your direct connection reveals a residential ISP in another RIR region, the velocity algorithm flags impossible travel.

Proper solution: establish consistent source addressing per destination class. Use policy-based routing with source NAT, not split tunneling with disparate exits. Maintain a single exit for financial destinations, ideally one with clean IP reputation and working rDNS.

RPKI and IRR are irrelevant here but I mention them because your providers should at least have ROAs for the space they assign you. Check with whois — https://bgp.tools works fine for a quick look.

iBGP, eBGP, don't care, just peer

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft