Not to be that guy…but there are no WireGuard servers or clients, only peers. Some setups “look” like clients, some “look” like servers, but it’s peers all the way down.
Nope, routing traffic between your network and the tunnel would involve routes and possibly NAT.
Wireguard is just a special interface on a peer computer that you can send packets to. What each peer decides to do with the packets is in the realm of routing.
Not unless your endpoint is configured to act as a gateway (IP forwarding, maybe also with masquerade) and allows other clients to access the IP address ranges you use in your home LAN (AllowedIP).
That was my assumption, but the way it was stated, I wanted to clarify there wasn’t something special about WireGuard in the way people tend to mean peer to peer
Its peer-tp-peer in that it can be configured in multiple modes on a peer by peer, interface by interface basis. You can make point to point, hub & spoke, or full mesh topologies. If you configure one of the peers for IP forwarding, it can gateway to external networks. If you configure two peers with IP forwarding and establish some routing you can build site to site topologoes, or add more peers for site to multisite and full mesh site topologies. Add IP masquerade (source NAT or PAT) to any of those topologies and it can provide remote access VPN.
Its very flexible. Most config guides walk you through a basic remote access VPN scenario that lets remote peers access local LAN services at the one end, but not the other, and/or additionally access Internet resources via IP masquerade. The other topologies require more work, but are (edit: not) much more difficult than the remote access use case.
Not to be that guy…but there are no WireGuard servers or clients, only peers. Some setups “look” like clients, some “look” like servers, but it’s peers all the way down.
It’s OK I was literally OMW to be that guy.
Do you mean it’s fully bidirectional?
E.g. connecting to the WireGuard “server” my work set up allows them full access to my internal network?
I would have assumed I would need to set some sort of reverse routing in that case
Nope, routing traffic between your network and the tunnel would involve routes and possibly NAT.
Wireguard is just a special interface on a peer computer that you can send packets to. What each peer decides to do with the packets is in the realm of routing.
Not unless your endpoint is configured to act as a gateway (IP forwarding, maybe also with masquerade) and allows other clients to access the IP address ranges you use in your home LAN (AllowedIP).
That was my assumption, but the way it was stated, I wanted to clarify there wasn’t something special about WireGuard in the way people tend to mean peer to peer
Its peer-tp-peer in that it can be configured in multiple modes on a peer by peer, interface by interface basis. You can make point to point, hub & spoke, or full mesh topologies. If you configure one of the peers for IP forwarding, it can gateway to external networks. If you configure two peers with IP forwarding and establish some routing you can build site to site topologoes, or add more peers for site to multisite and full mesh site topologies. Add IP masquerade (source NAT or PAT) to any of those topologies and it can provide remote access VPN.
Its very flexible. Most config guides walk you through a basic remote access VPN scenario that lets remote peers access local LAN services at the one end, but not the other, and/or additionally access Internet resources via IP masquerade. The other topologies require more work, but are (edit: not) much more difficult than the remote access use case.
Thanks for the in depth explanation.
When I’m using it from my work laptop to work’s server to access internal sites, it feels very client -> server.
When they said peer to peer, I was worried I was somehow also exposing my personal devices to work’s network
I didn’t realize there were so many other ways to set it up