Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


How to use VPN *client* on a VPS
New on LowEndTalk? Please Register and read our Community Rules.

How to use VPN *client* on a VPS

farsighterfarsighter Member
edited August 1 in Providers

and still have all incoming connections (not only SSH) to VPS public IP working?

I know how to make it work with OpenVPN client (by configuring proper IP routes) but unfortunately that solution doesn't work when using VPN provider's own binaries to establish a connection. Whenever I start such a VPN program (Keepsolid for example) on remote desktop it apparently rewrites IP rules and I'm always locked out, no matter what IP rules I set before.

I'm wondering if there's a solution to make it work in such situations, the same way it works with OpenVPN.

Thanked by 1Logano

Comments

  • If the provider provides OpenVPN config files/WireGuard config files, which I'm pretty sure almost all do, you should be able to work with those. (Even if they don't provide them officially there might be third party methods to get them)

  • farsighterfarsighter Member
    edited August 1

    @MallocVoidstar said:
    If the provider provides OpenVPN config files/WireGuard config files, which I'm pretty sure almost all do, you should be able to work with those. (Even if they don't provide them officially there might be third party methods to get them)

    They do but I need to switch IP quickly using their interface.

  • KousakaKousaka Member
    edited August 1

    Say your public ip is 192.168.1.42/24, gateway is 192.168.1.1 and interface is ens3:
    '''
    ip rule add from 192.168.1.42 table 128
    ip route add table 128 to 192.168.1.42/24 dev ens3
    ip route add table 128 default via 192.168.1.1
    '''

    Table number can be changed, you can also add "-6" and replace corresponding parameters to make it work for ipv6.

  • ralfralf Member

    If there are only a few known services on the public IP, you could add iptables rules to check for the source being your IP and the known port, and force that to route over the required external interface instead of the wireguard interface.

    Another option would be to have a container or nested VM that owns the wireguard connection and run the things you want going through the VPN in there and the rest of the system would use the public IP.

    Thanked by 1farsighter
  • @Kousaka said:
    Say your public ip is 192.168.1.42/24, gateway is 192.168.1.1 and interface is ens3:
    '''
    ip rule add from 192.168.1.42 table 128
    ip route add table 128 to 192.168.1.42/24 dev ens3
    ip route add table 128 default via 192.168.1.1
    '''

    Table number can be changed, you can also add "-6" and replace corresponding parameters to make it work for ipv6.

    Yes that's how it works with OpenVPN, but as explained it didn't work with GUI binaries supplied by VPN providers.

  • ralfralf Member

    The reason for my comment is that as soon as you bring up the wireguard interface, all the replies from your server to connections to its public IP will then be routed over the wireguard, and then masqueraded by the VPN. So when they finally arrive, the other end won't know they are the same connection and will just drop them. That's why you need to explicitly make sure they're routed normally and not through the wireguard interface.

  • KousakaKousaka Member

    @farsighter said:

    @Kousaka said:
    Say your public ip is 192.168.1.42/24, gateway is 192.168.1.1 and interface is ens3:
    '''
    ip rule add from 192.168.1.42 table 128
    ip route add table 128 to 192.168.1.42/24 dev ens3
    ip route add table 128 default via 192.168.1.1
    '''

    Table number can be changed, you can also add "-6" and replace corresponding parameters to make it work for ipv6.

    Yes that's how it works with OpenVPN, but as explained it didn't work with GUI binaries supplied by VPN providers.

    Maybe run these lines when the server boots? These shouldn't be affected by VPN connect/disconnect events.

  • @ralf said:
    If there are only a few known services on the public IP, you could add iptables rules to check for the source being your IP and the known port, and force that to route over the required external interface instead of the wireguard interface.

    Going to try that out thank you. Basically I need port 80, port 22 and various other ports for keeping NX remote desktop accessible. Any quick example for such iptables rule for a range of ports?

  • sotssots Member

    One kind of VPNs redirect all the outbound traffic to the VPN server (e.g. wireguard or openvpn). You need to set iptables and iproutes manually if you want to use it on your vps. Do NOT enable the proxy without extra configurations if you're connecting via SSH or RDP because your connection may be interrupted and you won't be able to connect to it again unless you disable the VPN.
    Another kind of VPNs just starts a HTTP or socks proxy on your machine (e.g. v2ray or shadowsocks). I would recommend you to use them because they're more flexible and easier to use.

  • sotssots Member
    edited August 1

    I would not recommend you to use GUI programs from the VPN providers on your server because they may modify your firewall or routing configurations. Also, starting an X Server on your server is waste of compute power. If your VPN provider gives you GUI clients only, please ask for refund and choose a provider that offers regular VPN software (ikev2/wg/ovpn/...) configurations.

    Thanked by 2yoursunny MannDude
  • ralfralf Member

    @farsighter said:

    @ralf said:
    If there are only a few known services on the public IP, you could add iptables rules to check for the source being your IP and the known port, and force that to route over the required external interface instead of the wireguard interface.

    Going to try that out thank you. Basically I need port 80, port 22 and various other ports for keeping NX remote desktop accessible. Any quick example for such iptables rule for a range of ports?

    From the top of my head:

    iptables -I POSTROUTING -p tcp -s your.ip.address.here -sport 22 -o eth0 -j ACCEPT
    iptables -I POSTROUTING -p tcp -s your.ip.address.here -sport 80 -o eth0 -j ACCEPT
    iptables -I POSTROUTING -p tcp -s your.ip.address.here -sport 443 -o eth0 -j ACCEPT
    

    etc. But I can't easily check right now, so I've probably missed something out. Obviously replace your.ip.address.here and eth0 as required. Also the first parameter is capital i not L or 1.

  • Thank you @ralf it's working now. That was the right direction :)

    Thanked by 1ralf
  • ralfralf Member

    PS if the IP address in that picture is your public IP, you probably want to pull the picture quick!

  • farsighterfarsighter Member
    edited August 1

    @ralf said:
    PS if the IP address in that picture is your public IP, you probably want to pull the picture quick!

    No that's one of Keepsolid VPN IPs lol

  • the problem of course is when your public IP changes and you're locked out of the vps. :)

  • ralfralf Member
    edited August 1

    @mosquitoguy said:
    the problem of course is when your public IP changes and you're locked out of the vps. :)

    That's a good point actually. Arguably you don't need the -s in there, at least for ssh, because the only ssh connections are going to be for the public IP (of course, this would also make outgoing ssh connections, if you make any, use the public IP not the VPN, but that's probably OK I'd guess).

  • Read the wireguard tutorial?

  • I can see your problem is sorted but I thought I'd add my two cents. If you're comfortable with CLI &/or Docker you can use a container to route other containers networking exclusively through a VPN using .opvn or .wg config files while leave all other aspects of the VPS networking untouched. https://github.com/wfg/docker-openvpn-client

  • LoganoLogano Member

    Someone should make a Udemy course for this with step by step instructions for noobs. I'd pay $10. Just make the title really advanced-sounding so that my certificate makes me look smarter than I really am. B)

  • boralesborales Member

    When I tried something like this a few years ago I broke my server and had to reinstall everything. This thread tempts me give it another try...

  • @borales said:
    When I tried something like this a few years ago I broke my server and had to reinstall everything. This thread tempts me give it another try...

    Feel free to reach out if you need a hand with any of this, I've set it up a few times before in a few different ways.

    Thanked by 1borales
  • emgemg Member

    @mosquitoguy said:
    the problem of course is when your public IP changes and you're locked out of the vps. :)

    You can create iptables rules to work with dynamic IP addresses. I use FreeDNS (afraid.org) with my firewall/router to give a fixed name to whatever IP address was provided by the ISP.

    In your case, if your source IP address changes, you may have to use the control panel to reboot your VPS so that it picks up the change. Depending on how rare IP changes are, it could be a great solution or it could be ugly if you must reboot the VPS frequently. If you are literally connecting from temporary sites like coffee shops or while traveling, that could be ugly.

    Related note:
    I have learned that it is very difficult to get my ISP to change the dynamic public IP address assigned to our internet connection. It will stay the same for a year or more if I don't make a change. My current hypothesis is that the IP address stability is deliberate, to make tracking easier for everyone who makes money from tracking. They treat your IP address as an identifier, like a phone number.
    -> What I figured out is that if I change the MAC address of the WAN Ethernet port on my firewall/router and reboot the hardware (firewall and modem), I get a different IP address from the ISP. (Yes, if I change it back, I get the old IP address back.) It is true that if you leave your equipment off long enough, you can force a change, but the ISP is patient about it. 24 hours is not always enough, but my ISP does not reserve an IP address forever. To fulfill my curiosity, I pinged previously assigned IP addresses and they sometimes responded.

  • @emg said:
    You can create iptables rules to work with dynamic IP addresses. I use FreeDNS (afraid.org) with my firewall/router to give a fixed name to whatever IP address was provided by the ISP.

    although you can use hostnames/fqdn as arguments with iptables, it only tracks the IP that's valid at the time of creation-- it doesn't do reverse or forward lookups on each packet. To do what you described, you have to create a cron job that checks the rules periodically and update them whenever the IP changes for that hostname.

  • ralfralf Member

    @emg said:
    Related note:
    I have learned that it is very difficult to get my ISP to change the dynamic public IP address assigned to our internet connection. It will stay the same for a year or more if I don't make a change. My current hypothesis is that the IP address stability is deliberate, to make tracking easier for everyone who makes money from tracking. They treat your IP address as an identifier, like a phone number.

    I actually doubt it's deliberate or even intentional. The simple reality is that most people keep their routers on 24-7, so once someone is allocated the next free IP, they will tend to keep it as when their DHCP lease is close to expiry, they'll renew it and just get the same address again.

    Even if you keep your router unplugged for a long time (my longest was 6 weeks when I went on a long holiday), if nobody else has done the same, yours is probably still just the next free IP.

    Conversely, with my new ISP, it seemed all of the PPPoE access points were overloaded, and when I first got it, for the first two weeks my longest time connected was 10 hours and then I'd get kicked off the server, and connect to a different one and get a new public IP. However, after then it settled down, and now I've had the same IP for the last two weeks.

    -> What I figured out is that if I change the MAC address of the WAN Ethernet port on my firewall/router and reboot the hardware (firewall and modem), I get a different IP address from the ISP. (Yes, if I change it back, I get the old IP address back.)

    This also would just tie in with it just being whenever the DHCP lease expired.

  • sotssots Member
    edited August 2

    [deleted]

  • sotssots Member

    @emg said: I have learned that it is very difficult to get my ISP to change the dynamic public IP address assigned to our internet connection. It will stay the same for a year or more if I don't make a change.

    Which provider did you choose? I have no public IPs. Seems that people here in a district use nat to share a /16 public IP pool. Is it better for privacy?

  • ralfralf Member
    edited August 2

    I interpreted "public IP" to mean the IP that's assigned to your router that's accessible from the rest of the internet. I only know of one ISP in the UK (Zen) that still offers a static IP rather than a dynamic one from a pool, but that usually remains constant for months at a time (as described above).

    But doing NAT from a huge pool seems a bit strange. Are you sure it's not just an IP per customer and the router doing the NAT?

  • emgemg Member
    edited August 2

    @sots said:

    Which provider did you choose? I have no public IPs. Seems that people here in a district use nat to share a /16 public IP pool. Is it better for privacy?

    Our cable provider is Spectrum Internet, which merged with Charter Communications, who bought Time Warner Cable, who bought RoadRunner. We get 1 public IPv4 address to share behind our own NAT. They also provide a /64 pool of IPv6 addresses.

    We are fortunate to live in a rare area that supports two competing high speed internet providers. AT&T fiber is also available in our area. I do not like their offering as well, but I like that the competition has lowered internet costs for everyone.

    "Privacy" means different things to different people. In terms of what you are asking, I do not see any privacy advantages to your /16 NAT. It may mean that you are slightly less vulnerable to hackers that randomly scan the internet, but that is not saying much about security, and I do not see it "privacy" per se. Let's see what others post about "privacy."

  • @ralf said:

    @emg said:
    Related note:
    I have learned that it is very difficult to get my ISP to change the dynamic public IP address assigned to our internet connection. It will stay the same for a year or more if I don't make a change. My current hypothesis is that the IP address stability is deliberate, to make tracking easier for everyone who makes money from tracking. They treat your IP address as an identifier, like a phone number.

    I actually doubt it's deliberate or even intentional.

    It very much is. There's legal reasons to have IPs matched to customers addresses and technical reasons to reserve DHCP addresses for planning and network design reasons. IPV4 planning is a pain for residential areas with growth and density.

    For more than a decade, the local ISP's would get the first (up to 5, but typically 2) MAC address seen by the router and reserve that. Replace PC's with new MAC addresses and the DSL ISP had a login portal to view and delete old MACs. The cable ISP just required a power cycle to get new MAC learned.

Sign In or Register to comment.