Difference between revisions of "Wireguard"

From Steak Wiki
Jump to navigationJump to search
Line 83: Line 83:
 
<pre>
 
<pre>
 
debian client:
 
debian client:
 +
a file named /etc/wireguard/wg0.conf
 
[Interface]
 
[Interface]
 
PrivateKey =
 
PrivateKey =
Address =  
+
ListenPort =
 +
#Address = SEE NOTES BELOW
  
 
[Peer]
 
[Peer]
Line 92: Line 94:
 
AllowedIPs = 0.0.0.0/0 #for routing all traffic, this may vary
 
AllowedIPs = 0.0.0.0/0 #for routing all traffic, this may vary
 
Endpoint =
 
Endpoint =
 +
 +
 +
And 'try' the following. (read below for a trap)
 +
in /etc/network/interfaces
 +
auto wg0
 +
iface wg0 inet auto
 +
address
 +
netmask
 +
pre-up wg-quick up $IFACE
 +
post-down wg-quick down $IFACE
 +
 +
One day on debian bullseye 11.1 i was unable to get the above
 +
section in network/interfaces working because the vpn server used a
 +
ddns name, and for whatever reason dns wouldn't resolve. theres not
 +
really a way to delay the setup of the wg0 interface, or set it as manual
 +
in /etc/network/interfaces
 +
(there is a manual option but that doesn't do what you think).
 +
If you run into this trap, just use wg-quick manually. If you end up using
 +
network interfaces, then the address must be specified in network interfaces but
 +
if you only use wg-quick then you specify the address in the wg0. I would guess
 +
this is only a problem if you use ddns in the server endpoint from the debian client,
 +
and with an ip it's not going to be an issue.
  
  
Line 105: Line 129:
 
         option preshared_key  
 
         option preshared_key  
 
         option route_allowed_ips '1'
 
         option route_allowed_ips '1'
 +
        list allowed_ips ''
 
         list allowed_ips ''
 
         list allowed_ips ''
  

Revision as of 09:45, 2 January 2024

Wireguard is a godsend to IT admins trying to manage VPNs. It is just as complex as it needs to be, to be a practical vpn, but no more. Much faster than any other VPN I've ever used (roadwarrior scripts and things like sonicwalls global vpn client don't count, as they just hide the underlying functionality from the admin, making it impossible to fix if things don't 'just work'.).

wireguard has a few setup scenarios. each are unique.

windows client to owrt split tunnel

windows

this setup assumes you are using it as a traditional vpn to access resources. not to hide your ip address / internet traffic.

download, run installer, add empty tunnel

[Interface]
PrivateKey = (it should auto populate this for you)(public key is above in text field)                          
Address = (the ip you want on the vpn net/32 for one ip)

[Peer]
PublicKey = (find it on server)
AllowedIPs = (what you want to be able to connect to on vpn lan)(usually its the vpn router's ip, and then the lan range behind the router)
Endpoint = (ipaddress:port)

Optional: If you have a windows server w/dns (i.e. domain) don't use the vpn router but the windows server as the DNS. However, you may want to also add some other dns (level 4 / google) as backups. e.g.

[Interface]
PrivateKey =                        
Address = 
DNS = (windows server and the subnet should be on allowed ips, if it isn't already), 4.2.2.2, 8.8.8.8

troubleshoot that with nslookup. You might think you can avoid this and hardcode the dns in window's /etc/hosts but that won't properly resolve the domain controller. and everytime you access a domain share you have to enter a password. bad idea.

owrt

config interface 'vpn'
        option proto 'wireguard'
        option private_key
        option listen_port someport
        list addresses ipofvpnhost

config wireguard_vpn 'anyname'
        list allowed_ips 'onlyoneip/32'
        option public_key
        option route_allowed_ips '1'

only tricky thing here is you need route_allowed_ips so the client knows to look for it's specified allowedips on the vpn iface the good news about this setup, is that owrt handles some of the routing / forwarding on its side. so you don't have to worry about a source nat command. you do have the follow the owrt install docs for wg though.

Tips/Troubleshooting

Basics

tcpdump -ni eth1 dst/src <ip>
tcpdump -ni vpn
route
wg (make sure the keys line up)

Make sure the vpn network is added to the lan section of /etc/config/firewall. This is a mistake I used to make.

Imagine doing this on one of those intern designed tacked on guis from sophos or sonicwall. Pure torture. Literally a layer of dogshit painted over the 'actually useful' command line tools. There is a reason starlink uses Owrt, and not some busywork web gui bullshit. Trying to use the molasses packet capture on a sonicwall or sophos through the web gui is demonic firewall design. "Some things exist on earth as an example of how it is 'not' supposed to be done".

Windows Firewall for SMB Shares

Windows and wireguard will set it as a public network where smb doesn't always work. the network is not listed in settings. but its there in the firewall section of settings... so you have to edit it via powershell. bad software design. (from W11 2023).

Get-NetConnectionProfile will list the networks (there are a bunch of windows Get- commands)
Set-NetConnectionProfile -InterfaceAlias 'wg0' -NetworkCategory 'Private'

note that the Alias may be different from wg0. the samba error in mount.cifs in linux (if testing an smb share) is mount error(115): Operation now in progress. the smb error in windows. haha. there's no fucking error # in windows. just a generic error message.

Finally, you have to make one other change: its a firewall error. as you can prove because mount.cifs works with the firewall disabled. Therefore, set these ports open:

UDP\137-138 and TCP\137,139,445.

in windows advanced firewall. it's two rules, so set all the TCP ports open, then all the UDP ports open

todo

alpine to owrt

debian to owrt

debian client:
a file named /etc/wireguard/wg0.conf
[Interface]
PrivateKey =
ListenPort = 
#Address =  SEE NOTES BELOW

[Peer]
PublicKey =
PreSharedKey = 
AllowedIPs = 0.0.0.0/0 #for routing all traffic, this may vary
Endpoint =


And 'try' the following. (read below for a trap)
in /etc/network/interfaces
auto wg0
iface wg0 inet auto
 address 
 netmask 
 pre-up wg-quick up $IFACE
 post-down wg-quick down $IFACE

One day on debian bullseye 11.1 i was unable to get the above
section in network/interfaces working because the vpn server used a
ddns name, and for whatever reason dns wouldn't resolve. theres not
really a way to delay the setup of the wg0 interface, or set it as manual 
in /etc/network/interfaces
(there is a manual option but that doesn't do what you think).
If you run into this trap, just use wg-quick manually. If you end up using
network interfaces, then the address must be specified in network interfaces but
if you only use wg-quick then you specify the address in the wg0. I would guess
this is only a problem if you use ddns in the server endpoint from the debian client,
and with an ip it's not going to be an issue.


openwrt server:
config interface 'vpn'
        option proto 'wireguard'
        option private_key ''
        option listen_port ''
        list addresses 'wireguard outside ip'

config wireguard_vpn 'apeer'
        option public_key 
        option preshared_key 
        option route_allowed_ips '1'
        list allowed_ips ''
        list allowed_ips ''


windows to windows

owrt to debian

CLIENT: openwrt
config interface 'vpn'
        option proto 'wireguard'
        option private_key '
        list addresses 'youraddress'

config wireguard_vpn
        option description 'name'
        option endpoint_host 'ipaddress'
        option endpoint_port 'port'
        list allowed_ips 'debiansubnetsyouwanttoaccess/24'
        list allowed_ips 'debianvpnaddress/32'
        option public_key '
        option preshared_key '
        option route_allowed_ips '1'

the allowed ips and route allowed ips are important here. if this was a fullon vpn, the allowed ips would be 0.0.0.0/0

SERVER: debian 10
====================
(etc network interfaces)
(note: see debian wiki for an alternative configuration)
auto wg-p2p
iface wg-p2p inet static
        address anyip
        netmask 255.255.255.0
        pre-up wg-quick up $IFACE
        post-down wg-quick down $IFACE

(/etc/wireguard/wg-p2p.conf)

[Interface]
PrivateKey = 
ListenPort = portnumber

[Peer]
PublicKey =
PreSharedKey = 
AllowedIPs = owrtvpn/32

with these two settings, the iface will be visible on the specified udp port 

and ping between will work. this is p2p.
if ping doesnt work, make sure there are routes between each box on the vpn interface

next

DEBIAN requires firewall rules
AND
ipv4 forwarding enabled.

its NOT masquerade
it's this:
iptables-legacy -t nat -A POSTROUTING -s vpnsubnet/24 -o vpsoutputiface -j SNAT --to-source vpswanip
the outputiface is eth0 or eth1
convert to nft with iptables-translate if necessary

in my VPS, ipv4 forwarding was not enabled by default. TRAP.
so do that right too.

vpns will bite you here:

firewall rules must change traffic from vpn to appear like its coming from vps. yes, even wireguard (sometimes... depends what distro you use)
forwarding must be enabled (depends upon distro again, but don't forget this)
wireguard: routes must be properly setup
wireguard: ping to start interface conversation from client. when in doubt use tcpdump.


firewall on client owrt: must add vpn to WAN (not lan zone) to minimize setup (i.e. so you don't make its own interface)
once you do this last step, clients will be able to connect in the client pool. not just the owrt router.

Troubleshooting:
make sure docker isn't causing trouble. if you install docker, it disables the 
default forwarding policy of accept. (makes it reject).