(untitled)

Hello. I wanted to set up a VPN and have decided to buy a VPS to install Wireguard on it. After some research, I went with the wg-easy tool and installed it successfully. However, I am experiencing an issue where I can't SSH into my VPS or access the wg-easy WebUI (on port 51821) when connected to the VPN. Let's say my VPS has a public IP address of 2.3.3.3 When I'm connected to the VPN, I can't "ssh 2.3.3.3" and I can't access "2.3.3.3:51821" with my browser. Everything works fine when I'm not connected to Wireguard, I can SSH into my VPS and access the wg-easy WebUI without any issues. Thanks.

If the VPS is hosting the VPN you're connected to then I think you can access the services on it on localhost.

>>21834 I can't. I don't think localhost can be changed somehow. it's literally localhost, it will be the same even if you're connected to VPN, as I understand

>>21834 and I want to access services on VPS by it's public ip, like 2.3.3.3:443, not localhost:44 So far I haven't put anything on it except wg-easy, but I would like to in the future. Do you think it would be okay if I put my personal page and Jellyfin on a server with wireguard? Like, would it be safe? All my traffic will go through it, so idk.

>>21835 Well maybe you can change the ip routing to ignore the VPN when accessing 2.3.3.3.

>>21837 I thought about it, but how do I do that?

Bump! Help is still needed.

>>21838 ip route add 2.3.3.3/32 via 192.168.0.1 dev eno1 where 192.168.0.1 and eno1 are your home router ip, and interface where it's plugged in/wifi if applicable. you can set static routes in nmtui if you're using network manager. Doing this, your traffic becomes more finger printable to your ISP >>21833 > Everything works fine when I'm not connected to Wireguard, I can SSH into my VPS and access the wg-easy WebUI without any issues. tracepath 2.2.2.3 and see where it's dropping. Check iptables and see what's going on there. Your traffic will not be NATed out of the default interface on the VPS if you're trying to access, even using the public IP. The source IP on the request will be whatever RFC 1918 address is assigned on the wireguard tunnel. >>21836 > Do you think it would be okay if I put my personal page and Jellyfin on a server with wireguard? Like, would it be safe? All my traffic will go through it, so idk. Well, you become identifiable publicly by hosting a site on the same IP. If you have two IP allocations from a provider, and force WG traffic through one and the rest through another, then maybe

>>21852 so you think I should have one separate VPS for wireguard and everything else on the other VPS?

>>21852 When connected to Wireguard: tracepath 2.3.3.3 1?: [LOCALHOST] pmtu 1420 1: no reply 2: no reply 3: no reply > Your traffic will not be NATed out of the default interface on the VPS if you're trying to access, even using the public IP. The source IP on the request will be whatever RFC 1918 address is assigned on the wireguard tunnel. Ughh, this one I didn't understand at all. what does NAT have to do with VPS, if it has it's own public IP assigned to it? check iptables on my home PC or on the VPS? never used it, btw>>21852

>>21855 Maybe the issue is that your VPS which is hosting the VPN identifies itself as 2.3.3.3 so the route goes to localhost, which then from your machine is your machine when connected to the VPN, perhaps though the VPS has a private network IP to which you can SSH from within the VPN. On the VPS you can check $ ip address $ cat /etc/hosts Or something such

...are you able to access internet through wireguard at all?

>>21859 Yes, I am. Again, when I'm connected to the wireguard of my VPS, I can access Internet from my home pc with VPS's ip but can't connect to my VPS with ssh

>>21862 lol wtf happens there. can you ping 2.3.3.3 when connected to VPN? also look through ip r , ip r l t all , nft list ruleset or if you have iptables i have no idea how to invoke it, i never bothered to even open it's manual.

P.S. I wrote this message the same day you replied, but I couldn't send it, sorry. >>21857 Sorry, I'm not sure what are you talking about. >>21871 I can ping it, yeah. wireguard related line from ip r : 10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.2 /// nft list ruleset : table ip6 wg-quick-wg0 { chain preraw { type filter hook prerouting priority raw; policy accept; } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } table ip wg-quick-wg0 { chain preraw { type filter hook prerouting priority raw; policy accept; iifname != "wg0" ip daddr 10.8.0.2 fib saddr type != local drop } chain premangle { type filter hook prerouting priority mangle; policy accept; meta l4proto udp meta mark set ct mark } chain postmangle { type filter hook postrouting priority mangle; policy accept; meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark } } /// wireguard related lines from ip r l t all : default dev wg0 table 51820 metric 1024 pref medium local 10.8.0.2 dev wg0 table local proto kernel scope host src 10.8.0.2 Do I need to post something else?

>>21932 i'm clueless at this point. might be that your vps providers drops connections to itself. at this point your best bet is to write to their support center and ask wtf's happening. if you couldn't ping, that would be another talk, however. but since you can... you might as well do something trivial like hosting dictd server on your VPS (takes 10 minutes if you read man carefully), bind it to 2.3.3.3 and and check if you can use it. most probably you will not be able to, but if you are, write back i guess PS some hints on dictd: /etc/dictd/dictd.conf: >listen_to 2.3.3.3 >allow * /etc/dictd/dict.conf: >server 2.3.3.3 dict -D

>>21932 Not the one who asked you for this, but I understand what's going on. Would be nice to see your entire routing table (ip route ) Let me try to explain. >>21855 >what does NAT have to do with VPS, if it has it's own public IP assigned to it? Imagine this way -- your Wireguard tunnel establishes a 'LAN' connection between you and your neighbor clients (phone, lappy, desktop, etc) on the 10.8.0.0/24 network. Think of your VPS, as your switch/gateway/router. Your clients plug into it over Wireguard. The wireguard tunnel works like a really long ethernet cable to your VPS' host switch. So because you can have a bunch of 10.8.0.0 addresses on a network with the VPS, and they all need to have internet access, NAT has to happen at the VPS. So, once the Wireguard connection is established, your computer is routing packets like ascii. Notice I'm not mentioning your public IP here. It should not exist as far as the wg0 part of your routing table is concerned. Your default route should be 0.0.0.0/0 via 10.8.0.1 dev wg0 computer (10.8.0.2) -> vps (10.8.0.1) -> nat out from 2.2.2.3(vps-publicip -> lainchan.org You should be able to access services and SSH to the VPS using IP 10.8.0.1 to access the VPS. A side note: It is much better security practice to firewall off SSH, Jellyfin, whatever is a 'personal service', from the public IP and access them only using 10.8.0.1 -- but in the interest of solving your issue, I'll give you some possible things to look for... - As far as the VPS is concerned, your Origin IP when making a request to the public ip (2.2.2.3) will be either the public ip, - OR - the RFC 1918 address (10.8.0.2). It is common practice to filter incoming traffic from bogons/RFC1918 on public IPs by default for a lot of firewalls. Have you tried to SSH into the VPS from the VPS itself? That shouldn't fail, because the packets should never leave the VPS. Depending on how you setup your NAT, traffic can be forced out the public interface only, or it can route directly to the public interface, never leaving the VPS. It's likely the latter. That indicates a firewall issue. The easiest debug step is just to stop the firewall service for a moment to see what happens. >>21854 I didn't mean this, I meant another IP; it's probably cheaper/easier to get another IP from your provider, or even a block.

Many VPS providers are not friendly towards setting up VPNs.

>>21943 wait if he does nat on his vps the public interface will handle requests like (src=2.3.3.3 dst=<ip>), so when SSHing himself it will be (src=2.3.3.3 dst=2.3.3.3) and there should be no problems unless such combination gets dropped on provider's side which i see no reason to do. what do you mean?

>>21947 How this specific situation is handled depends on a number of factors. All remote traffic gets NAT'd, but a number of things can happen when the destination ip is an interface on the same machine. The traffic does not leave the machine, and it's very likely the has nothing to do with the provider. It's perfectly valid, and is probably the case that it looks like <src=10.8.0.2,dst=2.3.3.3> - he either has to strictly route out the nat interface or find why that's not accepted. It's common configuration to reject RFC1918 source addresses to public IPs on a ton of applications. There is nothing stopping you from assigning, say, 8.8.8.8/32 on one of your home computers, and pinging that from another computer on your lan with the static IP 120.1.1.1/32 -- there's nothing magic about the 192,172,or10 local subnets -- they're just allocations. This is why AWS can use the unallocated IP 169.254.169.254 as the IP for their metadata service and everything works fine.

>>21955 >perfectly valid really? afaik rfc1918 traffic is never routed to outside world according to some standard (the rfc1918?). and it's understandable since if <src=10.8.0.2, dst=whatever> how does <whatever> knows where to send responce? 10.8.0.2 is from private address space, so you don't know where it physically is. if such traffic leaves the machine it never returns. i know it from times i was messing with my openVPN setup. i forgot to masquerade traffic after retouting it to public interface and it had rfc1918 source address. it did leave the system, but never returned back. perhaps it never even left my house because my router rejected it, i never bothered to dig further. correct me if i'm wrong

>>21958 It knows because of the routing table, and where it doesn't know because of the routing table, it knows because of the ARP table. Run `arp` and notice the IP to mac mapping also includes the interface. When you run `ip route`, notice most routes have a 'dev' specifier/interface assignment. RFC1918 simply states that traffic from those 3 blocks *should* never be on the internet -- RFC1918 is just a document, it's just instructions. No implementation is perfect. Traffic can also be routed by MAC. You can spoof IPs. At our datacenter, our DDoS scrubber shows a non-0 number for inbound RFC-1918 traffic stats. Weird soykaf happens, sometimes people get compromised, etc. Not every middleman/carrier filters it, and the thing is -- it's up to them. We firewall it, but it can still happen. PFSense has the option to reject RFC-1918 traffic and bogons unchecked (allowed) by default on WAN interfaces. Not everyone is setting that up correctly.

>>21966 *confused sounds* Ok. I'm computer M. There's also a computer P which is the provider. And there's a computer T which is a third party machine. M has public IP 1.1.1.1 P doesn't, because it's PPPoE T has HWaddress 3:3:3:3:3:3 T sends a packet with parameters <src=10.0.0.0, dst=1.1.1.1>. P receives the request and sends it to M. M processes the packed and sends response with parameters <src=1.1.1.1, dst=10.0.0.0>. T receives the request and has to decide where to send it. Question: how does it know that 10.0.0.0 in *this particular case* means HWaddress 3:3:3:3:3:3? Possible answer: using conntrack(?) + arp. It knows who (HWaddress) initiated the connection and thus it know what 10.0.0.0 means inside this particular connection. Question 2: if the possible answer above is correct, what the fuarrrk is the purpose of IP and why IP spoofing attacks are possible? Possible answer 2: In reality, P doesn't know where 10.0.0.0 is, because it has no customers with such IP address and thus the packed gets lost. Man you've kinda turned my world upside down.

>>21943 Hello! thanks for explaining NAT part. that makes sense. > Would be nice to see your entire routing table $ ip route: default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.192 metric 1002 10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.2 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.192 metric 1002 > You should be able to access services and SSH to the VPS using IP 10.8.0.1 to access the VPS. when connected to the VPN, 10.8.0.1:51821 doesn't work... I can't access the WebUI of wg-easy. > Have you tried to SSH into the VPS from the VPS itself? That shouldn't fail, because the packets should never leave the VPS. $ ssh vpsuser@localhost -p 5454 vpsuser@localhost: Permission denied (publickey). > A side note: It is much better security practice to firewall off SSH, Jellyfin, whatever is a 'personal service', from the public IP and access them only using 10.8.0.1 That won't solve my problem, but yes, it does sound safer to me. By the way, in this case I will have to be connected to a VPN to access my services. I won't be able to connect to them from my original IP address (from the ISP) I think you can create two VPNs, one for Internet access (hiding ISP IP address) and one for access to services. though... I'm not sure. > I didn't mean this, I meant another IP; it's probably cheaper/easier to get another IP from your provider, or even a block. so you're saying that I shouldn't use VPS' public ip, okay but what if the service has to be public, like minecraft server? then I should use another VPS right? so I should separate my "home server" for things like Jellyfin, and my "public server" for things like minecraft, webpage, etc... > As far as the VPS is concerned, your Origin IP when making a request to the public ip (2.2.2.3) will be either the public ip, - OR - the RFC 1918 address (10.8.0.2). It is common practice to filter incoming traffic from bogons/RFC1918 on public IPs by default for a lot of firewalls. By origin IP you mean src, right? like in src -> dest . What is "bogons"? dude, you seem to be speaking in generally familiar words, but I can't seem to grasp the point at all... I feel really stupid. > Depending on how you setup your NAT, traffic can be forced out the public interface only, or it can route directly to the public interface, never leaving the VPS. It's likely the latter. That indicates a firewall issue. That part I didn't quite get too, I'm really sorry... "traffic can be forced out the public interface only" - what do you mean by public interface? "route directly to the public interface" - what's the difference? "never leaving the VPS" - what do you mean by "traffic leaves the VPS"? "indicates a firewall issue" - what is has to do with firewall? based on the length of the explanation of the NAT part (which was perfect), explaining everything to me so I could understand what you're talking about would take a lot of your time, so I'll be fine if you'd just tell me what exactly should I do to fix my issue. > The easiest debug step is just to stop the firewall service for a moment to see what happens. I disabled ufw on VPS and nothing changed. Still can't ssh into "<vps_public_ip>" and I'm not sure how to setup ssh'ing with 10.8.0.1, and even if I would it probably wouldn't work because I can't access wg-easy WebUI on 10.8.0.1:51821. although I can ping 10.8.0.1 without any problems. >>21946 The problem is definitely not with the provider, because I know more than one person, even with the same plan as mine, who also put wg-easy and they are apparently doing fine. I see a big discussion down here, but I don't understand a damn thing at all.. sorry.

>>22001 > ip route This table shows that you aren't actually routing your traffic over the VPN, okay! Does whatsmyip.org show your VPS address? > when connected to the [...] But what about other services? netstat -tulpn on the VPS will show you what processes are bound to what ip/port combo, it could be that wg-easy is only bound to the public ip of the vps (2.2.2.2) > ssh yes, you can ssh in to tiself > so you're saying [...] Well, different IPs -- doesn't have to two VPS'. One VPS can have multiple IPs. IPs are usually cheaper than renting a whole nother server, that's why I am suggesting that. > bogons Yes origin == source ~= public interface bogons are IPs that aren't valid yet (haven't been allocated by IANA). > fix my problem You likely can't access wg-quick on 10.8.0.1 because it's not bound to that address. You can check with `netstat -tulpn` -- you should be able to change the wg bind address to 0.0.0.0 if you want to access it. Your local routing table shows that you are not routing traffic out the VPN at all, so if you can't SSH in while connected, there's likely another issue afoot; but it's irrelevant, because the big issues is that you aren't going through your VPN. You can try these commands on your local pc to try to route traffic correctly; these commands don't persist reboots, so worst case if you can't get online again, just reboot ip route del default # delete your default root ip route add default via 10.8.0.1 dev wg0 # tell computer to route traffic through wireguard only If you can't get online, you can delete the default route and then do ip route add default via 192.168.1.1 dev eth0 to undo the changes; no internet after changing the route indicates that it's not getting natted out the VPS. You'll have to enable NAT and forwarding -- there's guides on setting this up, look up 'ufw nat' should be just a few commands and something like 'sysctl ipv4.forwarding=true' or something like that

>>22004 > you aren't actually routing your traffic over the VPN I don't know, VPN is working... yes, it does show VPS' address. > you can ssh into itself but I got error? Or have I already passed the connection stage and this error kind of confirms it? > one vps can have multiple IPs I have a feeling that would make everything even harder, lol. > You likely can't access wg-quick on 10.8.0.1 because it's not bound to that address. You can check with `netstat -tulpn` -- you should be able to change the wg bind address to 0.0.0.0 if you want to access it. didn't quite get that part. > netstat -tulpn Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 0.0.0.0:51820 0.0.0.0:* users:(("docker-proxy",pid=24118,fd=4)) udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=1271,fd=13)) udp UNCONN 0 0 [::]:51820 [::]:* users:(("docker-proxy",pid=24123,fd=4)) tcp LISTEN 0 4096 0.0.0.0:51821 0.0.0.0:* users:(("docker-proxy",pid=24098,fd=4)) tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=868,fd=3)) tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=1271,fd=14)) tcp LISTEN 0 4096 [::]:51821 [::]:* users:(("docker-proxy",pid=24103,fd=4)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=868,fd=4)) I think process name isn't really helpful because wg-easy uses Docker...

tcpdump -nnvvi any port 22 See where it goes, see if it makes sense Turn on logging in wg and look for a line about disallowed packet or similar as seen in https://www.procustodibus.com/blog/2021/03/wireguard-logs/

Hello. OP's here. Sorry for a long reply, but I figured out the issue. It's a bug in wg-easy: https://github.com/wg-easy/wg-easy/issues/539 I switched to 3X-UI and everything works flawlessly. Thanks a lot for your assistance, anon!

>>21834 >localhost localhost would be his own computer OP needs to use the gateway's IP