I want to set up a VPN that uses the client’s IP when sending data out of the VPN server. I am able to use either OpenVPN (open-source edition), or Wireguard.
Not necessarily. VPN can be used for that, but I’d be that more common use case is to access networks which are otherwise firewalled off from the public internet, like corporate LAN.
I do wonder about when VPNs started being used as proxies… Back when I was in school, we’d use HTTP proxies for HTTP, and SOCKS5 proxies for everything else. I remember I’d try searching for free web-based proxies too.
I guess VPNs being easier to configure and automatically applying to all apps (since they’re just networks that can have routing rules) helped.
I do wonder about when VPNs started being used as proxies…
About at the same time operators at the US noticed that they could profit from profiling users behaviour. In here that’s very much illegal thing to do and most use cases for VPN is to connect yourself into corporate network. VPNs are of course useful to protect you from MITM attacks at open wifi networks and things like that, but hiding your behavior from your ISP is very much an US thing.
While I think you could techincally spoof your originating IP at the VPN server to match your clients IP it wouldn’t do anything useful. That’s not how IP routing works. What you’re trying to achieve with a setup like that?
I don’t think this will actually work. If data looks like it’s coming from the client IP, the return packets will take the wrong route and go directly to the client instead of via the proxy/VPN.
That’s not possible. There’s only one route to an IP. Those may lead to different machines depending on where the request originates, and you more or less can’t choose which one, your ISP and their upstream ISPs decide and it’s usually the shortest or cheapest route. The Internet is stateless, it just moves packets around. Each step makes an independent decision as to where to send it next.
So your VPN server can try spoofing its outbound traffic to use the client’s IP, but it’ll most likely get discarded by the ISP because it only allows your IP to go out. But even if you can, the answer to those packets will go to the client’s IP, which will go directly to the client and not the VPN. The other end doesn’t know where it originated from, it just has a number, and it sends it back into the Internet and the Internet figures it out.
And if you can properly port the IP to your server, then the client can no longer use that IP because anything directed at it will end up at the server.
It’s theoretically possible to pull off with some clever iptables rules but both ends need to be configured for it so it’ll never leave your private network. In which case, it’s just not worth the hassle to avoid making a new subnet.
That’s not true. There’s an infinite numer of ways to route IP addresses on the internet in fact. Most of them are useless however.
your VPN server can try spoofing its outbound traffic to use the client’s IP, but it’ll most likely get discarded by the ISP because it only allows your IP to go out. But even if you can, the answer to those packets will go to the client’s IP, which will go directly to the client and not the VPN.
Mission accomplished? This may be what OP wants? Really not sure.
That’s not true. There’s an infinite numer of ways to route IP addresses on the internet
I think what they were trying to say is that packets are usually routed one particular way, which is true (routes normally don’t suddenly change unless there’s a major change like an outage or cost change). This part of their comment makes me think they do understand that there’s many possible routes:
you more or less can’t choose which one, your ISP and their upstream ISPs decide and it’s usually the shortest or cheapest route.
Yeah, I almost talked about anycast IPs but it just added unnecessary complexity.
OP’s question is a bit weird but it sounds like they want to connect to a VPN server and then that server uses the client’s IP instead of its own for outbound traffic, like some sort of forwarding?
For all I know OP may be asking for a bridged VPN and it really just means to forward the remote client as if it’s on the local network.
But the way it’s worded, the same IP would be used to both talk to the server and by the server itself going outbound. It’s possible on a local network with iptables hacks but why would you even want to do this?
This feels like a XY problem. To be able to provide a useful answer to you, we’d need to know what exactly you’re trying to achieve. What goal are you trying to achieve with the VPN and what goal are you trying to achieve by using the client IP?
In most cases the whole point of the VPN is to not disclose the clients IP.
Are you talking about a site 2 site VPN? Then this would make sense. In that case you choose an IP range for the VPN endpoints and add routes to the networks in both ends over it. Then the clients will use their own IPs to connect and you should see them on the other side as source.
Make sure to have no IP range overlaps.
I can give you a simple example later if you want.
This can’t feasibly be done over the internet. An IP address must be unique as that’s how it finds it out of billions of other devices. There are situations where the same IP can route to different locations but that’s regional and way beyond what you’re trying to achieve here. It’s how something like 8.8.8.8 works without sending all the requests to a single location.
If your server is sending out traffic as 1.2.3.4 and then tries to send the encrypted traffic to the client at 1.2.3.4 the traffic would either be routed back to itself or the client would receive the plaintext traffic meant for the server.
Generally, yea, this isn’t how a client-server VPN works.
If you’re interconnecting two subnets that are part of the same network (say a remote site that uses a subnet of corporate address space) with a site-to-site vpn, then it can make sense. But then the VPN is usually transparent to the devices.
A client using VPN to connect to a VPN server as an entry point would need some kind of subnetting functionality to achieve this, something like what Tailscale does with Subnet Routing. But that would be reproducing the site-to-site, and you’d need to make sure IP addressing is peoperly configured (the remote site needs to be part of the same address space with no conflicts).
If you control both ends, this is possible with proper DHCP scoping/reservations, or just static addresses.
But without really understanding OP’s intent, it’s hard to say.
Yeah, not sure how many isps block it. They didn’t used to 10 years or so ago. I used to block unknown ips at my egress.
But they should, and I’m hoping they do now.
I’m also not too sure what the point would be for the OP. Even if their isp allows the ip spoofing the response would take the normal route back to the vpn client.
Going to summarize a lot of comments here with one - VPNs are very powerful tools that can do lots of things. Traffic can be configured to go in several directions. We really have to know more about your use case to advise you as to what config you might need.
Going to just write a ton of words on paper here - OP, let me know if any of this sounds like what you’re trying to do, and I can try to give a better explanation (or if something was confusing, let me know).
VPN that uses the client’s IP when sending data out of the VPN server
That’s the specific sentence I’m getting caught on myself. It could mean several things, some of which have been mentioned, some haven’t.
Site to site VPN: Two (generally) fixed devices operate a VPN connection between them and utilize some form of non-NAT routing so that every child device behind each site sees it’s “real” counterpart without getting NATed. However, NAT is typically still configured for IPv4 facing the internet, so each device shows an internet “exit IP” matching the site it’s on. Typically, the device with the most powerful / most stable / most central / least restrictive would be the receiver, while the other nodes would be initiators pointed to that receiver. In larger maps, you could build multiple hub/spoke systems as needed.
Sub-type of site to site possible: where one site tunnels all of its data over to the second site, and the second site is the one that provides NAT. This is similar in nature to how GL.Inet routers operate their VPN switch, but IMHO more powerful of you have greater control over the server compared to subscribing to a public VPN service. Notably for you example, the internet NAT exit device can be either the initiator or the receiver.
Normal VPN but without NAT: this is another possible expansion of what you’ve written, with one word adjusted - it operates the VPN but preserves the client IP as it’s entering the network. This is how most corporate remote access VPNs operate, since it would be overloaded and pointless to have every remote worker from a small pool of IP addresses when you don’t even need to use a NAT engine for intranet.
My remote access VPN for my home lab is of the latter type, and I have a few of the sites to site connections floating around with various protocols.
For mine, I have two VPN servers: one internal server that works tightly with my home firewall, and one remote server running inside a VPS. Both the firewall and VPS apply NAT rules to egress traffic, but internal bound traffic is not NATed and simply passed along the site to site connections to wherever it needs to go. My home-side remote access VPN is simply a “dumb” VPN server that has the VPN protocol port forwarded back to it and passes almost raw traffic to the firewall for processing.
For routing, since each VPN requires its own subnet, I use FRR with a mixture of OSPF and iBGP (depending on how old the link is)
For VPN protocols, I currently am using strongSwan for IPsec, but it’s really easy to slap OpenVPN onto that routing stack I already set up and have the routes propagate inward.
I think that it’s similar to the “Normal VPN without NAT”, but I want it to preserve the client IP all the way through to the server that the client wants to connect to (in other words, the website that the client wants to access will receive the IP of the client, not the VPN server).
So there’s three problems you are very likely to encounter.
Most providers now almost certainly filter their egress for netblocks under their control to prevent ip spoofing. So it’s likely the packets would never make it out at all.
2: if it does work the return path would be over the normal Internet route and not via the vpn. Only the sent packets would go via the vpn host.
3: if the client is behind nat the router will not recognise the response packets as belonging to an open connection and will drop them.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
deleted by creator
Not necessarily. VPN can be used for that, but I’d be that more common use case is to access networks which are otherwise firewalled off from the public internet, like corporate LAN.
Right. That’s literally why it’s called a VPN - you’re connecting to a private network (LAN), virtually.
deleted by creator
Its also a vital part of software defined networking
Not at all. A VPN can be used as a proxy but that’s not what they were intended for.
I do wonder about when VPNs started being used as proxies… Back when I was in school, we’d use HTTP proxies for HTTP, and SOCKS5 proxies for everything else. I remember I’d try searching for free web-based proxies too.
I guess VPNs being easier to configure and automatically applying to all apps (since they’re just networks that can have routing rules) helped.
About at the same time operators at the US noticed that they could profit from profiling users behaviour. In here that’s very much illegal thing to do and most use cases for VPN is to connect yourself into corporate network. VPNs are of course useful to protect you from MITM attacks at open wifi networks and things like that, but hiding your behavior from your ISP is very much an US thing.
The hiding of internet traffic is also a proxy thing, not necessarily a VPN thing.
This is doable with a SOCKS5 or HTTP proxy though. I’m wondering about VPNs specifically.
Uh? Is this a thing? And, if it is, what’s the use case? Just curious…
deleted by creator
While I think you could techincally spoof your originating IP at the VPN server to match your clients IP it wouldn’t do anything useful. That’s not how IP routing works. What you’re trying to achieve with a setup like that?
It can be achieved with nat proxy on the server https://serverfault.com/questions/379360/vpn-tunneling-to-hide-real-ip-through-my-proxy-server-while-showing-the-clien
I don’t think this will actually work. If data looks like it’s coming from the client IP, the return packets will take the wrong route and go directly to the client instead of via the proxy/VPN.
That’s not possible. There’s only one route to an IP. Those may lead to different machines depending on where the request originates, and you more or less can’t choose which one, your ISP and their upstream ISPs decide and it’s usually the shortest or cheapest route. The Internet is stateless, it just moves packets around. Each step makes an independent decision as to where to send it next.
So your VPN server can try spoofing its outbound traffic to use the client’s IP, but it’ll most likely get discarded by the ISP because it only allows your IP to go out. But even if you can, the answer to those packets will go to the client’s IP, which will go directly to the client and not the VPN. The other end doesn’t know where it originated from, it just has a number, and it sends it back into the Internet and the Internet figures it out.
And if you can properly port the IP to your server, then the client can no longer use that IP because anything directed at it will end up at the server.
It’s theoretically possible to pull off with some clever iptables rules but both ends need to be configured for it so it’ll never leave your private network. In which case, it’s just not worth the hassle to avoid making a new subnet.
That’s not true. There’s an infinite numer of ways to route IP addresses on the internet in fact. Most of them are useless however.
Mission accomplished? This may be what OP wants? Really not sure.
I think what they were trying to say is that packets are usually routed one particular way, which is true (routes normally don’t suddenly change unless there’s a major change like an outage or cost change). This part of their comment makes me think they do understand that there’s many possible routes:
Yeah, I almost talked about anycast IPs but it just added unnecessary complexity.
OP’s question is a bit weird but it sounds like they want to connect to a VPN server and then that server uses the client’s IP instead of its own for outbound traffic, like some sort of forwarding?
For all I know OP may be asking for a bridged VPN and it really just means to forward the remote client as if it’s on the local network.
But the way it’s worded, the same IP would be used to both talk to the server and by the server itself going outbound. It’s possible on a local network with iptables hacks but why would you even want to do this?
This feels like a XY problem. To be able to provide a useful answer to you, we’d need to know what exactly you’re trying to achieve. What goal are you trying to achieve with the VPN and what goal are you trying to achieve by using the client IP?
Thanks for the XY link… I’ve seen this occur loads of times, but that sums it up succinctly. Thanks
In most cases the whole point of the VPN is to not disclose the clients IP. Are you talking about a site 2 site VPN? Then this would make sense. In that case you choose an IP range for the VPN endpoints and add routes to the networks in both ends over it. Then the clients will use their own IPs to connect and you should see them on the other side as source. Make sure to have no IP range overlaps.
I can give you a simple example later if you want.
deleted by creator
This can’t feasibly be done over the internet. An IP address must be unique as that’s how it finds it out of billions of other devices. There are situations where the same IP can route to different locations but that’s regional and way beyond what you’re trying to achieve here. It’s how something like 8.8.8.8 works without sending all the requests to a single location.
If your server is sending out traffic as 1.2.3.4 and then tries to send the encrypted traffic to the client at 1.2.3.4 the traffic would either be routed back to itself or the client would receive the plaintext traffic meant for the server.
Depends.
Generally, yea, this isn’t how a client-server VPN works.
If you’re interconnecting two subnets that are part of the same network (say a remote site that uses a subnet of corporate address space) with a site-to-site vpn, then it can make sense. But then the VPN is usually transparent to the devices.
A client using VPN to connect to a VPN server as an entry point would need some kind of subnetting functionality to achieve this, something like what Tailscale does with Subnet Routing. But that would be reproducing the site-to-site, and you’d need to make sure IP addressing is peoperly configured (the remote site needs to be part of the same address space with no conflicts).
If you control both ends, this is possible with proper DHCP scoping/reservations, or just static addresses.
But without really understanding OP’s intent, it’s hard to say.
IP spoofing on the internet won’t get you very far. So, no, this won’t work. I don’t even see a scenario where this would make sense.
Yeah, not sure how many isps block it. They didn’t used to 10 years or so ago. I used to block unknown ips at my egress.
But they should, and I’m hoping they do now.
I’m also not too sure what the point would be for the OP. Even if their isp allows the ip spoofing the response would take the normal route back to the vpn client.
I have no numbers, but with the rise in bad actors I assume that at least the larger hosts who have their own data centers do it.
Going to summarize a lot of comments here with one - VPNs are very powerful tools that can do lots of things. Traffic can be configured to go in several directions. We really have to know more about your use case to advise you as to what config you might need.
Going to just write a ton of words on paper here - OP, let me know if any of this sounds like what you’re trying to do, and I can try to give a better explanation (or if something was confusing, let me know).
That’s the specific sentence I’m getting caught on myself. It could mean several things, some of which have been mentioned, some haven’t.
Site to site VPN: Two (generally) fixed devices operate a VPN connection between them and utilize some form of non-NAT routing so that every child device behind each site sees it’s “real” counterpart without getting NATed. However, NAT is typically still configured for IPv4 facing the internet, so each device shows an internet “exit IP” matching the site it’s on. Typically, the device with the most powerful / most stable / most central / least restrictive would be the receiver, while the other nodes would be initiators pointed to that receiver. In larger maps, you could build multiple hub/spoke systems as needed.
Sub-type of site to site possible: where one site tunnels all of its data over to the second site, and the second site is the one that provides NAT. This is similar in nature to how GL.Inet routers operate their VPN switch, but IMHO more powerful of you have greater control over the server compared to subscribing to a public VPN service. Notably for you example, the internet NAT exit device can be either the initiator or the receiver.
Normal VPN but without NAT: this is another possible expansion of what you’ve written, with one word adjusted - it operates the VPN but preserves the client IP as it’s entering the network. This is how most corporate remote access VPNs operate, since it would be overloaded and pointless to have every remote worker from a small pool of IP addresses when you don’t even need to use a NAT engine for intranet.
My remote access VPN for my home lab is of the latter type, and I have a few of the sites to site connections floating around with various protocols.
For mine, I have two VPN servers: one internal server that works tightly with my home firewall, and one remote server running inside a VPS. Both the firewall and VPS apply NAT rules to egress traffic, but internal bound traffic is not NATed and simply passed along the site to site connections to wherever it needs to go. My home-side remote access VPN is simply a “dumb” VPN server that has the VPN protocol port forwarded back to it and passes almost raw traffic to the firewall for processing.
For routing, since each VPN requires its own subnet, I use FRR with a mixture of OSPF and iBGP (depending on how old the link is)
For VPN protocols, I currently am using strongSwan for IPsec, but it’s really easy to slap OpenVPN onto that routing stack I already set up and have the routes propagate inward.
I think that it’s similar to the “Normal VPN without NAT”, but I want it to preserve the client IP all the way through to the server that the client wants to connect to (in other words, the website that the client wants to access will receive the IP of the client, not the VPN server).
Where is the server located? Are you looking at an intranet location or internet?
Is the client connected to the VPN concentrator via IPv4 or IPv6?
Is the VPN concentrator connected to the server via IPv4 or IPv6?
What you ask may be possible depending on those answers.
So there’s three problems you are very likely to encounter.
2: if it does work the return path would be over the normal Internet route and not via the vpn. Only the sent packets would go via the vpn host.
3: if the client is behind nat the router will not recognise the response packets as belonging to an open connection and will drop them.
I’m really not sure what your intention is.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
5 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #364 for this sub, first seen 19th Dec 2023, 09:15] [FAQ] [Full list] [Contact] [Source code]