What's new

Wireguard Session Manager - Discussion thread (CLOSED/EXPIRED Oct 2021 use http://www.snbforums.com/threads/session-manager-discussion-2nd-thread.75129/)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

been running my client now for a couple of un-eventful days, however the syslog looks strange:
Code:
Jun  7 20:59:00 RT-AC86U-D7D8 (wg_manager.sh): 6941 Clients [97m1[95m, Servers [97m0
Jun  7 20:59:01 RT-AC86U-D7D8 (wg_manager.sh): 6941 wg11:[97m transfer: 392.88 MiB received, 14.18 MiB sent        [97m0 Days, 02:28:50 from 2021-06-07 18:30:11 >>>>>>[0m
Jun  7 20:59:01 RT-AC86U-D7D8 (wg_manager.sh): 6941 wg11: period : 367.07 MiB received, 11.97 MiB sent (Rx=384900792;Tx=12555459)
this was also in post #218 but with negative data values. tried the same advice you gave to rebuild the SQL tables, but that did not work. any advice?
Code:
E:Option ==> diag sql traffic

        DEBUG: SQL '/opt/etc/wireguard.d/WireGuard.db'

        Table:traffic
Peer  Timestamp            RX         TX
wg11  2021-06-07 18:14:53  0          0
wg11  2021-06-07 18:16:50  34437      16056
wg11  2021-06-07 18:26:34  0          0
wg11  2021-06-07 18:27:44  5304       5816
wg11  2021-06-07 18:28:28  2786       3963
wg11  2021-06-07 18:30:11  0          0
wg11  2021-06-07 18:36:07  4194304    331540
wg11  2021-06-07 18:59:01  82659246   3212647
wg11  2021-06-07 19:59:01  27063747   2313349
wg11  2021-06-07 20:59:01  384900792  12555459

//Zeb
Are you complaining about the number/format of 'noise' messages being written to the Syslog every hour or the accuracy of the data records?
 
Are you complaining about the number/format of 'noise' messages being written to the Syslog every hour or the accuracy of the data records?
Well, as far as I can tell all numbers are correct. but I meant the "[97m" and "[95m" here and there seems to be unintentional.
Also some lines seems to be cut-off (since they are too long, maybee?).

//Zeb
 
Well, as far as I can tell all numbers are correct. but I meant the "[97m" and "[95m" here and there seems to be unintentional.
Also some lines seems to be cut-off (since they are too long, maybee?).

//Zeb

1. The '[97m1[95m' and '[97m0' are ANSI Control characters which, if viewed on a compatible terminal, (in this instance) will show colours (as used extensively in the wg_manager console interface).

e.g.

1623151571164.png

but I suppose I shouldn't assume that there is ANSI Control character support when writing to Syslog. :oops:

2. There is no truncation , the '>>>>>>' simply denotes the session is still running i.e. there is no end-of-session timestamp (yet) recorded.
(Probably only truly useful when displaying the inbound 'client' Peers rather than the outbound 'client' connections)
 
Last edited:
just added another vpn client with another country output, wg12. I figure I'll try without doing anything to the config file from my supplier. I couldnt believe it when it just connected.
further, I could'nt really wrap my head around how to make the DNS work with 3 different outbound connections (with unbound stuck in the middle, bound to one vpn client)... well, @Martineau was way ahead of me.

Using Yazfi to make one of the guest ssid: "SurfinUSA" using DNS to router. obviously custom config to allow wl1.1 to wg12 (guessing it is only a matter of time until Yazfi supports wireguard). the only custom config needed at wireguard_manager side was actually to masquarade this subnet as it was leaving wg12.

Thank you @Martineau for making this possible!

//Zeb

(ps. now I only need to figure out why I would ever need to surf-the-usa)
 
@Martineau
For some reason my log starts displaying negative values on one peer (wg11):
RT-AC86U-D7D8 (wg_manager.sh): 4954 Clients [97m2[95m, Servers [97m0
Jun 14 17:59:01 RT-AC86U-D7D8 (wg_manager.sh): 4954 wg11:[97m transfer: 14.72 GiB received, 1.16 GiB sent [97m2 days 22:27:07 from 2021-06-11 19:31:54 >>>>>>[0m
Jun 14 17:59:01 RT-AC86U-D7D8 (wg_manager.sh): 4954 wg11: period : -1598690429 Bytes received, 1.00 GiB sent (Rx=-1598690429;Tx=1078596730)
Jun 14 17:59:02 RT-AC86U-D7D8 (wg_manager.sh): 4954 wg12:[97m transfer: 389.56 MiB received, 181.78 MiB sent [97m2 days 19:57:10 from 2021-06-11 22:01:52 >>>>>>[0m
Jun 14 17:59:02 RT-AC86U-D7D8 (wg_manager.sh): 4954 wg12: period : 275.61 MiB received, 176.33 MiB sent (Rx=288998034;Tx=184895406)

So checking the SQL table:
wg12 2021-06-11 21:59:02 151099802 109733478
wg12 2021-06-11 22:01:17 10485 10486
wg12 2021-06-11 22:01:52 0 0
wg11 2021-06-11 22:59:01 785016421 87545610
wg12 2021-06-11 22:59:02 108034785 2002780
wg11 2021-06-11 23:59:01 686009878 145406034
wg12 2021-06-11 23:59:02 4068475 922747
wg11 2021-06-12 00:59:00 785016421 88300585
wg12 2021-06-12 00:59:02 108894617 2348810
wg11 2021-06-12 01:59:01 686009878 145741578
wg12 2021-06-12 01:59:02 283681752 182483682
wg11 2021-06-12 02:59:01 785016421 88992645
wg12 2021-06-12 02:59:02 109450362 2684354
wg11 2021-06-12 03:59:01 686009878 146171495
wg12 2021-06-12 03:59:01 284468184 182829712
wg11 2021-06-12 04:59:01 785016421 89422561
wg12 2021-06-12 04:59:02 109953678 2862612
wg11 2021-06-12 05:59:01 686009878 146737726
wg12 2021-06-12 05:59:02 286250764 183721001
wg11 2021-06-12 06:59:01 795753839 89841991
wg12 2021-06-12 06:59:02 110855453 3701473
wg11 2021-06-12 07:59:01 686009878 147178128
wg12 2021-06-12 07:59:01 286628251 183888773
wg11 2021-06-12 08:59:01 795753839 90544537
wg12 2021-06-12 08:59:02 112365403 3848274
wg11 2021-06-12 09:59:01 1598690429 166943786
wg12 2021-06-12 09:59:02 288861718 184622776
wg12 2021-06-12 10:59:02 112375888 3858760
wg12 2021-06-12 11:59:01 288861718 184633262
wg12 2021-06-12 12:59:02 112375888 3869246
wg12 2021-06-12 13:59:01 288872204 184633262
wg12 2021-06-12 14:59:02 112375888 3879731
wg12 2021-06-12 15:59:02 288872204 184643748
wg12 2021-06-12 16:59:02 112375888 3890217
wg12 2021-06-12 17:59:02 288882690 184654234
wg12 2021-06-12 18:59:01 115532102 4739563
wg12 2021-06-12 19:59:02 288882690 184664720
wg12 2021-06-12 20:59:01 119485233 5505023
wg12 2021-06-12 21:59:02 288882690 184675206
wg12 2021-06-12 22:59:01 119485233 5515509
wg12 2021-06-12 23:59:02 288893176 184685692
wg12 2021-06-13 00:59:02 119485233 5525994
wg12 2021-06-13 01:59:02 288893176 184696178
wg12 2021-06-13 02:59:02 119485233 5536480
wg12 2021-06-13 03:59:02 288903662 184706664
wg12 2021-06-13 04:59:01 119485233 5546965
wg12 2021-06-13 05:59:01 288903662 184717150
wg12 2021-06-13 06:59:01 119485233 5557451
wg12 2021-06-13 07:59:01 288914147 184727636
wg12 2021-06-13 08:59:01 119485233 5557451
wg12 2021-06-13 09:59:01 288914147 184738121
wg12 2021-06-13 10:59:01 119485233 5567937
wg12 2021-06-13 11:59:01 288924633 184748607
wg12 2021-06-13 12:59:02 119485233 5578423
wg12 2021-06-13 13:59:01 288924633 184759093
wg12 2021-06-13 14:59:01 119485233 5588908
wg12 2021-06-13 15:59:01 288935119 184769579
wg12 2021-06-13 16:59:01 119485233 5599394
wg12 2021-06-13 17:59:02 288935119 184780065
wg12 2021-06-13 18:59:02 119485233 5609879
wg12 2021-06-13 19:59:02 288945605 184790551
wg12 2021-06-13 20:59:01 119485233 5620365
wg12 2021-06-13 21:59:02 288945605 184801037
wg12 2021-06-13 22:59:02 119485233 5620365
wg12 2021-06-13 23:59:02 288956091 184811522
wg12 2021-06-14 00:59:02 119485233 5630851
wg12 2021-06-14 01:59:02 288956091 184822008
wg12 2021-06-14 02:59:02 119485233 5641337
wg12 2021-06-14 03:59:02 288966576 184832493
wg12 2021-06-14 04:59:02 119485233 5651823
wg12 2021-06-14 05:59:02 288966576 184842979
wg12 2021-06-14 06:59:02 119485233 5662309
wg12 2021-06-14 07:59:02 288977062 184853464
wg12 2021-06-14 08:59:02 119485233 5672795
wg12 2021-06-14 09:59:02 288977062 184863950
wg12 2021-06-14 10:59:02 119485233 5683281
wg12 2021-06-14 11:59:02 288987548 184874435
wg12 2021-06-14 12:59:02 119485233 5693767
wg12 2021-06-14 13:59:02 288987548 184874435
wg12 2021-06-14 14:59:02 119485233 5704253
wg12 2021-06-14 15:59:02 288998034 184884921
wg12 2021-06-14 16:59:02 119485233 5714739
wg12 2021-06-14 17:59:02 288998034 184895406

Looks like wg11 stopped generating stat values 12/6 at 10am.

I have looked at the database but can't make any sense of the time codes so I'm lost.

The last thing I did (which might have been 12/6 am:ish but can't remember) was to update my wg12.conf with persistent keepalive and I imported it without deleting the old peer first (I stopped it though). Could this have been messing up the entries for wg11 in such way that cause this?

I'm quite sure this will return to normal when I reset the traffic and session tables.

//Zeb

Edit: according to the sessions recorded in the database there were no actions during that date:
E:Option ==> diag sql session DEBUG: SQL '/opt/etc/wireguard.d/WireGuard.db'
Table:session
Peer State Timestamp
wg11 Start 2021-06-07 18:14:53
wg11 Start 2021-06-07 18:26:34
wg11 End 2021-06-07 18:28:28
wg11 Start 2021-06-07 18:30:11
wg11 End 2021-06-07 22:38:03
wg11 Start 2021-06-07 22:38:04
wg11 End 2021-06-07 22:51:14
wg11 Start 2021-06-07 22:51:15
wg11 Start 2021-06-08 06:12:36
wg11 End 2021-06-08 21:02:28
wg11 Start 2021-06-08 21:04:08
wg12 Start 2021-06-09 18:53:11
wg11 End 2021-06-09 20:52:03
wg12 End 2021-06-09 20:52:05
wg11 Start 2021-06-09 20:52:06
wg12 Start 2021-06-09 20:52:08
wg11 End 2021-06-09 21:05:04
wg12 End 2021-06-09 21:05:05
wg11 Start 2021-06-09 21:05:07
wg12 Start 2021-06-09 21:05:08
wg11 End 2021-06-09 21:05:47
wg12 End 2021-06-09 21:05:49
wg11 Start 2021-06-09 21:05:49
wg12 Start 2021-06-09 21:05:50
wg11 End 2021-06-09 21:30:51
wg12 End 2021-06-09 21:30:54
wg11 Start 2021-06-09 21:30:55
wg12 Start 2021-06-09 21:30:57
wg11 End 2021-06-09 22:14:58
wg11 Start 2021-06-09 22:14:58
wg12 End 2021-06-09 22:19:50
wg11 End 2021-06-09 22:19:51
wg11 Start 2021-06-09 22:19:58
wg12 Start 2021-06-09 22:19:59
wg11 End 2021-06-09 22:22:21
wg12 End 2021-06-09 22:22:22
wg11 Start 2021-06-09 22:24:06
wg12 Start 2021-06-09 22:24:08
wg11 End 2021-06-09 22:41:40
wg12 End 2021-06-09 22:41:41
wg11 Start 2021-06-09 22:43:23
wg12 Start 2021-06-09 22:43:25
wg12 End 2021-06-10 19:29:01
wg12 Start 2021-06-10 19:29:01
wg12 End 2021-06-11 19:31:43
wg12 Start 2021-06-11 19:31:44
wg11 End 2021-06-11 19:31:54
wg11 Start 2021-06-11 19:31:54
wg12 End 2021-06-11 21:43:19
wg12 Start 2021-06-11 21:43:34
wg12 End 2021-06-11 21:48:52
wg12 Start 2021-06-11 21:50:17
wg12 End 2021-06-11 22:01:17
wg12 Start 2021-06-11 22:01:52

WireGuard ACTIVE Peer Status: Clients 2, Servers 0

I will try to reset the tables in a couple of hours.

Edit2 (updated): attached last entries in database. Seems to be only wg12 entries after June 12.
 

Attachments

  • Screenshot_20210614-220558_Sqlite Master.jpg
    Screenshot_20210614-220558_Sqlite Master.jpg
    57.4 KB · Views: 82
Last edited:
Digged up the log file from June 12th and the values are indeed turning negative at the time for the entries stop coming:
Jun 12 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 16387 Clients [97m2[95m, Servers [97m0
Jun 12 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 16387 wg11:[97m transfer: 2.23 GiB received, 245.56 MiB sent [97m0 Days, 14:27:07 from 2021-06-11 19:31:54 >>>>>>[0m
Jun 12 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 16387 wg11: period : 1.49 GiB received, 159.21 MiB sent (Rx=1598690429;Tx=166943786)
Jun 12 09:59:02 RT-AC86U-D7D8 (wg_manager.sh): 16387 wg12:[97m transfer: 382.64 MiB received, 179.74 MiB sent [97m0 Days, 11:57:10 from 2021-06-11 22:01:52 >>>>>>[0m
Jun 12 09:59:02 RT-AC86U-D7D8 (wg_manager.sh): 16387 wg12: period : 275.48 MiB received, 176.07 MiB sent (Rx=288861718;Tx=184622776)
Jun 12 10:59:01 RT-AC86U-D7D8 (wg_manager.sh): 27827 Clients [97m2[95m, Servers [97m0
Jun 12 10:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27827 wg11:[97m transfer: 3.68 GiB received, 292.04 MiB sent [97m0 Days, 15:27:08 from 2021-06-11 19:31:54 >>>>>>[0m
Jun 12 10:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27827 wg11: period : -1942287813 Bytes received, 132.83 MiB sent (Rx=-1942287813;Tx=139282349)
Jun 12 10:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27827 wg12:[97m transfer: 382.65 MiB received, 179.75 MiB sent [97m0 Days, 12:57:10 from 2021-06-11 22:01:52 >>>>>>[0m
Jun 12 10:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27827 wg12: period : 107.17 MiB received, 3.68 MiB sent (Rx=112375888;Tx=3858760)
Jun 12 11:59:00 RT-AC86U-D7D8 (wg_manager.sh): 28791 Clients [97m2[95m, Servers [97m0
Jun 12 11:59:00 RT-AC86U-D7D8 (wg_manager.sh): 28791 wg11:[97m transfer: 3.97 GiB received, 307.12 MiB sent [97m0 Days, 16:27:06 from 2021-06-11 19:31:54 >>>>>>[0m
Jun 12 11:59:00 RT-AC86U-D7D8 (wg_manager.sh): 28791 wg11: period : -1630902684 Bytes received, 147.91 MiB sent (Rx=-1630902684;Tx=155094875)
Jun 12 11:59:01 RT-AC86U-D7D8 (wg_manager.sh): 28791 wg12:[97m transfer: 382.65 MiB received, 179.76 MiB sent [97m0 Days, 13:57:09 from 2021-06-11 22:01:52 >>>>>>[0m
Jun 12 11:59:01 RT-AC86U-D7D8 (wg_manager.sh): 28791 wg12: period : 275.48 MiB received, 176.08 MiB sent (Rx=288861718;Tx=184633262)

//Zeb

Edit: I did a reset according to post #219 which made all numbers ok again:
Jun 15 06:02:24 RT-AC86U-D7D8 (wg_manager.sh): 9674 Clients [97m2[95m, Servers [97m0
Jun 15 06:02:24 RT-AC86U-D7D8 (wg_manager.sh): 9674 wg11:[97m transfer: 26.37 KiB received, 19.18 KiB sent [97m0 Days, 00:02:15 from >>>>>>[0m
Jun 15 06:02:24 RT-AC86U-D7D8 (wg_manager.sh): 9674 wg11: period : 26.37 KiB received, 19.18 KiB sent (Rx=27003;Tx=19640)
Jun 15 06:02:25 RT-AC86U-D7D8 (wg_manager.sh): 9674 wg12:[97m transfer: 184 B received, 520 B sent [97m0 Days, 00:02:15 from >>>>>>[0m
Jun 15 06:02:25 RT-AC86U-D7D8 (wg_manager.sh): 9674 wg12: period : 184 Bytes received, 520 Bytes sent (Rx=184;Tx=520)

I still have a copy of the old database if you need for debugging.
 
Last edited:
Today, same thing happened again:
Jun 15 08:59:00 RT-AC86U-D7D8 (wg_manager.sh): 15473 Clients [97m2[95m, Servers [97m
Jun 15 08:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg11:[97m transfer: 1009.72 MiB received, 36.63 MiB sent [97m0 Days, 02:58:52 from >>>>>>[0m
Jun 15 08:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg11: period : 839.84 MiB received, 30.97 MiB sent (Rx=880640523;Tx=32475730)
Jun 15 08:59:02 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg12:[97m transfer: 7.73 KiB received, 28.49 KiB sent [97m0 Days, 02:58:52 from >>>>>>[0m
Jun 15 08:59:02 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg12: period : 5.04 KiB received, 18.56 KiB sent (Rx=5162;Tx=19008)
Jun 15 09:59:00 RT-AC86U-D7D8 (wg_manager.sh): 15656 Clients [97m2[95m, Servers [97m0
Jun 15 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg11:[97m transfer: 5.06 GiB received, 126.89 MiB sent [97m0 Days, 03:58:52 from >>>>>>[0m
Jun 15 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg11: period : -880640523 Bytes received, 95.92 MiB sent (Rx=-880640523;Tx=100578079)
Jun 15 09:59:03 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg12:[97m transfer: 10.33 KiB received, 38.20 KiB sent [97m0 Days, 03:58:53 from >>>>>>[0m
Jun 15 09:59:04 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg12: period : 5.29 KiB received, 19.64 KiB sent (Rx=5416
Looks like someone hit the internet hard this morning (scools out for summer)

Could it be the rx value growing too large? This coincides with rx growing larger than datatype INT.

//Zeb
 
Today, same thing happened again:
Jun 15 08:59:00 RT-AC86U-D7D8 (wg_manager.sh): 15473 Clients [97m2[95m, Servers [97m
Jun 15 08:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg11:[97m transfer: 1009.72 MiB received, 36.63 MiB sent [97m0 Days, 02:58:52 from >>>>>>[0m
Jun 15 08:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg11: period : 839.84 MiB received, 30.97 MiB sent (Rx=880640523;Tx=32475730)
Jun 15 08:59:02 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg12:[97m transfer: 7.73 KiB received, 28.49 KiB sent [97m0 Days, 02:58:52 from >>>>>>[0m
Jun 15 08:59:02 RT-AC86U-D7D8 (wg_manager.sh): 15473 wg12: period : 5.04 KiB received, 18.56 KiB sent (Rx=5162;Tx=19008)
Jun 15 09:59:00 RT-AC86U-D7D8 (wg_manager.sh): 15656 Clients [97m2[95m, Servers [97m0
Jun 15 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg11:[97m transfer: 5.06 GiB received, 126.89 MiB sent [97m0 Days, 03:58:52 from >>>>>>[0m
Jun 15 09:59:01 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg11: period : -880640523 Bytes received, 95.92 MiB sent (Rx=-880640523;Tx=100578079)
Jun 15 09:59:03 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg12:[97m transfer: 10.33 KiB received, 38.20 KiB sent [97m0 Days, 03:58:53 from >>>>>>[0m
Jun 15 09:59:04 RT-AC86U-D7D8 (wg_manager.sh): 15656 wg12: period : 5.29 KiB received, 19.64 KiB sent (Rx=5416
Looks like someone hit the internet hard this morning (scools out for summer)

Could it be the rx value growing too large? This coincides with rx growing larger than datatype INT.

//Zeb
Every hour the stats are generated (or you can manually enter the generatestats menu command) and written to the database.

e.g.
Code:
E:Option ==> diag sql traffic

    DEBUG: SQL '/opt/etc/wireguard.d/WireGuard.db'

    Table:traffic
Peer    Timestamp            RX          TX
<snip>
wg11    2021-06-15 14:08:53  0           0
wg11    2021-06-16 07:53:22  605888184   53896806
wg11    2021-06-16 07:59:01  1247806     1216349

Each time you start a 'client' Peer, a record containing zeros is written.

I know from personal experience (circa 2019) that large numbers can cause arithmetic errors and was fixed in the published script.

e.g.
Code:
 echo $((1191071409 + 2037987240))
-1065908647
fixed by using
Code:
echo $(expr "1191071409" + "2037987240")
3229058649

I have uploaded a modified wg_manager v4.11b6 to use the slower external utility expr and (temporarily) modified wg_client to now also explicitly write the zero traffic record to the database when the 'client' Peer is terminated.

Please try the patched scripts.
Code:
e  = Exit Script [?]

E:Option ==> uf dev

If the problem still persists then you can try manually running the generatestats command after tuning on debugging using the debug command.
 
Last edited:
Please try the patched scripts.
Code:
e  = Exit Script [?]

E:Option ==> uf dev

If the problem still persists then you can try manually running the generatestats command after tuning on debugging using the debug cocommand.
Thanks, Updated... looks ok so far but not so high numbers yet. Will probably pop up during the day.

//Zeb

Edit: did acouple of downloads to get the numbers up and still looking good:
27680 wg11:[97m transfer: 3.10 GiB received, 188.04 MiB sent [97m0 Days, 13:58:34 from >>>>>>[0m
Jun 16 12:59:01 RT-AC86U-D7D8 (wg_manager.sh): 27680 wg11: period : 2.51 GiB received, 111.04 MiB sent (Rx=2699767061;Tx=116432763)
Jun 16 12:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27680 wg12:[97m transfer: 36.20 KiB received, 133.38 KiB sent [97m0 Days, 13:58:34 from >>>>>>[0m
Jun 16 12:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27680 wg12: period : 19.23 KiB received, 70.88 KiB sent (Rx=19688;Tx=72581)
Jun 16 13:59:00 RT-AC86U-D7D8 (wg_manager.sh): 30962 Clients [97m2[95m, Servers [97m0
Jun 16 13:59:01 RT-AC86U-D7D8 (wg_manager.sh): 30962 wg11:[97m transfer: 8.95 GiB received, 393.23 MiB sent [97m0 Days, 14:58:34 from >>>>>>[0m
Jun 16 13:59:01 RT-AC86U-D7D8 (wg_manager.sh): 30962 wg11: period : 6.44 GiB received, 282.19 MiB sent (Rx=6910222264;Tx=295898777)
Jun 16 13:59:02 RT-AC86U-D7D8 (wg_manager.sh): 30962 wg12:[97m transfer: 38.80 KiB received, 142.98 KiB sent [97m0 Days, 14:58:34 from >>>>>>[0m
Jun 16 13:59:02 RT-AC86U-D7D8 (wg_manager.sh): 30962 wg12: period : 19.57 KiB received, 72.10 KiB sent (Rx=20043;Tx=73831)

Ill keep my eye on it the next couple of days.
 
Last edited:
Well, I set my dns in the wg11.conf to router lan ip (192.168.1.1). So unbound and diversion works as normal. This works for me...

//Zeb
Hi
If I set 192.168.1.1 as my dns in wg11.conf, I cannot resolve any website.
Do you have any suggestion?

Edit:
After upgrading with "uf=dev", I can resolve domains again.
 
Last edited:
Activating wireguard seems to activate some sort of QoS or something on the router. When I install it on my AX86U and do a speedtest, my speed seems to cap at 450 mbps down (I have 1.2 Gbps), and one core gets pegged at 100%. Is there something I'm missing in settings?
 
Activating wireguard seems to activate some sort of QoS or something on the router. When I install it on my AX86U and do a speedtest, my speed seems to cap at 450 mbps down (I have 1.2 Gbps), and one core gets pegged at 100%. Is there something I'm missing in settings?
and wg_manager v4.11beta available on the Github dev branch includes the patch
 
and wg_manager v4.11beta available on the Github dev branch includes the patch

Huh, interesting.

Reading on Flow Cache in the forums, seems like it's a black box that replaced CTF with a solution that resolves STP issues.

Wonder if disabling this increases system latency at all or if this is just another one of Broadcomm Proprietary Technologies that doesn't improve anything on modern hardware with enough cache and DRAM speed.

I'll reinstall using the beta. Thanks!
 
Okay still hitting the limit...

I'm sorry, I should have added more detail:

Using a machine from the LOCAL network, I run a speedtest on speedtest.net and then it hits a CPU core hard at 100% and peaks at 300-450 mbps. And I was on the latest dev branch.

Out of curiousity, I tried 'fc enable'. Behavior resumed as normal, hitting the peak speeds of 1.2 Gbps on the local network.

I also tested it from my 5G mobile connection using WireGuard to connect to my router and WAN. FC enable caused the slowdowns mentioned with all cores on the router being hit hard and causing WebUI and SSH lag. Disabling removes that slowness but resumes local machines being speed limited.

Few other notes:
Using 802.3ad WAN Aggregation to my modem for that 1.2 Gbps.
No QoS enabled.
Local desktop hooked to 2.5 Gbps port on AX86U.

Dunno if FC just does not like a new virtual interface? Or if my setup is unique? Don't know, but I can test further if needed.


Disregard, unsure what is happening as local is now working fine. Couldn't say what's the problem yet, but probably not wireguard. A reboot has fixed it for the moment.
 
Last edited:
Hi,

I'm thinking of using this and have some general questions about how it works that I hope someone can help with:

1. I'd like to set up a Wireguard VPN so I can connect to home remotely instead of using OpenVPN. It sound like this is possible?
2. I'd like to set another Wireguard connection to Mullvad and assign that to a wifi network so all connections to the network are going through it. I'm using YazFi at the moment. Is this possible?
3. What happens if I upgrade ASUS Wrt and the kernel changes, the modules need to be re-compiled / reinstalled before this will work?

Thanks in advance!
 
I am able to get local wg21 run so I can dial-in to my home network via wireguard. Next I try to setup wireguard client to NordVPN. The WireguardVPN.conf was quite empty than some of the config I see here, so I copy a bit over. I can get wg11 connected to NordVPN, I need help on how to setup the rules. Once wg11 connected I lost Internet connection. Internet is still down after I stop wg11. Internet only back after I stop wg21 as well. Then I can start wg21 again and Internet is not affected. Here is the diag output.

Code:
E:Option ==> diag

                 WireGuard VPN Peer Status
interface: wg21
  public key: ichMaZLYJmwFSrJdu682D72TPaCg32zEFxtUrb3/enk=
  private key: (hidden)
  listening port: 51820

peer: CrCkxoXyDVgk9jMQmUDpIc0Wc7ACZx06oGPY54sIYhw=
  endpoint: <my mobile public ip>:8323
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 47 seconds ago
  transfer: 135.18 KiB received, 487.40 KiB sent

interface: wg11
  public key: TMsFXcl2JHJnJilh26OdicticNiriEOFRD3TqglVOVU=
  private key: (hidden)
  listening port: 54863

peer: l1sRg+3hrtHWrEKxvZ9zrzQ5G+ewLIowIAc9HTWyDlM=
  endpoint: 202.87.221.198:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 45 seconds ago
  transfer: 145.93 KiB received, 45.54 KiB sent
  persistent keepalive: every 25 seconds

        DEBUG: Routing info MTU etc.

34: wg21: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.50.1.1/24 scope global wg21
       valid_lft forever preferred_lft forever
35: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.5.0.2/32 scope global wg11
       valid_lft forever preferred_lft forever

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         128.0.0.0       U         0 0          0 wg11
10.50.1.0       0.0.0.0         255.255.255.0   U         0 0          0 wg21
128.0.0.0       0.0.0.0         128.0.0.0       U         0 0          0 wg11

        DEBUG: RPDB rules

0:      from all lookup local
9810:   from all fwmark 0xd2 lookup 210
9990:   from all fwmark 0x8000/0x8000 lookup main
9993:   from all fwmark 0x4000/0x4000 lookup ovpnc3
10501:  from 10.16.0.0/24 lookup ovpnc3
10502:  from 192.168.1.11 lookup ovpnc3
10503:  from 192.168.1.21 lookup ovpnc3
10504:  from 192.168.1.2 lookup ovpnc3
32766:  from all lookup main
32767:  from all lookup default

        DEBUG: Routing Table 121 (wg11) # my38.nordvpn.com

0.0.0.0/1 dev wg11 scope link
128.0.0.0/1 dev wg11 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

        DEBUG: Routing Table main

0.0.0.0/1 dev wg11 scope link
10.50.1.0/24 dev wg21 proto kernel scope link src 10.50.1.1
128.0.0.0/1 dev wg11 scope link

        DEBUG: UDP sockets.

netstat: showing only processes with your user ID
udp        0      0 0.0.0.0:54863           0.0.0.0:*                           -
udp        0      0 0.0.0.0:51820           0.0.0.0:*                           -
udp        0      0 :::54863                :::*                                -
udp        0      0 :::51820                :::*                                -

        DEBUG: Firewall rules


        DEBUG: -t filter

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      572  387K ACCEPT     all  --  *      wg21    0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */
2      485 69163 ACCEPT     all  --  wg21   *       0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      313 36059 ACCEPT     all  --  wg21   *       0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */
2      810  161K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:51820 /* WireGuard 'server' */

Chain OUTPUT (policy ACCEPT 363K packets, 226M bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      273 80148 ACCEPT     all  --  *      wg21    0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */

        DEBUG: -t nat

Chain PREROUTING (policy ACCEPT 28 packets, 3637 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        8   561 WGDNS1     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* WireGuard 'client1 DNS' */
2        0     0 WGDNS1     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 /* WireGuard 'client1 DNS' */
3        1   176 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:51820 /* WireGuard 'server' */

Chain POSTROUTING (policy ACCEPT 19 packets, 1629 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        4   597 MASQUERADE  all  --  *      wg11    192.168.1.0/24       0.0.0.0/0            /* WireGuard 'client' */

Chain WGDNS1 (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        8   561 DNAT       all  --  *      *       192.168.1.0/24       0.0.0.0/0            /* WireGuard 'client1 DNS' */ to:202.87.221.198

        DEBUG: -t mangle

Chain FORWARD (policy ACCEPT 237 packets, 25234 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1       22  3631 MARK       all  --  *      wg11    0.0.0.0/0            0.0.0.0/0            /* WireGuard 'client' */ MARK xset 0x1/0x7
2        2   120 TCPMSS     tcp  --  wg11   *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
3        2   120 TCPMSS     tcp  --  *      wg11    0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
4      572  387K MARK       all  --  *      wg21    0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */ MARK xset 0x1/0x7
5       19  1252 TCPMSS     tcp  --  wg21   *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU
6       19  1140 TCPMSS     tcp  --  *      wg21    0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU

Chain PREROUTING (policy ACCEPT 911 packets, 405K bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      138  143K MARK       all  --  wg11   *       0.0.0.0/0            0.0.0.0/0            /* WireGuard 'client' */ MARK xset 0x1/0x7
2      799  105K MARK       all  --  wg21   *       0.0.0.0/0            0.0.0.0/0            /* WireGuard 'server' */ MARK xset 0x1/0x7


Use command 'diag sql [ table_name ]' to see the SQL data (might be many lines!)

       Valid SQL Database tables: clients  devices  fwmark   ipset    policy   servers  session  traffic

             e.g. diag sql traffic will show the traffic stats SQL table


        WireGuard ACTIVE Peer Status: Clients 1, Servers 1



1  = Update Wireguard modules                                           7  = Display QR code for a Peer {device} e.g. iPhone
2  = Remove WireGuard/wg_manager                                        8  = Peer management [ "list" | "category" | "new" ] | [ {Peer | category} [ del | show | add [{"auto="[y|n|p]}] ]
                                                                        9  = Create Key-pair for Peer {Device} e.g. Nokia6310i (creates Nokia6310i.conf etc.)
3  = List ACTIVE Peers Summary [Peer...] [full]                         10 = IPSet management [ "list" ] | [ "upd" { ipset [ "fwmark" {fwmark} ] | [ "enable" {"y"|"n"}] | [ "dstsrc"] ] } ]
4  = Start   [ [Peer [nopolicy]...] | category ] e.g. start clients
5  = Stop    [ [Peer... ] | category ] e.g. stop clients
6  = Restart [ [Peer... ] | category ] e.g. restart servers

?  = About Configuration
v  = View ('/jffs/addons/wireguard/WireguardVPN.conf')

e  = Exit Script [?]

E:Option ==>
 
Hi,

I'm thinking of using this and have some general questions about how it works that I hope someone can help with:

1. I'd like to set up a Wireguard VPN so I can connect to home remotely instead of using OpenVPN. It sound like this is possible?
2. I'd like to set another Wireguard connection to Mullvad and assign that to a wifi network so all connections to the network are going through it. I'm using YazFi at the moment. Is this possible?
3. What happens if I upgrade ASUS Wrt and the kernel changes, the modules need to be re-compiled / reinstalled before this will work?

Thanks in advance!
1) as long as you have a Public ip adress on your WAN (not behind a cgnat) it should work just fine.
2) absolutely. I have set up yazfi and wgm so ordinary wifi goes out wg11, guest wifi1 goes out wan and guest wifi2 goes out wg12. Some custom config needed on yazfi and wgm side though. I could share what I have if needed.
3) I wouldn't think the kernel ever changes... but I could be wrong...

//Zeb
 
1) as long as you have a Public ip adress on your WAN (not behind a cgnat) it should work just fine.
2) absolutely. I have set up yazfi and wgm so ordinary wifi goes out wg11, guest wifi1 goes out wan and guest wifi2 goes out wg12. Some custom config needed on yazfi and wgm side though. I could share what I have if needed.
3) I wouldn't think the kernel ever changes... but I could be wrong...

//Zeb

Thank you for replying,

1. Yes, I have a static IP.
2. Could you please give some pointers on how to do this?
3. OK, got it, I can see there’s an option to rebuild the modules anyhow.
 
2. Could you please give some pointers on how to do this
For Yazfi you could follow this post to allow guest subnet to access wireguard interfaces:
https://www.snbforums.com/threads/e...-hnd-platform-4-1-x-kernels.46164/post-664947

Just replace the interfaces wlX.Y and wg0 with your interfaces.
disregard the "masquarading to /16" part since we will handle that below:

For wireguard manager:
Create a custom script for your peer (assuming wg11 below):
Code:
nano /jffs/addons/wireguard/Scripts/wg11-up.sh
Populate the file with (assuming guest wifi subnet 192.168.2.xxx to wg11):
Code:
#!/bin/sh

#add custom config here

iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o wg11 -j MASQUERADE

Save the file.
Make it executable:
Code:
chmod +x /jffs/addons/wireguard/Scripts/wg11-up.sh

Then redo same thing for another file (to delete rules when peer is stopped:
Code:
nano /jffs/addons/wireguard/Scripts/wg11-down.sh

Code:
#!/bin/sh

#add custom config here

iptables -t nat -D POSTROUTING -s 192.168.2.0/24 -o wg11 -j MASQUERADE

Save the file.
Make it executable.

Then the rest of the config in wgm
peer in policy mode,
rule add FROM 192.168.2.0/24 to VPN.
rule add TO 192.168.0.0/16 to WAN

//Zeb
 
Last edited:
I try to setup wireguard client to NordVPN. The WireguardVPN.conf was quite empty than some of the config I see here, so I copy a bit over
'WireguardVPN.conf' does not need to be modified for Peer configurations - all parameters are now held in the SQL database.

You simply need to use the import command using the 'client' Peer configuration provided by NordVPN as-is.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top