Question about how wireguard and routing

RouterOS General
1

I was working on a project in a lab environment for routing a client’s traffic through a VPN with routing rules. The VPN provider mentions to masquerade traffic coming out of the WG interface otherwise traffic will be dropped which makes sense. Maybe I am mistaken but I’d assume the traffic wouldn’t flow unless you NAT’d it again when it is leaving the WAN but it seems that it does that automatically without needing a NAT rule set up?

I have have a rule setup to have all traffic from 10.0.0.254 use the “VPN” routing table. The routing table consists of two rules 0.0.0.0/0 → 10.2.0.2%wireguard1 and 154.47.25.145 → ether1.

My assumption is that although all traffic from 10.0.0.254 is being NATED while leaving the wireguard1 interface that it would be a 10.2.0.2 private ip and would be dropped after leaving the WAN. That’s why I have the rule to masquerade all traffic leaving WAN disabled to test it.

If I were to ping 1.1.1.1 with a source address of 10.2.0.2 it fails unless masquerading is enabled on the WAN interface.

Obviously this is probably normal and there is something simple I am probably missing. Just trying to learn, not an expert in anyway. If someone could let me know why this is happening I’d love to know.

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/ip pool
add name=dhcp_pool0 ranges=10.0.0.2-10.0.0.254
/ip dhcp-server
add address-pool=dhcp_pool0 interface=ether2 name=dhcp1
/port
set 0 name=serial0
/routing table
add disabled=no fib name=vpn
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=154.47.25.145 endpoint-port=\
    51820 interface=wireguard1 name=peer1 public-key=\
    "j+clV7yQPWWhQ7v4/8AWBzZ5DNUGSvruZAIsVtyZ92A="
/ip address
add address=10.0.0.1/24 interface=ether2 network=10.0.0.0
add address=10.2.0.2/30 interface=wireguard1 network=10.2.0.0
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=10.0.0.0/24 dns-server=1.1.1.1 gateway=10.0.0.1
/ip firewall nat
add action=masquerade chain=srcnat disabled=yes out-interface=ether1
add action=masquerade chain=srcnat out-interface=wireguard1
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.2.0.1 \
    routing-table=vpn scope=30 suppress-hw-offload=no target-scope=10
add disabled=no dst-address=154.47.25.145/32 gateway=ether1 routing-table=vpn \
    suppress-hw-offload=no
/routing rule
add action=lookup disabled=no src-address=10.0.0.254/32 table=vpn
/system note
set show-at-login=no
/tool sniffer
set filter-direction=tx filter-ip-address=!192.168.11.2/32 filter-stream=yes \
    streaming-enabled=yes streaming-server=192.168.11.2
2

I dont fully understand your question here.

When you establish the Wireguard tunnel the router uses its IP on the ether1 interface to communicate with the Wireguard Peer.
Since its a encrypted TUNNEL everything inside the tunnel is invisible to every hop in between.

And since the traffic is originating from the router, which presumably has an IP on the ether1 interface, there’s no need to NAT.
You have 1 IP-Address on ether1. You need just 1 Address (for the router).
Everything else communicates through the wireguard tunnel, which counts as another interface.

3

Thanks for the information. I know it’s likely a dumb question I guess I trip myself up on the dumb questions because I overthink it. I was under the impression that due to the wireguard interface having an IP of 10.2.0.2 that it would be the src-address when leaving the WAN but if I am understanding you correctly due to the traffic (wireguard) originating from the router the src-address will just be any interface it’s traveling out of. (WAN address in this instance)

4

In this case the wireguard traffic is going to some third party site, presumably to go out internet there.
Probably not even a wireguard device at the other end.
Since we dont control both ends, how is the remote end supposed to know what subnets we are going to have coming through on wireguard.
THey would have to know for two reasons.
a. to put our subnets into their allowed IPs
b. to add ip routes for each subnet thats not local to their end device ( so traffic can be returned through the wg tunnel ).

By sourcenatting the traffic going into the tunnel (and thus the IP address of our wireguard interface ),
the remote device does not need any of our subnet information as the allowed IP is allowed and IP route for that already exists.

Third party servers are only expecting traffic from the single IP they have assigned to you.