What's new

Wireguard Session Manager - Discussion (2nd) thread

  • 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!

Hey! Does the output from diag cmd gets saved as a file?
The SSH client is the best method to record the info to a file, ....although you can cut'n'paste etc. but that can be tedious.. although you can copy either the 'screen' or 'session'

e.g. I use XShell6 (it's free for home use) so you start the logging.....

1634647630407.png

then when you have issued the commands you wish to capture, simply 'stop' the log, and it will ask you where to save the log, then you can click on 'Open Log Folder'

It's not perfect (for retaining menu/table column formatting etc.) but when performing a lengthy verbose debugging session it saves me a lot of time!
 
Last edited:
@ZebMcKayhan

I have implemented your suggestion to auto-import Vendor supplied .conf files into the next available WireGuard designated interface 'slot' on the router, and relegated the use of import xxxxxx[.conf] name= requests for advanced users.

e.g. I already have 4 WireGuard 'client' peers configured (interfaces wg11 thru' wg14), and requested the import of Mullvad's file

'/opt/etc/wireguard.d/mlvd-us53.conf'

Code:
E:Option ==> import mlvd-us53

    [✔] Config mlvd-us53 import as wg15 success

This should eliminate all future end-user confusion/frustration ( as reported by new user @Stingray123 ) as the very first import request should now by default create wg11 (rather than mlvd-us53 as it would have done previously as allowed per the official wg=quick documentation)

Ah, that gives me some answers for the unexpected results I was seeing when trying to import before. I think your new import change will be helpful for the less experienced like me.

Thank you Martineau and ZebMcKayhan for all your efforts going into Session Manager!
 
@Martineau, I'm looking for some direction here. During the last updates to dev and main branches the RPDB build principles have changed, I believe.
I had (and have) wgm working well (and very well) over the last several months. I built the routing tables based on your early view at http://www.snbforums.com/threads/se...discussion-2nd-thread-75129.70787/post-695607.

It all looked like that:
Code:
asmin@RT-AX86U:/tmp/mnt/asus/conf# ip rule
0:      from all lookup local
220:    from all lookup 220
9810:   from all fwmark 0xd2 lookup 210
9890:   from all fwmark 0x8000/0x8000 lookup main
9892:   from all fwmark 0x7010/0x7010 lookup 124
9893:   from all fwmark 0x4010/0x4010 lookup 123
9894:   from all fwmark 0x2010/0x2010 lookup 122
9895:   from all fwmark 0x1010/0x1010 lookup 121
9911:   from 192.168.1.246 lookup 121
9911:   from 192.168.1.230 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x1000/0x1000 lookup ovpnc1
10210:  from 192.168.1.237 lookup ovpnc1
10211:  from 192.168.1.253 lookup ovpnc1
10212:  from 192.168.1.238 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

I noted that you recently removed the requirement to have at least one client per interface in order to be able to route IPSets, so I removed the dummies and it all looked cleaner.

Now, late in the weekend with the last update I think I've seen the routing re-arranged as follows:
Code:
asmin@RT-AX86U:/tmp/mnt/asus/conf# ip rule
0:      from all lookup local
220:    from all lookup 220
9810:   from all fwmark 0xd2 lookup 210
9911:   from 192.168.1.246 lookup 121
9911:   from 192.168.1.230 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x1010/0x1010 lookup 121
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9992:   from all fwmark 0x2010/0x2010 lookup 122
9993:   from all fwmark 0x4010/0x4010 lookup 123
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9994:   from all fwmark 0x7010/0x7010 lookup 124
9995:   from all fwmark 0x1000/0x1000 lookup ovpnc1
10210:  from 192.168.1.237 lookup ovpnc1
10211:  from 192.168.1.253 lookup ovpnc1
10212:  from 192.168.1.238 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

It all works now (there is little to nothing one can't do with the -route-up/down and -up/down scripts.)
I can see that not having 2 WAN routes to the main table makes sense.
The question remains what was the leading factor to the change? And why the change from the earlier priority definition for routing clients running on different protocols?
 
@Martineau, I'm looking for some direction here. During the last updates to dev and main branches the RPDB build principles have changed, I believe.
I had (and have) wgm working well (and very well) over the last several months. I built the routing tables based on your early view at http://www.snbforums.com/threads/se...discussion-2nd-thread-75129.70787/post-695607.

It all looked like that:
Code:
asmin@RT-AX86U:/tmp/mnt/asus/conf# ip rule
0:      from all lookup local
220:    from all lookup 220
9810:   from all fwmark 0xd2 lookup 210
9890:   from all fwmark 0x8000/0x8000 lookup main
9892:   from all fwmark 0x7010/0x7010 lookup 124
9893:   from all fwmark 0x4010/0x4010 lookup 123
9894:   from all fwmark 0x2010/0x2010 lookup 122
9895:   from all fwmark 0x1010/0x1010 lookup 121
9911:   from 192.168.1.246 lookup 121
9911:   from 192.168.1.230 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x1000/0x1000 lookup ovpnc1
10210:  from 192.168.1.237 lookup ovpnc1
10211:  from 192.168.1.253 lookup ovpnc1
10212:  from 192.168.1.238 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

I noted that you recently removed the requirement to have at least one client per interface in order to be able to route IPSets, so I removed the dummies and it all looked cleaner.

Now, late in the weekend with the last update I think I've seen the routing re-arranged as follows:
Code:
asmin@RT-AX86U:/tmp/mnt/asus/conf# ip rule
0:      from all lookup local
220:    from all lookup 220
9810:   from all fwmark 0xd2 lookup 210
9911:   from 192.168.1.246 lookup 121
9911:   from 192.168.1.230 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x1010/0x1010 lookup 121
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9992:   from all fwmark 0x2010/0x2010 lookup 122
9993:   from all fwmark 0x4010/0x4010 lookup 123
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9994:   from all fwmark 0x7010/0x7010 lookup 124
9995:   from all fwmark 0x1000/0x1000 lookup ovpnc1
10210:  from 192.168.1.237 lookup ovpnc1
10211:  from 192.168.1.253 lookup ovpnc1
10212:  from 192.168.1.238 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

It all works now (there is little to nothing one can't do with the -route-up/down and -up/down scripts.)
I can see that not having 2 WAN routes to the main table makes sense.
The question remains what was the leading factor to the change? And why the change from the earlier priority definition for routing clients running on different protocols?
Initially with wireguard_manager, I didn't want to have different fwmarks for both my original OpenVPN and WireGuard design.

There are users that apparently use both OpenVPN and WireGuard 'clients' concurrently for daily use, but ideally, I would hope that after the initial feasibility testing of WireGuard 'clients' they would deem it acceptable to agree that WireGuard (when configured and UP) should take priority - should the decision to drop OpenVPN clients entirely wasn't chosen i.e. use one or the other.

As you have deliberately chosen/assigned custom WireGuard fwmarks, can you be 100% sure that the lower bit in your wg11 fwmark 0x1010 isn't used by the ASUS/Broadcom?

When I chose 0x1000 for ovpnc1, at the time this was deemed to be a good choice given some of the lower 24 bits were definitely used/reserved by ASUS so best to stay clear to avoid any weird behaviour/clash.

I'm not saying single bit fwmark 0x1000 (and 0x2000, 0x4000) is still 100% safe, but if not, then I (and by association so too @Xentrk) have successfully blagged our way forward and enjoyed a rewarding good run over the last 4-5 years!

At the moment I don't have an RT-AX86U etc. so I don't know if wireguard_manager will be around much longer given WireGuard's formal inclusion in the official firmware for that model et al., nor indeed @RMerlin's future plans for VPN Director.

Abject apologies if I have broken/inconvenienced your fwmark WireGuard environment. :oops:
 
Last edited:
Hello,

I have managed to compile a "wireguard-kernel_1.0.20210606-k51_1_aarch64-3.10.ipk". I currently don't have any AX88U router to test it on so it is completely untested. if any AX88U owner have the guts to test it: PM me and I will send a download link with some instructions.

//Zeb

Prerequisites is of course you have a working wgm setup today.
 
Last edited:
@ZebMcKayhan

I have implemented your suggestion to auto-import Vendor supplied .conf files into the next available WireGuard designated interface 'slot' on the router, and relegated the use of import xxxxxx[.conf] name= requests for advanced users.

e.g. I already have 4 WireGuard 'client' peers configured (interfaces wg11 thru' wg14), and requested the import of Mullvad's file

'/opt/etc/wireguard.d/mlvd-us53.conf'

Code:
E:Option ==> import mlvd-us53

    [✔] Config mlvd-us53 import as wg15 success

This should eliminate all future end-user confusion/frustration ( as reported by new user @Stingray123 ) as the very first import request should now by default create wg11 (rather than mlvd-us53 as it would have done previously as allowed per the official wg=quick documentation)

View attachment 36869

NOTE: If the .conf file has a 'wg1' prefix then it will be honoured as the target interface name (assuming it is not already in use), unless overridden by the supplied name= directive.

e.g. Advanced users who may wish to retain 'mlvd-us53' as the WireGuard 'client' peer interface name would need to use:
Code:
E:Option ==> import mlvd-us53 name=mlvd-us53

Please download wireguard_manager v4.12b2 from the dev branch to test at your convenience.
Code:
e  = Exit Script [?]

E:Option ==> uf dev

    v4.12b2 WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/dev/wg_manager.sh)
    MD5=f38a9aadaf71ce119e83b83eebd602a9 /jffs/addons/wireguard/wg_manager.sh

<snip>
Looking good, Again!

as I didnt wanna mess up existing configs (I can only generate 5, when I generate the 6:th the first one gets disabled, on the other hand they seem to live forever) so I modified the keys of an existing one, just to get the import:

named it IntegritySE.conf
Code:
E:Option ==> import IntegritySE

        [✔] Config IntegritySE import as wg13 success
it gets imported as wg13 as wg11 and wg12 is already used.

IntegritySE.conf gets renamed to IntegritySE.conf_imported and wg13.conf is the result of the import.

Code:
E:Option ==> peer wg13 del

        Deleting 'client' Peer (wg13)

        Press y to CONFIRM or press [Enter] to SKIP.
y
        'client' Peer wg13 DELETED

wg13.conf is removed.

Code:
mv IntegritySE.conf_imported IntegritySE.conf

testing full name import
Code:
E:Option ==> import IntegritySE.conf

        [✔] Config IntegritySE import as wg13 success

Code:
mv IntegritySE.conf_imported IntegritySE.conf

testing name= option:
Code:
E:Option ==> import IntegritySE name=wg15

        [✔] Config IntegritySE import as wg15 success

testing different ending:
Code:
mv IntegritySE.conf_imported IntegritySE.Whatever

Code:
E:Option ==> import IntegritySE.Whatever

        ***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/IntegritySE.Whatever) config NOT found?....skipping import Peer 'IntegritySE.Whatever' request
nope... the file ending must be .conf

testing additional . :
Code:
 mv IntegritySE.Whatever Integrity.SE.conf

Code:
E:Option ==> import Integrity.SE

        [✔] Config Integrity.SE import as wg13 success

seems rock-solid! great work!

so as long as the file has a .conf ending there shouldnt be any problem.

//Zeb

Edit: also tried IntegritySE without .conf but it wouldnt import... so make sure the filename is xxxxxxxx.conf and it will work!
 
Last edited:
Looking good, Again!

as I didnt wanna mess up existing configs (I can only generate 5, when I generate the 6:th the first one gets disabled, on the other hand they seem to live forever) so I modified the keys of an existing one, just to get the import:

named it IntegritySE.conf
Code:
E:Option ==> import IntegritySE

        [✔] Config IntegritySE import as wg13 success
it gets imported as wg13 as wg11 and wg12 is already used.

IntegritySE.conf gets renamed to IntegritySE.conf_imported and wg13.conf is the result of the import.

Code:
E:Option ==> peer wg13 del

        Deleting 'client' Peer (wg13)

        Press y to CONFIRM or press [Enter] to SKIP.
y
        'client' Peer wg13 DELETED

wg13.conf is removed.

Code:
mv IntegritySE.conf_imported IntegritySE.conf

testing full name import
Code:
E:Option ==> import IntegritySE.conf

        [✔] Config IntegritySE import as wg13 success

Code:
mv IntegritySE.conf_imported IntegritySE.conf

testing name= option:
Code:
E:Option ==> import IntegritySE name=wg15

        [✔] Config IntegritySE import as wg15 success

testing different ending:
Code:
mv IntegritySE.conf_imported IntegritySE.Whatever

Code:
E:Option ==> import IntegritySE.Whatever

        ***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/IntegritySE.Whatever) config NOT found?....skipping import Peer 'IntegritySE.Whatever' request
nope... the file ending must be .conf

testing additional . :
Code:
 mv IntegritySE.Whatever Integrity.SE.conf

Code:
E:Option ==> import Integrity.SE

        [✔] Config Integrity.SE import as wg13 success

seems rock-solid! great work!

so as long as the file has a .conf ending there shouldnt be any problem.

//Zeb

Edit: also tried IntegritySE without .conf but it wouldnt import... so make sure the filename is xxxxxxxx.conf and it will work!
Thanks for taking the time to post your detailed and methodical/comprehensive tests...Quality Assurance engineering background perhaps? ;)
 
Quality Assurance engineering background perhaps?
Ooh, the shame!!:eek::eek::eek:

Most QA people I've worked with are sitting doing fish-leg diagram, 8d reports, fmea, iso9000-whatever certifications. They don't care if the product works or not as long as the paper trailing looks good.
Electronics design engineer actually and I wouldn't say close enough (I usually don't get along with the QA guys/girls). Hopefully my experience is not representative....

Sir, it is I that should be thankful. Thanks for a great script!

//Zeb

By the way, I also tested to import a config where the Adress and DNS were commented and it works just as good. Wgm seem to disregard these hashes. You are one step ahead, again...
 
Last edited:
@Martineau, something totally cosmetic. Is it possible to tag route table 121 as wgvpnc1?

I see the file but it is read only.
/etc/iproute2/rt_tables

Something like this in your old post possible?
 
@Martineau, something totally cosmetic. Is it possible to tag route table 121 as wgvpnc1?

I see the file but it is read only.
/etc/iproute2/rt_tables

Something like this in your old post possible?
Yes.

e.g. Clone '/etc/iproute2/rt_tables' to '/jffs/configs/rt_tables' then when you have modified ''/jffs/configs/rt_tables'' use the following in the appropriate script ( I use init-start) to mount your custom name table.

Code:
if [ -f /jffs/configs/rt_tables ]; then
    # Use custom table
    logger -st "($(basename $0))" "Custom RPDB name table /jffs/configs/rt_tables replaces /etc/iproute2/rt_tables"
    mount -o bind /jffs/configs/rt_tables /etc/iproute2/rt_tables            # Override 'ovpncX' with 'TalkTalk', NewYork etc.
    # df
    # umount /rom/etc/iproute2/rt_tables
fi
You can check if the file is mounted using df, then use umount prior to making more edits before remounting.

Code:
df

Filesystem           1K-blocks      Used Available Use% Mounted on
ubi:rootfs_ubifs         79016     66148     12868  84% /
devtmpfs                220048         4    220044   0% /dev
tmpfs                   220160       420    219740   0% /var
tmpfs                   220160      1660    218500   1% /tmp/mnt
mtd:bootfs                4480      3364      1116  75% /bootfs
tmpfs                   220160      1660    218500   1% /tmp/mnt
mtd:data                  8192       636      7556   8% /data
tmpfs                   220160      1660    218500   1% /tmp
/dev/mtdblock9           48128      6188     41940  13% /jffs
/dev/sda1             14779860   3458076  10570988  25% /tmp/mnt/RT-AC86U
Display contents of readonly file....
Code:
cat /etc/iproute2/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1
Display contents of customised file
Code:
cat /jffs/configs/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1

# Custom Wireguard - Martineau
121 wgvpnc1
122 wgvpnc2
123 wgvpnc3
124 wgvpnc4
125 wgvpnc5
Mount the custom file over the readonly file
Code:
mount -o bind /jffs/configs/rt_tables /etc/iproute2/rt_tables

df

Filesystem           1K-blocks      Used Available Use% Mounted on
ubi:rootfs_ubifs         79016     66148     12868  84% /
devtmpfs                220048         4    220044   0% /dev
tmpfs                   220160       420    219740   0% /var
tmpfs                   220160      1656    218504   1% /tmp/mnt
mtd:bootfs                4480      3364      1116  75% /bootfs
tmpfs                   220160      1656    218504   1% /tmp/mnt
mtd:data                  8192       636      7556   8% /data
tmpfs                   220160      1656    218504   1% /tmp
/dev/mtdblock9           48128      6196     41932  13% /jffs
/dev/sda1             14779860   3458076  10570988  25% /tmp/mnt/RT-AC86U
/dev/mtdblock9           48128      6196     41932  13% /rom/etc/iproute2/rt_tables
Code:
cat /etc/iproute2/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1

# Custom Wireguard - Martineau
121 wgvpnc1
122 wgvpnc2
123 wgvpnc3
124 wgvpnc4
125 wgvpnc5
Check the WireGuard routing table alias now work
Code:
ip route show table 121

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

ip route show table wgvpnc1

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
 
Last edited:
Edit: also tried IntegritySE without .conf but it wouldnt import... so make sure the filename is xxxxxxxx.conf and it will work!
I decided to ensure that the WireGuard configuration file used by the wireguard_manager import feature would adhere to the WIreGuard naming standard as expected by wg-quick e.g. xxxxxx.conf

The intention was that transferring a working xxxxxx.conf file between platforms would eliminate any typos confusion and keep the process honest etc.

If IntegritySE does allow their created config 'IntegritySE' to be used (or retrieved) as-is without the .conf suffix then I'll still prefer to enforce the .conf naming practice.
 
Last edited:
Yes.

e.g. Clone '/etc/iproute2/rt_tables' to '/jffs/configs/rt_tables' then when you have modified ''/jffs/configs/rt_tables'' use the following in the appropriate script ( I use init-start) to mount your custom name table.

Code:
if [ -f /jffs/configs/rt_tables ]; then
    # Use custom table
    logger -st "($(basename $0))" "Custom RPDB name table /jffs/configs/rt_tables replaces /etc/iproute2/rt_tables"
    mount -o bind /jffs/configs/rt_tables /etc/iproute2/rt_tables            # Override 'ovpncX' with 'TalkTalk', NewYork etc.
    # df
    # umount /rom/etc/iproute2/rt_tables
fi
You can check if the file is mounted using df, then use umount prior to making more edits before remounting.

Code:
df

Filesystem           1K-blocks      Used Available Use% Mounted on
ubi:rootfs_ubifs         79016     66148     12868  84% /
devtmpfs                220048         4    220044   0% /dev
tmpfs                   220160       420    219740   0% /var
tmpfs                   220160      1660    218500   1% /tmp/mnt
mtd:bootfs                4480      3364      1116  75% /bootfs
tmpfs                   220160      1660    218500   1% /tmp/mnt
mtd:data                  8192       636      7556   8% /data
tmpfs                   220160      1660    218500   1% /tmp
/dev/mtdblock9           48128      6188     41940  13% /jffs
/dev/sda1             14779860   3458076  10570988  25% /tmp/mnt/RT-AC86U
Display contents of readonly file....
Code:
cat /etc/iproute2/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1
Display contents of customised file
Code:
cat /jffs/configs/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1

# Custom Wireguard - Martineau
121 wgvpnc1
122 wgvpnc2
123 wgvpnc3
124 wgvpnc4
125 wgvpnc5
Mount the custom file over the readonly file
Code:
mount -o bind /jffs/configs/rt_tables /etc/iproute2/rt_tables

df

Filesystem           1K-blocks      Used Available Use% Mounted on
ubi:rootfs_ubifs         79016     66148     12868  84% /
devtmpfs                220048         4    220044   0% /dev
tmpfs                   220160       420    219740   0% /var
tmpfs                   220160      1656    218504   1% /tmp/mnt
mtd:bootfs                4480      3364      1116  75% /bootfs
tmpfs                   220160      1656    218504   1% /tmp/mnt
mtd:data                  8192       636      7556   8% /data
tmpfs                   220160      1656    218504   1% /tmp
/dev/mtdblock9           48128      6196     41932  13% /jffs
/dev/sda1             14779860   3458076  10570988  25% /tmp/mnt/RT-AC86U
/dev/mtdblock9           48128      6196     41932  13% /rom/etc/iproute2/rt_tables
Code:
cat /etc/iproute2/rt_tables

100 wan0
111 ovpnc1
112 ovpnc2
113 ovpnc3
114 ovpnc4
115 ovpnc5
200 wan1

# Custom Wireguard - Martineau
121 wgvpnc1
122 wgvpnc2
123 wgvpnc3
124 wgvpnc4
125 wgvpnc5
Check the WireGuard routing table alias now work
Code:
ip route show table wgvpnc1

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


ip route show table 121

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
Very nice. It works well. :)
Just added the script into init-start. I suppose this is required so that the custom rt-tables get mounted again during the next reboot. I resists to reboot the router for now. Trying to get more uptime.
 
Very nice. It works well. :)
Just added the script into init-start. I suppose this is required so that the custom rt-tables get mounted again during the next reboot.
Correct, and exactly how I recommend.

I'm not sure how the future firmware implementation will make it human-friendly (if at all), but currently the custom WireGuard routing table alias could be anything e.g. 'NewYork' etc., unless your scripts need/expect to have a formal 'wgvpnc' prefix.
 
Last edited:
Correct, and exactly how I recommend.

I'm not sure how the future firmware implementation will make it human-friendly (if at all), but currently the custom WireGuard routing table alias could be anything e.g. 'NewYork' etc., unless your scripts need/expect to have a formal 'wgvpnc' prefix.
Thanks again. Yes, there is one part of the script I can change from ...table 12$WGVPN_ID to ...table wgvpnc$WGVPN_ID. Actually I have get used to your numbering and I can keep it as is.
 
If IntegritySE does allow their created config 'IntegritySE' to be used (or retrieved) as-is without the .conf suffix
no, they dont... they are only .conf named. I dont know how all others are though but I agree that wgm should require the .conf to make sure we are trying to import something compatible.
what happens if you import the Wireguard.db by mistake (in the same folder)?? probably some friendly message telling you that this did not go as expected, or maybe a more severe import of some random data? or worse?

Android Wireguard app requires the import file to be .conf or .zip (just a zipped .conf file??). if I try to import i.e. a .jpg file it says "error, must be a .conf or .zip file".

so perhaps the error message for importing is a tad confusing:
Code:
***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/IntegritySE.Whatever) config NOT found?....skipping import Peer 'IntegritySE.Whatever' request
when infact (/opt/etc/wireguard.d/IntegritySE.Whatever) exist.

Maybee it should be:
Code:
***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/IntegritySE.Whatever.conf) NOT found?....skipping import Peer 'IntegritySE.Whatever' request
then there is a chance for the user to realize what needs to be done and why it didnt work.

//Zeb
 
Last edited:
what happens if you import the Wireguard.db by mistake
Code:
e  = Exit Script [?]

E:Option ==> import WireGuard.db

    ***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/WireGuard.db) config NOT found?....skipping import Peer 'WireGuard.db' request
So you can then check by listing ALL potential .conf files to be imported

e.g. issue:
Code:
e  = Exit Script [?]

E:Option ==> import ?

     Available Peer Configs for import:
SGS8.conf
mlvd-us53.conf
ubimo.conf
Maybee it should be:
Code:
***ERROR: WireGuard 'client' Peer (/opt/etc/wireguard.d/IntegritySE.Whatever.conf) NOT found?....skipping import Peer 'IntegritySE.Whatever' request
then there is a chance for the user to realize what needs to be done and why it didnt work.
Maybe indeed
 
@DreaZ
Did you get your client to work? Or are you still experience problems?

//Zeb

Yes :\ I've confirmed that there was a issue with the killswitch in 4.11 and have permanently disabled it in 4.12b2 for now. But I still have the same issue when I start wg11 Internet dies, I can't reach 'anything'. As soon as I stop it, Internet works again. I don't have this issue with OpenVPN on the router or when I try the exact same Wireguard key in another device.

And I can't see anything wrong in the imported Wireguard key in WGM. The only difference I see is that I DNS and Address is disabled with # in front of them.

I'm not familiar with Linux and iptables at all, so the wgm diag doesn't say anything to me. But I did sent it to @Martineau

I'm on Merlin fw RT-AC86U_386.3_2 for my Asus RT-AC86U

WAN on the Router:
I have tried different DNS (Cloudflare and my VPN Provider) and automatic from ISP
Disabled Rebind protection and DNSSEC

LAN on the router:
DNSFilter is enabled and Global set to Router

Restarted router within the gui and also tried a hard restart.

Disabled Skynet and Diversion just in case.

But yea... the issue remains...
 
Yes :\ I've confirmed that there was a issue with the killswitch in 4.11 and have permanently disabled it in 4.12b2 for now. But I still have the same issue when I start wg11 Internet dies, I can't reach 'anything'. As soon as I stop it, Internet works again. I don't have this issue with OpenVPN on the router or when I try the exact same Wireguard key in another device.

And I can't see anything wrong in the imported Wireguard key in WGM. The only difference I see is that I DNS and Address is disabled with # in front of them.

I'm not familiar with Linux and iptables at all, so the wgm diag doesn't say anything to me. But I did sent it to @Martineau

I'm on Merlin fw RT-AC86U_386.3_2 for my Asus RT-AC86U

WAN on the Router:
I have tried different DNS (Cloudflare and my VPN Provider) and automatic from ISP
Disabled Rebind protection and DNSSEC

LAN on the router:
DNSFilter is enabled and Global set to Router

Restarted router within the gui and also tried a hard restart.

Disabled Skynet and Diversion just in case.

But yea... the issue remains...
ok, lets hope @Martineau finds anything that could be fixed.

if you, from the terminal issue "wg show" (not inside wgm) do you see any traffic (rx/tx) bytes or are they both 00?

if the peer is working and you have at least any rx/tx bytes you could check if it is DNS related by pinging an ip that does not need to be resolved (like www.google.com):
Code:
ping 142.250.74.36

and see if you get any replies... if you do, the connection works you just cant resolve names (which usually appears as not being able to access anything).

some VPN ISP blocks access to other DNS servers than their own, which is included in the .conf file. I dont know how this is with OVPN, but using the DNS from the original .conf file might be required. DNS in @Odkrys scripts works differently depending if you use default routing or policy routing.
when you had this working did you use default or policy routing? did you use the DNS from the original .conf file and moved into wg scripts?

wgm usually overrides WAN DNS from the router GUI from the one you specify inside wgm. The DNS should be changed inside wgm by:
Code:
peer wg11 dns=9.9.9.9
then restart the client:
Code:
restart wg11

make a note of your original DNS from the .conf file and try to swap back and forth. but this all ofcource requires the peer to work, meaning you have some rx/tx bytes and can ping ipadresses.

//Zeb
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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