Back-to-Home-VPN: firewall logs multiple connection attempts from 127.0.0.1 to 0.0.0.0:0 and 127.0.0.1:0

RouterOS General
1

I’m seeing these packets in firewall INPUT whenever back-to-home-vpn is enabled:

 13:55:40 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:55:45 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:55:50 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:55:55 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:00 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:06 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:11 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:16 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:21 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:26 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:31 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:36 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->0.0.0.0:0, len 176
 13:56:41 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->127.0.0.1:0, len 176
 13:56:46 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->127.0.0.1:0, len 176
 13:56:51 firewall,info input: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:41878->127.0.0.1:0, len 176

These are Back-to-Home VPN packets because port 41878 is the chosen port of the service:
/interface wireguard
add comment=back-to-home-vpn listen-port=41878 mtu=1420 name=back-to-home-vpn

As soon as back-to-home-vpn is disabled, the packets also stop arriving in INPUT.

I would like to know if this is somehow some misconfiguration in the back-to-home-vpn Wireguard service. I also have another, different Wireguard instance and don’t observe such packets in the firewall from that service. The packets above are caught by the DROP all final INPUT rule in my firewall setup, and even though they are dropped, back-to-home-vpn continues to function normally.

2

CAPsMAN, Wireguard and others, use the loopback port to work properly, if you blocked it or deleted the default firewall rule that allow the loopback, this is the result.

P.S.: unknown is the internal CPU process

3

You mean this default firewall rule:

/ip firewall {
<snip>
filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
<snip>
}

It only matches packets in INPUT with dst-address=127.0.0,1. You forgot that in the logs there is also dst-address=0.0.0.0, which DOESN'T match the rule above.

4

Add the missing rule…
/ip firewall filter
add chain=input action=accept src-address=127.0.0.1 comment=“defconf: accept from local loopback (for Wireguard)”

5

I have the rule re-enabled.

I just need to understand, why the BTH VPN service generates those connections, with dest port 0 no less, when a similar Wireguard config achieves the same service the BTH VPN provides (sans the relay), WITHOUT generating those connections on dest port 0.

6

The “unknown” is a clue — that’s some process running on RouterOS as @rextended suggestions.

One guess is BTH does need to detect if it need use direct vs proxy mode, so perhaps the traffic is part of that detection. Even if direct right now, WAN could change to need proxy mode. And why it differ from a normal WG peer connection.

The other guess be that it’s some internal web service that creates a WG peer from BTH app (since that take username/password, but something has to create the BTH peer inside RouterOS)

7

Yes, I know what such a packet meant. It is something internal to RouterOS that cannot be discerned from any of the user-facing UIs.


You are correct. I overlooked these functionalities relating to the relay. But, most importantly, that the service also provides seamless integration with an app that offers ease of use. Another pair of eyes help make things clearer.

I have already modified the rule to use src-address matching instead of dst-address for loopback traffic or those that originate from localhost.

Thank you @Ammo and @rextended.