Join Log in
Score:2
avatar Server

How to configure wireguard to forward client IP address (with gateway)?

jp flag
Daniel

I am trying to configure wireguard to work as a VPN server. The main problem is, that the gateway only forwards the VPN server ip to other server, not my client IP.

My setup is the following:

                                                        - server A (10.10.0.4)
                                                      /
CLIENT (10.10.1.3) -> wireguard server (10.10.1.2) -- 
                                       (10.10.0.2)    \
                                                        - server B (10.10.0.3)

The wireguard server runs on a machine with two interfaces:

  • eth0 (10.10.0.2)
  • wg0 (10.10.1.2)

When the VPN connection is established, I am able to connect to server A and server B (via ssh). The problem is, that the IP address of the wireguard server is forwarded (nat) to server A and B. Logged in via ssh shows me every time, that the last connection came from 10.10.0.2 (on server A and B). But on the wireguard server, the last logged in IP is my real client IP (10.10.1.3).

What I am trying to do is to configure wireguard so that my IP (10.10.1.3) is forwarded correctly to server A and B.

This is my client wireguard config file:

[Interface]
PrivateKey = xxx
Address = 10.10.1.3/24
DNS = 10.10.0.2, 8.8.8.8

[Peer]
PublicKey = XXX
AllowedIPs = 10.10.0.0/24
Endpoint = xxx.xxx.xxx.xxx:41194
PersistentKeepalive = 15

My wireguard server (wg0.conf) config:

[Interface]
Address = 10.10.1.2/24

## My VPN server port ##
ListenPort = 41194

PrivateKey = xxx

# Internet Gateway config: nat wg1 out to the internet on ens10
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
## Desktop/client VPN public key ##
PublicKey = xxx

AllowedIPs = 10.10.1.3/32

I guess that the iptables configuration is wrong, because of the nat / MASQUERADE, but I wasn't able to configure the gateway correctly.

I appreciate your help.

Update

Executing on server A (same on B)

ip -br link; ip -br address; ip route

Returns (public IP is masked):

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             96:00:01:29:d6:9b <BROADCAST,MULTICAST,UP,LOWER_UP>
ens10            UP             86:00:00:08:9c:c5 <BROADCAST,MULTICAST,UP,LOWER_UP>
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.0.3/32  fe80::9400:1ff:fe29:d69b/64
ens10            UP             49.xxx.xxx.xxx/32  2a01:xxx:xxx:xxx::1/64  fe80::8400:ff:fe08:9cc5/64
default via 172.31.1.1 dev ens10 proto dhcp src 49.xxx.xxx.xxx metric 100
10.10.0.0/16 via 10.10.0.1 dev eth0
10.10.0.1 dev eth0 scope link
172.31.1.1 dev ens10 proto dhcp scope link src 49.xxx.xxx.xxx metric 100
492
0 + 0
Score:1
A.B avatar Server
cl flag
A.B

NAT is done by the configuration so you get NAT as asked. To avoid using NAT you have to:

  • make sure end servers A and B have a real route back to the client

    If that's not the case, add at least this on A and B (if running Linux):

    ip route add 10.10.1.3/32 via 10.10.0.2

    UPDATE: OP's routing setup (in a cloud) makes A and B's traffic to 10.10.0.2 (or even between each others) go through an additional router 10.10.0.1 (part of the cloud network). So the route had to be added on this part, as confirmed by OP.

  • remove NAT on wireguard server

    Just remove the second iptables commands in the two WireGuard's PostUp and PostUp configuration, and make sure there's not a previously added entry left, by running this time only:

    iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

  • optional: update AllowedIPs on client

    If client wants to access wireguard server using server's address on its tunnel side rather than its eth0 side, or to be sure ICMP sent back by the wireguard server are received (eg: to get traceroute to server A working without * * *), 10.10.1.2 should also be in AllowedIPs to satisfy WireGuard's cryptokey routing.

    Replace on client:

    AllowedIPs = 10.10.0.0/24

    with:

    AllowedIPs = 10.10.1.2,10.10.0.0/24
0 + 0
jp flag
Daniel
Thanks for your response. I tried to add the IP route on both server (ip route add 10.10.1.3/32 via 10.10.0.2), but I only got an error: "Nexthop has invalid gateway". It seems, that there might be a network misconfiguration?!
0
Reply
jp flag
Daniel
I'll updated my question to provide the result of ```ip -br link; ip -br address; ip route```
0
Reply
A.B avatar
cl flag
A.B
With the added information: all traffic for 10.10.0.0/16 which would usually be LAN traffic is routed through 10.10.0.1 leaving no LAN traffic on server A or B that could have exceptions. The route has then to be added on 10.10.0.1 which is not appearing anywhere in the question.
0
Reply
jp flag
Daniel
Thanks for pointing me into the right direction. 10.10.0.1 is not completely out of control. It's a cloud network, but I added a route from 10.10.1.0/24 to 10.10.0.2. Now it's working perfectly. Thanks!
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.