0

I setup a wireguard server with AWS, setup the wireguard client with a raspberry PI.

Now I need to redirect the WG traffic (wg0) to eth1 (eth0 is the uplink to my switch)

-- my goal is to get a IP from my WG server when a client is connected to the PI eth1 (Full tunnel)

my WG config

[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = ##
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = ##
AllowedIPs = 10.1.1.2/32

I installed Netplan but I'm very lost with the config (I need to sent WG0 traffic to ETH1)

does the follow config make sense : (probably not...)

network:
    version: 2
    renderer: networkd
    bonds:
        bond0:
            dhcp4: yes
            interfaces:
                - wg0
                - eth1
            parameters:
                primary: wg0



It's would be even better for the Raspberry PI to joint my UniFi VLAN (uplink) and get an IP from there but still sent/receive all the traffic from WG server but that's to complex for me I guess

UPDATE: should I add the WG config to Netplan?

tunnels:
network:
    version: 2
    renderer: networkd
    bonds:
        bond0:
            dhcp4: yes
            interfaces:
                - wg0
                - eth1
            parameters:
                primary: wg0
  wg0:
    mode: wireguard
    addresses: 10.1.1.1/24
    peers:
      - keys:
         Public_key?
        ...
    key: Private_key?
Kevin
  • 103
  • 3
  • So basically you want the Pi to act like a VPN router in which case eth1 is the LAN interface and wg0 is the WAN interface, is that correct? – Tom Yan Mar 06 '22 at 11:32
  • Yes that's what I'm desperately try to accomplish. ETH0 is connected to my switch (so WAN), WG0 Is connecting to my AWS WG server and I want whatever devices connected in ETH1 (LAN) to go to WG0 (full tunnel) and get an IP from AWS – Kevin Mar 06 '22 at 12:50

1 Answers1

2

First of all bond has nothing to do with that, and basically, the drill is to make use of an ip rule, which looks up another route table (that consists of a default route with dev wg0) for all the traffics from eth1.

ip route add default dev wg0 table 123
ip rule add iif eth1 lookup 123

(The number 123 is arbitrary. You'll need to refine them if you e.g. want the eth1 hosts to be able to reach the eth0 hosts.)

Certainly IP forwarding needs to be enabled (sysctl) and allowed (firewall, if any) as well.

Then you decide whether you want to masquerade/NAT for the eth1 IP subnet, or add a return route for it on the wireguard server. The latter is recommended when possible, and one of the reasons is that you'll need to masquerade/NAT on wireguard server anyway (for either 10.1.1.2 or the eth1 IP subnet), assuming you want to use one of its interface for Internet connection. (The number of layers of NAT should be kept to the minimal.)

(I'm assuming 10.1.1.2 is the WG IP on the Pi. It's unclear which conf you have shown.)

Make sure the eth1 IP subnet does not conflict with any that is used on the wireguard server, if you choose not to NAT for it on the Pi. Also the subnet needs to be added to AllowIPs= on the wireguard server in that case.

Most likely you should use the PostUp= for the aforementioned setup, as I'm not sure if netplan has a way for you to specifiy it. (The added route should be gone when wg0 is gone, so you only need to delete the ip rule with Pre/PostDown=.)

EDIT: You should probably use Table=off on the client conf, unless you want the Pi's own traffics to go into the tunnel as well.

Tom Yan
  • 715
  • 2
  • 9
  • "Then you decide whether you want to masquerade/NAT for the eth1 IP subnet, or add a return route for it on the wireguard server. The latter is recommended when possible, and one of the reasons is that you'll need to masquerade/NAT on wireguard server anyway" - Should it not be "the former"? So you recommend masquerading on the server, right? I am struggling with something similar. On the wireguard server I can not ping anything on the client's LAN, although I added a route for this LAN into the tunnel. – bomben Aug 25 '22 at 15:51
  • `Should it not be "the former"?` No. What I meant was, you would need to NAT on the WG server for traffics that goes out to the Internet, but when possible you should avoid NAT on the WG client for the LAN hosts. Instead you can add a route for the LAN subnet on the WG server that routes the (replying) traffics for the subnet (back) to the WG client (since the WG client is part of the LAN as well there would already be a route that further routes the traffics back to the corresponding LAN host). – Tom Yan Aug 26 '22 at 01:58
  • Thanks! That's the way I did it and last night I could confirm it worked. What i don't understand is why the server does need an extra route, if `you'll need to masquerade/NAT on wireguard server anyway` as you wrote (and I also saw in my setup). Why is natting active but does not apply into the tunnel? Also, I recognised something weird: I can connect from any client in serverLAN to any client in clientLAN, but from the server itself, I can not. I can not even ping from the server to the clientLAN. The routing seems to just apply when the package comes redirected from the router. – bomben Aug 26 '22 at 06:19
  • `What i don't understand is why the server does need an extra route` because the server doesn't out-of-the-box know how to reach the LAN (the traffics from the LAN doesn't automagically "teaches" the server that). The default route (if exists) will be used for destinations not covered by a (more) specific route. – Tom Yan Aug 26 '22 at 11:57
  • `Why is natting active but does not apply into the tunnel?` You *can* configure NAT for traffics from other network/hosts (attached to the WG server) that destined at the WG client or its LAN, but that isn't relevant to the scenario this answer was talking about. Such NAT would be to hide / obfuscate network/hosts that try to reach the WG client or its LAN, by making the traffics look originating from the WG server. – Tom Yan Aug 26 '22 at 12:17