wireguard for vpn?

sixpiece

New Member


Messages: 13

Question 1: I am able to make a handshake but how can I make it so that my client can request and receive traffic through the server that it has made a handshake connection with. How can I make it so that the server will receive requests and forward the requests outside of the network through the Network Address translator connected to the world wide web as well as transmit the data responses to the client?

Question 2: Does Wireguard work with FreeBSD are there significant issues and what are they?
 

diizzy

Aspiring Daemon

Reaction score: 209
Messages: 601

1. Not sure what you're trying to accomplish
2. Works great
 
OP
sixpiece

sixpiece

New Member


Messages: 13

1. Not sure what you're trying to accomplish
2. Works great
-- I would like my ipad to be able to connect to the server and then browse the internet through the server. I also would like to understand the process and be comfortable with it and have my small questions answered so that I can do this. For example, I want the Apache Web Server to work unhindered. I would like to understand how the private networking works so that I do not create more routes than necessary but the meaning of more routes, etc.. And possibly more questions.

From the wireguard website (link above):

Routing All Your Traffic​

A less obvious usage, but extremely powerful nonetheless, is to use this characteristic of WireGuard for redirecting all of your ordinary Internet traffic over WireGuard. But first, let's review the old usual solutions for doing this:

The Classic Solutions​

The classic solutions rely on different types of routing table configurations. For all of these, we need to set some explicit route for the actual WireGuard endpoint. For these examples, let's assume the WireGuard endpoint is demo.wireguard.com, which, as of writing, resolves to 163.172.161.0. Further, let's assume we usually connect to the Internet using eth0 and the classic gateway of 192.168.1.1.

Replacing The Default Route​

The most straightforward technique is to just replace the default route, but add an explicit rule for the WireGuard endpoint:

# ip route del default
# ip route add default dev wg0
# ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0
This works and is relatively straightforward, but DHCP daemons and such like to undo what we've just did, unfortunately.

Overriding The Default Route​

So, instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default:

# ip route add 0.0.0.0/1 dev wg0
# ip route add 128.0.0.0/1 dev wg0
# ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0
This way, we don't clobber the default route. This also works quite well, though, unfortunately when eth0 goes up and down, the explicit route for demo.wireguard.com will be forgotten, which is annoying.

Rule-based Routing​

Some folks prefer to use rule-based routing and multiple routing tables. The way this works is we create one routing table for WireGuard routes and one routing table for plaintext Internet routes, and then add rules to determine which routing table to use for each:

# ip rule add to 163.172.161.0 lookup main pref 30
# ip rule add to all lookup 80 pref 40
# ip route add default dev wg0 table 80
Now, we're able to to keep the routing tables separate. Unfortunately the downside is that explicit endpoint rules still need to be added, and there's no cleanup when the interface is removed, and more complicated routing rules now need to be duplicated.

Improved Rule-based Routing​

The prior solution relies on us knowing the explicit endpoint IP that should be exempt from the tunnel, but WireGuard endpoints can roam, which means this rule may go stale. Fortunately, we are able to set an fwmark on all packets going out of WireGuard's UDP socket, which will then be exempt from the tunnel:

# wg set wg0 fwmark 1234
# ip route add default dev wg0 table 2468
# ip rule add not fwmark 1234 table 2468
# ip rule add table main suppress_prefixlength 0
We first set the fwmark on the interface and set a default route on an alternative routing table. Then we indicate that packets that do not have the fwmark should go to this alternative routing table. And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. This is the technique used by the wg-quick(8) tool.

Improving the Classic Solutions​

The WireGuard authors are interested in adding a feature called "notoif" to the kernel to cover tunnel use cases. This would allow interfaces to say "do not route this packet using myself as an interface, to avoid the routing loop". WireGuard would be able to add a line like .flowi4_not_oif = wg0_idx, and userspace tun-based interfaces would be able to set an option on their outgoing socket like setsockopt(fd, SO_NOTOIF, tun0_idx);. Unfortuantely this hasn't yet been merged, but you can read the LKML thread here
 

m0nkey_

Member

Reaction score: 15
Messages: 38

I do believe you made an appearance in the #wireguard IRC channel earlier today. I may be wrong, but your question is very similar.

Why are you adding routes manually? In the [Peer] section of your config, just add AllowedIPs = 0.0.0.0/0, this will automatically configure and send all traffic over the tunnel.

Consider the AllowedIPs configuration item as the routable subnets.

Here's an example client config

Code:
[Interface]
PrivateKey = [removed]
Address = 10.10.0.2/24
DNS = 192.168.192.1, example.net

[Peer]
PublicKey = [removed]
PresharedKey = [removed]
AllowedIPs = 0.0.0.0/0
Endpoint = [hostname]:[port]
 
OP
sixpiece

sixpiece

New Member


Messages: 13

I do believe you made an appearance in the #wireguard IRC channel earlier today. I may be wrong, but your question is very similar.

Why are you adding routes manually? In the [Peer] section of your config, just add AllowedIPs = 0.0.0.0/0, this will automatically configure and send all traffic over the tunnel.

Consider the AllowedIPs configuration item as the routable subnets.

Here's an example client config

Code:
[Interface]
PrivateKey = [removed]
Address = 10.10.0.2/24
DNS = 192.168.192.1, example.net

[Peer]
PublicKey = [removed]
PresharedKey = [removed]
AllowedIPs = 0.0.0.0/0
Endpoint = [hostname]:[port]

Thank you for the reply...

When I do this wg0.conf will not allow it to do that:

service wireguard restart modifies wg0.conf as follows:

Code:
root@grocery:/usr/local/etc/wireguard # service wireguard restart
[#] wg showconf wg0
[#] ifconfig wg0 destroy
[#] ifconfig wg create name wg0
[#] wg setconf wg0 /dev/stdin
[#] ifconfig wg0 inet 192.168.222.1 alias
[#] ifconfig wg0 inet 0.0.0.0 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 192.168.222.2/32 -interface wg0
[+] Backgrounding route monitor
root@grocery:/usr/local/etc/wireguard # vi wg0.conf
[Interface]
Address = 192.168.222.1
Address = 0.0.0.0
SaveConfig = true
ListenPort = 51820
PrivateKey = itSbigsecretcodeg=

[Peer]
PublicKey = nottellingthekeycodec=
AllowedIPs = 192.168.222.2/32
Endpoint = 223.123.778.255:54245

ios.conf is as follows:

interface
public key

pair
endpoint my ip and port
authorized ips 0.0.0.0/0
 
OP
sixpiece

sixpiece

New Member


Messages: 13

Which firewall are you using?
Have you configured your firewall correctly? It could be blocking your traffic.
See the Network section of this guide (for OpenBSD) - https://thomasward.com/openbsd-wireguard/
I got it to work. I think the issue was very simple... but there was something with to do with the firewall I think... and there was also Addresses on the Client must be the Addresses allowed on the Server... the same number this caused issue so it might have been overthought...
 
Top