Hacked? or bug

I freaked out when I saw this, luckily its a test system with little-to-none personal data.
You can see the vpn tx go nuts
image

However when I looked at the wan tx I calmed down somewhat, I did not restart it, just unplugged the wan-cable twice. Once during freakout and after to test to see if counters would reset and they did not.

So while cable was unplugged I recorded what was happening:

image

Any idea's?

Because if hackers can download with that speed over an unplugged wan-cable I will start looking for a simpler profession such as ditch digger or burger flipper. (I have some past experience :smile: )

edit:
I think it all started after I enabled this (unsure):

image

Counter vpn1 stopped going crazy when I restarted wifi device.

wifi has nothing to do with WAN, it is as minimum one NAT away from it.

I understand, but that was the last change I made.

edit:
The more I look into it, the less sense the vpn txcounter makes, but its there.

You can start with sharing your configs like /etc/config/network and /etc/config/firewall.

/etc/config/network:

config globals 'globals'
	option packet_steering '1'

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config device
	option name 'eth1'
	option ipv6 '0'

config interface 'lan'
	option device 'eth1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option delegate '0'

config device
	option name 'eth0'
	option ipv6 '0'

config interface 'wan'
	option device 'eth0'
	option proto 'dhcp'
	option hostname '*'
	option peerdns '0'
	option delegate '0'
	option ip4table '10'
	option ip6table '10'

config interface 'vpn1'
	option proto 'wireguard'
	option private_key  '<redacted>' 
	list addresses '10.10.11.2/32'
	list dns '10.10.11.1'
	option delegate '0'
	option ip4table '11'
	option ip6table '11'

config wireguard_vpn1
	option public_key  '<redacted>' 
	list allowed_ips '0.0.0.0/0'
	option endpoint_host  '<redacted>' 
	option endpoint_port '51820'
	option route_allowed_ips '1'

config device
	option name 'phy0-ap0'
	option ipv6 '0'

config interface 'wlan'
	option proto 'static'
	option force_link '0'
	option device 'radio0.network1'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option delegate '0'

config interface 'vpn2'
	option proto 'wireguard'
	option private_key  '<redacted>' 
	list addresses '10.10.12.2/32'
	list dns '10.10.12.1'
	option delegate '0'
	option ip4table '12'
	option ip6table '12'

config wireguard_vpn2
	option public_key  '<redacted>' 
	list allowed_ips '0.0.0.0/0'
	option endpoint_host  '<redacted>' 
	option endpoint_port '51820'
	option route_allowed_ips '1'

config interface 'vpn3'
	option proto 'wireguard'
	option private_key  '<redacted>' 
	list addresses '10.10.13.2/32'
	list dns '10.10.13.1'
	option delegate '0'
	option ip4table '13'
	option ip6table '13'

config wireguard_vpn3
	option public_key  '<redacted>' 
	list allowed_ips '0.0.0.0/0'
	option endpoint_host  '<redacted>' 
	option endpoint_port '51820'
	option route_allowed_ips '1'

config rule
	option lookup '10'
	option mark '10'
	option in 'lan'

config rule
	option in 'lan'
	option lookup '11'

config rule
	option in 'wlan'
	option lookup '12'

config route
	option target  '<redacted>' 
	option gateway  '<redacted>' 
	option interface 'loopback'

config route
	option target  '<redacted>' 
	option gateway  '<redacted>' 
	option interface 'loopback'

config route
	option target  '<redacted>' 
	option gateway  '<redacted>' 
	option interface 'loopback'

/etc/config/firewall:

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option drop_invalid '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'

config forwarding
	option src 'lan'
	option dest 'wan'

config zone
	option name 'vpn1'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'vpn1'

config forwarding
	option src 'lan'
	option dest 'vpn1'

config zone
	option name 'wlan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'wlan'

config zone
	option name 'vpn2'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'vpn2'

config forwarding
	option src 'wlan'
	option dest 'vpn2'

config zone
	option name 'vpn3'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'vpn3'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

You are sending all your traffic through your vpn

1 Like

That's not the point of this conversation, but thank you for caring.

What is the point then?

Are you saying that you're genuinely concerned your router is somehow connecting to the Internet - despite having disconnected it from the Internet?

Your screenshot/videos with comedy-like descriptions are confusing.

I don't see RX (i.e., no download) changing, so what's your concern?

I don't see anything "happening".

What is "it"?

That makes sense, particularly if your SRC traffic were WiFi clients.

Oh, my bad, I sometimes forget humor does not translate well.

You can see the vpn1 TX go up, meaning I'm uploading which freaked me out because I wasn't. So I unplugged the cable at TX: 5.xx GB and it stopped. After some investigation, I looked and saw the counter going up again. Then I recorded it and made some screenshots. What's weird is that the RX remains static.

So I figured there might have been a race condition of some sort.

The upload/TX counter going crazy

Now that is whats weird, WFI-clients only have access to vpn2 (at least that was the intended configuration, did I mess up somewhere ?).

Also wireless is configured with option band '2g' (65 mbit iirc)
So looking at the gif, I dont think it was the wifi:

24.04 GB - 23.48 GB = 0.59 GB = 590 MB
4h24m4s  - 4h23m48s = 16s

590 MB / 16 s = 36.875 * 8 = 295mbit

That's all I can make of it, I'm a bit green when it comes to routers and routing :blush:

That's not weird. You disconnected the Internet, correct?

Where would an encrypted response [magically] come from?

Not weird. Use tcpdump to see where the SRC of the traffic is.

1 Like

Probably iftop for text ui.

What other devices are on the network? 20.55GB is a lot for just transmit but maybe there is some device doing some sort of file upload. If this is over a larger period of time it wouldn't be that surprising.

I personally would use tcpdump to get a traffic sample and then wireshark to analysis it.

Thanks for the support guys, I really appreciate it.

The problem seems to be related to disconnecting the wan-cable. It happened today again and I made sure there was nothing attached to the router other than a workstation, wifi limited to one mac/device.

This time it was vpn3 where tx skyrocketed. Afaik if tx vpn3 increases so should tx wan correct ?

# ifconfig|grep -E 'Link|bytes'
eth0      Link encap:Ethernet  HWaddr <redacted>
          RX bytes:650585023 (620.4 MiB)  TX bytes:76295046 (72.7 MiB)
eth1      Link encap:Ethernet  HWaddr <redacted>
          RX bytes:31768553 (30.2 MiB)  TX bytes:106859311 (101.9 MiB)
lo        Link encap:Local Loopback  
          RX bytes:74045317 (70.6 MiB)  TX bytes:74045317 (70.6 MiB)
phy0-ap0  Link encap:Ethernet  HWaddr <redacted>
          RX bytes:0 (0.0 B)  TX bytes:360 (360.0 B)
vpn1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          RX bytes:55973492 (53.3 MiB)  TX bytes:9182628 (8.7 MiB)
vpn2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
vpn3      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          RX bytes:566439628 (540.1 MiB)  TX bytes:6625853268 (6.1 GiB)

Can you describe your "concern" regarding TX without RX?

It's unclear.

Well, that could be my some what limited knowledge, I try my best to understand.

If vpn3 is connected and working both tx from vpn3 and wan should increase if something is transmitted, is that a correct assessment ?

So when the wan-cable is disconnected, both should cease increasing ?

What I saw happening today is when the wan-cable got disconnected that vpn3 tx increased immensely.

?

No, just RX.

No.

And no RX, correct?

Ahh, so something could be transmitting, but not able to deliver packets ?
So tx would still increase ?

Afaik, I'm not transmitting anything over vpn3

Yes, rxon vpn3 remains the same.

1 Like

You disconnected WAN, yes.

What's the "bug" concern?

There was nothing wrong with my configuration, I imported it on a x86 and it worked just fine. Go figure :blush:. So I think since rk3588s is still under development and partially supported under Linux 6.6 I'll just wait it out.

I wrote a hotplug.d script to correct the routes (that is not needed on x86) and everything works great now.

All and all, thanks guys for all technical and emotional support.

1 Like