NAT wireguard-originated traffic

RouterOS General
1

Hi

I’ve set up two routers R1 and R2 (ROS 7.1.1) and connected them with wireguard. Tunnel works fine, I can ping both endpoints.
I’m trying to use it as a kind of VPN, forwarding part of the traffic from R1 via R2 to the internet.

So - I’ve set up routes, firewall rules. Firewall counters on R2 shows that packets from R1 are arriving.
If I open packet sniffer on R2 I can see packets from R1 on both wireguard link and internet link with original IP address of R1.

Now I have to NAT the traffic - so I went to NAT chain and add MASQ rule. Tried following filters:

  • rule based on source IP of R1 - Does not work, NAT counters stays at 0.
  • rule based on connection mark with mangle marking packets (mangle counters shows that there is traffic) - Does not work, NAT counters stays at 0.
  • catch-all rule for all traffic going out on R2 - Does not work
    So - it looks like NAT chain does not catch wireguard-originated traffic.

So:

  • packets are arriving
  • packets are routed properly
  • packets are present on internet link on R2
  • NAT does not catch them

Is this a bug/feature?

2

Who said you have to NAT traffic??
https://forum.mikrotik.com/viewtopic.php?t=182340

Such instances are rare and not the norm and usually fall into the category if you have an ISP router before your MT router and are trying to do something extra…

Without seeing the configs on both ends, assistance will be futile…

3

anav, thanks for reply but I don’t really understand Your post nor mentioned article.

The situation here is simple:

  • R1 is a “client”. R2 is “gateway”.
  • R1 and R2 does have own internet connection, but part of R1-originated internet traffic has to go via R2, not by local link on R1.
  • I’m testing it by redirecting ICMP traffic from R1 to 153.19.40.230 via R2

Packet flow - as it works at this time:

  1. Traffic from R1 (client) goes to R2 (“internet gateway”) via wireguard (I can sniff this)
  2. It is being processed by firewall on R2 (packet counters increases)
  3. It is not being processed by NAT on R2 regardless what I put into config (counters does not increase)
  4. This means that R1 packets goes to the internet with internal IP of R1 router, not public address of R2

I suppose there is no need to publish config as this problem is easy to replicate - as stated above. But - here it goes:


R1 (the client)

/ip address
add address=192.168.254.101 interface=wg-arrow network=255.255.255.255
(additional public ip is taken from ppoe client)
/interface wireguard
add listen-port=13231 mtu=1420 name=wg-arr
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address= endpoint-port=49131 interface=wg-arr persistent-keepalive=30s public-key=“”
/ip route
add disabled=no distance=1 dst-address=192.168.254.254/32 gateway=wg-arr pref-src=“” routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add comment=“wireguard test” disabled=yes distance=1 dst-address=153.19.40.230/32 gateway=wg-arr pref-src=“” routing-table=main scope=30 suppress-hw-offload=no
target-scope=10



R2 (the internet gateway)

/ip address
add address=<public_ip> interface=ether1-WAN network=<public_net>
add address=192.168.254.254 interface=gdansk network=255.255.255.255
/interface wireguard
add listen-port=49131 mtu=1420 name=gdansk
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address= endpoint-port=13231 interface=gdansk persistent-keepalive=30s public-key=“”
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=<inet_ip>
add disabled=no distance=1 dst-address=192.168.254.101/32 gateway=gdansk
pref-src=“” routing-table=main scope=30 suppress-hw-offload=no
target-scope=10

/ip/firewall/filter
add action=jump chain=forward comment=“wireguard forward” in-interface-list=wireguard jump-target=*CLASS_FORW_WIREGUARD
add action=accept chain=*CLASS_IN_WIREGUARD protocol=icmp
add action=reject chain=*CLASS_IN_WIREGUARD log=yes log-prefix=“wireguard in reject” reject-with=icmp-network-unreachable

/ip firewall nat (this does not work)
add action=src-nat chain=srcnat comment=“MASQ for wireguard” log-prefix=MASQ out-interface=ether1-WAN to-addresses=<ip_address>

4

What other srcnat rules you have in “/ip firewall nat” on R2? Some of them must be catching these packets.

5

No they don’t. This is the first rule.

BUT - the problem is fixed now. All I did is to restart the router. So - definitelly - there is some kind of problems in 7.1.1

6

btw: it works and is not using masq/snat rules. I can disable them. It is strange, I don’t understand what is changing source address.
Does wireguard have it’s own MASQ?

7

One explanation would be that you started ping before you had srcnat rule, conntrack made a virtual connection for it without srcnat, and when you added srcnat rule later, it still used what it had from before. That’s because srcnat works only for new connections (from the first packet). Same happens when you first have srcnat, then disable it, but ping still works and is natted. But if you’d stop it, let the “connection” time out, then next ping would be seen as new connection.

8

That is good explanation - but next question arrives:
why it works even with all NAT rules disabled? It looks like wireguard is doing NAT internally.

9

So I’m answering to myself :wink:

Works because it is already being tracked. If I flush all connections it stops working

So:

  1. Wireguard needs SRCNAT and is not doing NAT internally
  2. I need to double-check before posting
10

You were faster and it’s correct answer.

11

Hahaha, this is rather amusing…