What's new

Kamoj Kamoj Add-on Beta testing II

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

Hello,

I installed 5.4b32 on my R9000. I was unable to get VPN bypassing to work and I had to try several times to get AdGuard to install/start (which it eventually did). I assume it is something relating to my system. I didn't see anything in the logs that stuck out, however I was unable to download the Kamoj or Voxel information from the System Information page. Everything else seemed OK. Things I tried:

- A restart of the router, cleaning the browser cache on the machine I was using and restarting the machine.
- Clearing the VPN bypassing by moving items back to non-bypassed and clicking the clear bypassing from NVRAM buttons.
- Uninstall 5.4b32. Factory reset router, reinstall the current Voxel firmware and 5.4b32

The ip rule display on the VPN bypass page showed nothing was being bypassed no matter what I did...and checking the ip of several devices using curl confirmed devices in the bypass selection list were still using the VPN.

As I needed to get the router going again, I reinstalled 5.4b31. Everything worked as it should on 5.4b31 except I was still unable to download the Voxel release notes, Kamoj release notes or Kamoj FAQ. Downloading the Aegis info, etc., still worked.

Didn't have time to check further, but thought I would pass this along as I won't be able to hop back on here for a while.

Best wishes,
BL
Thank you as always for your good reporting!
The downloading probably times out for you. What timeout do you use for downloads?
Don't know what about the bypassing is about.
Wish you had taken a screen dump of Router Information page. Its very informative...
 
just updated to 5.b32

Just the usual issue with the OpenVPN password file. I have this issue everytime I upgrade. But never took the time to make a topic about it.

Issue: VPN doesn't start after re-install of new addon + reboot.

Log file says:
Code:
2021-07-28 21:45:00; 66.96; [OpenVPN]; [rc.common 13922 Information: Check that OpenVPN Client is enabled];
2021-07-28 21:45:00; 66.97; [OpenVPN]; [rc.common 13922 Information: Check that a configuration file is given and exist];
2021-07-28 21:45:00; 67.00; [OpenVPN]; [rc.common 13922 Existing OpenVPN configuration selected in nvram: ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 21:45:00; 67.03; [OpenVPN]; [rc.common 13922 check_password_file . Get password file for: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 21:45:00; 67.06; [OpenVPN]; [rc.common 13922 Information: Password file according to ipvanish-NL-Amsterdam-ams-a42.ovpn:];
2021-07-28 21:45:00; 67.08; [OpenVPN]; [rc.common 13922 Password file given and exist:/etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.11; [OpenVPN]; [rc.common 13922 Information: fix_password_file /etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.16; [OpenVPN]; [rc.common 13922 Password file not found. Password file Must be 2 lines. FILE: /etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.17; [OpenVPN]; [rc.common 13922 No password file found: /tmp/openvpn_client/idpw. Check pre-defined username/password];
2021-07-28 21:45:00; 67.19; [OpenVPN]; [rc.common 13922 No password file found. No pre-defined username/password exist.];
2021-07-28 21:45:00; 67.21; [OpenVPN]; [rc.common 13922 ERROR: No password file found and no default passwords exist. Exiting];
2021-07-28 21:45:00; 67.23; [OpenVPN]; [rc.common 13922 Information: exit_it ];

Normally, I would then "Create/Edit an OpenVPN Client Configuration manually", load the existing .opvn, fill in the username and password, then save the configuration and then restart the VPN connection and it would work.

However, with this version, if I click the button to save the configuration, then I do see "create_vpn_config_button_clicked 2"
But I do not see an .auth file created.
And also VPN still doesn't start.
Thank you for reporting.
How is the structure of your .ovpn/.auth files on the USB-device? Flat or with sub-directories?
 
Thank you for reporting.
How is the structure of your .ovpn/.auth files on the USB-device? Flat or with sub-directories?
I always had a few lines in /mnt/sda1/autorun/scripts/post-mount.sh that would copy the certificate, the .ovpn and the .auth file directly into /etc/openvpn/config/client/, if they didn't exist there.
(they are stored in the root of the USB)

And then as mentioned, I always had to load the config, enter username+password and save the config.
And then it would overwrite the .auth file and everything would work.
I never found out why it wouldn't just directy use the exiting .auth file.

but since b32 this approach no longer works. -> somehow now when reading the config, it did already prepopulate the username and password field. So it can read the .auth. But openvpn startup script keeps complaining there is no pwd file.

and then I tried deleting .auth -> after this, it doesn't get recreated.

Guess it has something to do with your new option "Sync with USB" but I did not yet enable that option.
 
Hmmm, seems openvpn-client tries to now fetch username+password from nvram
but with me, nvram show |grep vpn_client doesn't show any entries for username / password

Manually added the kamoj_vpn_client_username and password entries.
But still doesn't work.

anyways, first bug I already found in openvpn-client:

Code:
check_password_file () {
   logit "check_password_file $*. Get password file for: ${OVPN_CLIENT_CONF}"
   \rm -f "$CLIENTDIR"/idpw

   # Find specified user/password authentification file:
   PASSWORDFILE=$(grep "^auth-user-pass" "${OVPN_CLIENT_CONF}" | awk '{ print $2 }')
   f="$(basename "${OVPN_CLIENT_CONF}" 2>/dev/null)"; # se1-2.azirevpn.net.ovpn

   logit "Information: Password file according to $f:${PASSWORDFILE}"
   if [ -s "${OPENVPN_CONF_DIR}/${PASSWORDFILE}" ]; then
in my case, my .opvn doesn't yet contain a location for password file. -> ${PASSWORDFILE} is empty, so it tries to use the directory /etc/openvpn/config/client/ as a password file...
So if statement must be:
if [ -s "${OPENVPN_CONF_DIR}/${PASSWORDFILE}" ] && [ -n "${PASSWORDFILE}" ]; then

After this fix, logs look a little better:
Code:
2021-07-28 23:15:14; 5481.23; [OpenVPN]; [rc.common 5181 check_password_file . Get password file for: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 23:15:14; 5481.25; [OpenVPN]; [rc.common 5181 Information: Password file according to ipvanish-NL-Amsterdam-ams-a42.ovpn::];
2021-07-28 23:15:14; 5481.26; [OpenVPN]; [rc.common 5181 ipvanish-NL-Amsterdam-ams-a42.ovpn: Password file not given. Try to find/create one...];
2021-07-28 23:15:14; 5481.27; [OpenVPN]; [rc.common 5181 Information: find_password_file ];
2021-07-28 23:15:14; 5481.28; [OpenVPN]; [rc.common 5181 Processing /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.ovpn ...];
2021-07-28 23:15:14; 5481.30; [OpenVPN]; [rc.common 5181 Processing /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth ...];
2021-07-28 23:15:14; 5481.31; [OpenVPN]; [rc.common 5181 Found possible password file: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth];
2021-07-28 23:15:14; 5481.32; [OpenVPN]; [rc.common 5181 Information: fix_password_file /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth];
2021-07-28 23:15:14; 5481.34; [OpenVPN]; [rc.common 5181 Possible password file: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth];

but it still fails with this error:
021-07-28 23:15:20 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

So somehow something is still ignoring the .auth file, that now in the meantime has been created....


I now manually editted my .opvn file and added the .auth file behind the auth-user-pass statement.

-> now VPN finally starts.

Logfile however shows that my solution for the bug mentioned above is also not entirely correct.
Code:
2021-07-28 23:23:21; 5968.21; [OpenVPN]; [rc.common 28431 check_password_file . Get password file for: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 23:23:21; 5968.23; [OpenVPN]; [rc.common 28431 Information: Password file according to ipvanish-NL-Amsterdam-ams-a42.ovpn:/etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth:];
2021-07-28 23:23:21; 5968.24; [OpenVPN]; [rc.common 28431 ipvanish-NL-Amsterdam-ams-a42.ovpn: Password file given but does not exist:/etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.auth. Try to find another one...];
2021-07-28 23:23:21; 5968.26; [OpenVPN]; [rc.common 28431 Information: find_password_file ];
Because it now has a $PASSWORDFILE that is not empty.
so it should print "Password file given and exist:"
but instead it goes to the elif statement and prints "Password file given but does not exist:"
 
Last edited:
VPN Bypassing is also broken in b32

Code:
root@R7800:/$ ip route show table novpn
Error: argument "novpn" is wrong: table id value is invalid

root@R7800:/$ ip rule show
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

root@R7800:/$ /usr/bin/addon_bypassvpnip.sh force
grep: /etc/iproute2/rt_tables: No such file or directory
Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: invalid table ID

Starting Firewall...
Done!


quick fix, reverted this line
Code:
 [ "$(grep -c "^\<${TID}\>.*\<${NOVPN_TABLE}\>$" /etc/iproute2/rt_tables)" = "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables

back to what is was in the previous version:
Code:
   [ "$(grep -c "${NOVPN_TABLE}$" /etc/iproute2/rt_tables)" -eq "0" ] && [ "$(grep -c "^$TID" /etc/iproute2/rt_tables)" -eq "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables
 
Last edited:
also tested the new function "reverse VPN bypassing":
I defined kamoj_ips_to_vpn and kamoj_reverse_bypass_vpn nvram variables (as mentioned in the FAQ)
and ran the sed -i 's/echo XXX //g' /usr/bin/addon_bypassvpnip.sh (as mentioned in the release post for b32)

After /usr/bin/addon_bypassvpnip.sh force, indeed this function works perfectly.
Only remark I have, is that there is no need to parse the no_vpn_file and add all the IPs to table novpn, if reverse_bypass is enabled

And to disable it again, nvram set kamoj_reverse_bypass_vpn=0 doesn't work; I need to nvram unset kamoj_reverse_bypass_vpn

(and I can imagine that people might also like to use this function based on mac-address (for DHCP devices) i.e. also have kamoj_macs_to_vpn and then translate mac-to-IP before adding them to the rules for table main)


I also tested the "interfaces_to_bypass_vpn":
nvram set kamoj_interfaces_to_bypass_vpn="tun0" && nvram commit

And this works as expected.
 
Thank you for this great discovery!
You are really clever!

In a way good that this happened... o_O
The reason for it is that the file /etc/iproute2/rt_tables does not exist.
The old code then created a new one with only novpn:
213 novpn

But it should have been:
#
# reserved values
#
255 local
254 main
253 default
0 unspec
213 novpn

I don't know in when this started, but will add code to recreate the file if it's missing.
PS
So the old code fixed the issue, but it was not meant to.
I thought /etc/iproute2/rt_tables was a vital file that always existed...

VPN Bypassing is also broken in b32

Code:
root@R7800:/$ ip route show table novpn
Error: argument "novpn" is wrong: table id value is invalid

root@R7800:/$ ip rule show
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

root@R7800:/$ /usr/bin/addon_bypassvpnip.sh force
grep: /etc/iproute2/rt_tables: No such file or directory
Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: invalid table ID

Starting Firewall...
Done!


quick fix, reverted this line
Code:
[ "$(grep -c "^\<${TID}\>.*\<${NOVPN_TABLE}\>$" /etc/iproute2/rt_tables)" = "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables

back to what is was in the previous version:
Code:
   [ "$(grep -c "${NOVPN_TABLE}$" /etc/iproute2/rt_tables)" -eq "0" ] && [ "$(grep -c "^$TID" /etc/iproute2/rt_tables)" -eq "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables
 
Very many thanks to testing and coming with improvement suggestions!

Ok, no more "add all the IPs to table novpn, if reverse_bypass is enabled"

OK, added to FAQ.txt how to off reverse_bypass

OK, added "kamoj_macs_to_vpn" so also MACs can be added to the table main

also tested the new function "reverse VPN bypassing":
I defined kamoj_ips_to_vpn and kamoj_reverse_bypass_vpn nvram variables (as mentioned in the FAQ)
and ran the sed -i 's/echo XXX //g' /usr/bin/addon_bypassvpnip.sh (as mentioned in the release post for b32)

After /usr/bin/addon_bypassvpnip.sh force, indeed this function works perfectly.
Only remark I have, is that there is no need to parse the no_vpn_file and add all the IPs to table novpn, if reverse_bypass is enabled

And to disable it again, nvram set kamoj_reverse_bypass_vpn=0 doesn't work; I need to nvram unset kamoj_reverse_bypass_vpn

(and I can imagine that people might also like to use this function based on mac-address (for DHCP devices) i.e. also have kamoj_macs_to_vpn and then translate mac-to-IP before adding them to the rules for table main)


I also tested the "interfaces_to_bypass_vpn":
nvram set kamoj_interfaces_to_bypass_vpn="tun0" && nvram commit

And this works as expected.
 
Thank you!!! :)
Added your way of doing it to the add-on now.:cool:
Not sure if it really a good idea to every 10 seconds wipe and rebuild the routing table + restart the firewall.

Especially for the "guest" devices that should not be routed via VPN, these would every 10 seconds temporary again send a few packets (for at least a second) via VPN, while the routing is rebuild.
But also the frequent restarting of the firewall might cause some disruptions.

A better solution would be to define an ebtables rule to mark all packets that come in via ath1 (=2.4 GHz) and than have a ip rule to route all those marked packets via routing table novpn.

simple PoC:
edit /usr/bin/addon_bypassvpnip.sh and just above the last "ip route flush cache" insert this line:

Code:
[ "$(ip rule list | grep -c "fwmark 0x64 lookup $NOVPN_TABLE")" = "0" ] && ip rule add fwmark 0x64 table $NOVPN_TABLE

then execute /usr/bin/addon_bypassvpnip.sh force to activate that rule.

And finally execute this command, to start marking the packets:
ebtables -I INPUT -i ath1 -j mark --set-mark 0x64 --mark-target CONTINUE

Just tested this myself, and it works perfectly.
Only thing I do not yet know, is the best place to put that ebtables command, so it persists reboots.
(probably needs to go into /lib/wifi/qcawifi.sh)
 
Your problem is because your .ovpn-file is missing the name of the password file.
I tried to handle these cases in the add-on, but a bug made it not work - as for you.

More info:
1. The "auth-user-pass" line in the .ovpn file should contain the name of the password file.
E.g.: For testing.ovpn the line should be:
auth-user-pass testing.auth
It seems like your line is only:
auth-user-pass

2. The "auth-user-pass" line in the .ovpn file should NOT contain any path.
E.g.: For testing.ovpn the line should be:
auth-user-pass testing.auth

3. All your *.ovpn and correspondingly password files *.auth should be stored at USBs directory /openvpn-client
(These files are at boot (even in Voxel original) copied by hotplug2 to /etc/openvpn/config/client/)
The add-on will only read/backup files to/from this directory.

4. I've updated the add-on handle this and other .ovpn issues better, and given better logs/debug information.

THANK YOU! :)

just updated to 5.b32

Just the usual issue with the OpenVPN password file. I have this issue everytime I upgrade. But never took the time to make a topic about it.

Issue: VPN doesn't start after re-install of new addon + reboot.

Log file says:
Code:
2021-07-28 21:45:00; 66.96; [OpenVPN]; [rc.common 13922 Information: Check that OpenVPN Client is enabled];
2021-07-28 21:45:00; 66.97; [OpenVPN]; [rc.common 13922 Information: Check that a configuration file is given and exist];
2021-07-28 21:45:00; 67.00; [OpenVPN]; [rc.common 13922 Existing OpenVPN configuration selected in nvram: ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 21:45:00; 67.03; [OpenVPN]; [rc.common 13922 check_password_file . Get password file for: /etc/openvpn/config/client/ipvanish-NL-Amsterdam-ams-a42.ovpn];
2021-07-28 21:45:00; 67.06; [OpenVPN]; [rc.common 13922 Information: Password file according to ipvanish-NL-Amsterdam-ams-a42.ovpn:];
2021-07-28 21:45:00; 67.08; [OpenVPN]; [rc.common 13922 Password file given and exist:/etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.11; [OpenVPN]; [rc.common 13922 Information: fix_password_file /etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.16; [OpenVPN]; [rc.common 13922 Password file not found. Password file Must be 2 lines. FILE: /etc/openvpn/config/client/];
2021-07-28 21:45:00; 67.17; [OpenVPN]; [rc.common 13922 No password file found: /tmp/openvpn_client/idpw. Check pre-defined username/password];
2021-07-28 21:45:00; 67.19; [OpenVPN]; [rc.common 13922 No password file found. No pre-defined username/password exist.];
2021-07-28 21:45:00; 67.21; [OpenVPN]; [rc.common 13922 ERROR: No password file found and no default passwords exist. Exiting];
2021-07-28 21:45:00; 67.23; [OpenVPN]; [rc.common 13922 Information: exit_it ];

Normally, I would then "Create/Edit an OpenVPN Client Configuration manually", load the existing .opvn, fill in the username and password, then save the configuration and then restart the VPN connection and it would work.

However, with this version, if I click the button to save the configuration, then I do see "create_vpn_config_button_clicked 2"
But I do not see an .auth file created.
And also VPN still doesn't start.

EDIT: I do see the file /tmp/openvpn_client/config/ipvanish-NL-Amsterdam-ams-a42.ovpn.pw created with my username + password.
But somehow openvpn is not using that.
(and I wonder: after a reboot, this file would be gone. so how does that work?)
 
3. All your *.ovpn and correspondingly password files *.auth should be stored at USBs directory /openvpn-client
(These files are at boot (even in Voxel original) copied by hotplug2 to /etc/openvpn/config/client/)
The add-on will only read/backup files to/from this directory.
THANK YOU! :)

Learned something new. Never knew that Voxel FW also already did this.
Does it simply copy everything that is in /openvpn-client? so also any required certificates?

and no thanks, just glad I could help.
and these latest changes at least make my live a lot easier with FW and/or addon updates.
 
Learned something new. Never knew that Voxel FW also already did this.
Does it simply copy everything that is in /openvpn-client? so also any required certificates?

and no thanks, just glad I could help.
and these latest changes at least make my live a lot easier with FW and/or addon updates.
No, the certs are not copied...
I tried your wifi bypass method implemented in the add-on now, and it works as it should.
Except if killswitch is ON, all devices on that wifi interface lose internet connection.
Can you confirm that? And if so, do you yet again have a neat solution for it?
 
No, the certs are not copied...
I tried your wifi bypass method implemented in the add-on now, and it works as it should.
Except if killswitch is ON, all devices on that wifi interface lose internet connection.
Can you confirm that? And if so, do you yet again have a neat solution for it?
hmm, indeed the killswitch I did't test.

but, i'd say you need to alter openvpn-client

and then in the section that generates /tmp/openvpn/firewall-start-openvpnkillswitch.sh, add some logic.

(and probably also in the WIreGuard file the same needs to be done ??? so perhaps for future maintainability, it is easier to move kill-switch code to a separate file. And call that file from both OpenVPN and Wireguard scripts ?)


some pseudo-code:
Code:
if kamoj_reverse_bypass_vpn=1 then generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh with this contents:
   for each $ip_to_vpn in kamoj_ips_to_vpn do:
       iptables -w -I FORWARD -i br0 -s $ip_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
      for each $mac_to_vpn in kamoj_macs_to_vpn do:
         iptables -w -I FORWARD -i br0 -m mac --mac-source $mac_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
  # and the above code would need to be written if kill-switch is enabled; the option "no killswitch for bypassed devices"  I would simply ignore with reverse bypass.
else
    existing code to generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh
fi

and something to additionaly think about and/or clearly mention in the FAQ:
kamoj_reverse_bypass_vpn=1 only does br0 towards table novpn
an optional tun0 would still go via VPN, even with reverse bypass.
so I in my case also still need this:
kamoj_interfaces_to_bypass_vpn="tun0"

but also this new option would need some additional modifications in the killswitch file.

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn does not contain tun0 then tun0 should still go via VPN??
and thus killswitch.sh should also have
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn=tun0
then killswitch.sh shouldn't have any reject rule for tun0

if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn has some values and "no killswitch for bypassed devices=1"
for each $interface_to_bypass in kamoj_interfaces_to_bypass_vpn do
iptables -w -I FORWARD -i $interface_to_bypass -j br0_fwd
#question here: should you validate the interfaces? And I think the only supported interfaces for kamoj_interfaces_to_bypass_vpn would be br0 and tun0 ??


if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn is not set then:
in the existing logic, also add a rule for this: (if (tun0 exists):
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"
(this rule should have been already in file. But nobody noticed it was missing.


And the trick is to ensure these kill-switch rules are inserted in the right order.

I'm going on holiday tomorrow, so I cannot really do much more than this.
 
The code has become a bit complex through the years...
And for the bypass "WiFi Interface" (involning ebtables)? ...

Relax and have a great holiday!!! :cool:
hmm, indeed the killswitch I did't test.

but, i'd say you need to alter openvpn-client

and then in the section that generates /tmp/openvpn/firewall-start-openvpnkillswitch.sh, add some logic.

(and probably also in the WIreGuard file the same needs to be done ??? so perhaps for future maintainability, it is easier to move kill-switch code to a separate file. And call that file from both OpenVPN and Wireguard scripts ?)


some pseudo-code:
Code:
if kamoj_reverse_bypass_vpn=1 then generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh with this contents:
   for each $ip_to_vpn in kamoj_ips_to_vpn do:
       iptables -w -I FORWARD -i br0 -s $ip_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
      for each $mac_to_vpn in kamoj_macs_to_vpn do:
         iptables -w -I FORWARD -i br0 -m mac --mac-source $mac_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
  # and the above code would need to be written if kill-switch is enabled; the option "no killswitch for bypassed devices"  I would simply ignore with reverse bypass.
else
    existing code to generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh
fi

and something to additionaly think about and/or clearly mention in the FAQ:
kamoj_reverse_bypass_vpn=1 only does br0 towards table novpn
an optional tun0 would still go via VPN, even with reverse bypass.
so I in my case also still need this:
kamoj_interfaces_to_bypass_vpn="tun0"

but also this new option would need some additional modifications in the killswitch file.

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn does not contain tun0 then tun0 should still go via VPN??
and thus killswitch.sh should also have
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn=tun0
then killswitch.sh shouldn't have any reject rule for tun0

if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn has some values and "no killswitch for bypassed devices=1"
for each $interface_to_bypass in kamoj_interfaces_to_bypass_vpn do
iptables -w -I FORWARD -i $interface_to_bypass -j br0_fwd
#question here: should you validate the interfaces? And I think the only supported interfaces for kamoj_interfaces_to_bypass_vpn would be br0 and tun0 ??


if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn is not set then:
in the existing logic, also add a rule for this: (if (tun0 exists):
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"
(this rule should have been already in file. But nobody noticed it was missing.


And the trick is to ensure these kill-switch rules are inserted in the right order.

I'm going on holiday tomorrow, so I cannot really do much more than this.
 
And for the bypass "WiFi Interface" (involning ebtables)? ...

Relax and have a great holiday!!! :cool:
For the ebtables, you’d need to do something with the mark
Don’t have the code handy though.
But would be some rule that I think has
-m mark —mark 0x64
 
I'll add a protocol common "killswitch.sh" file to start with.
Once it's good enough we can add tun0.
You can look at next release when you have time and then we sort out how to proceed.
hmm, indeed the killswitch I did't test.

but, i'd say you need to alter openvpn-client

and then in the section that generates /tmp/openvpn/firewall-start-openvpnkillswitch.sh, add some logic.

(and probably also in the WIreGuard file the same needs to be done ??? so perhaps for future maintainability, it is easier to move kill-switch code to a separate file. And call that file from both OpenVPN and Wireguard scripts ?)


some pseudo-code:
Code:
if kamoj_reverse_bypass_vpn=1 then generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh with this contents:
   for each $ip_to_vpn in kamoj_ips_to_vpn do:
       iptables -w -I FORWARD -i br0 -s $ip_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
      for each $mac_to_vpn in kamoj_macs_to_vpn do:
         iptables -w -I FORWARD -i br0 -m mac --mac-source $mac_to_vpn -o ${WAN_IF} -m state --state NEW -j REJECT"
   next
  # and the above code would need to be written if kill-switch is enabled; the option "no killswitch for bypassed devices"  I would simply ignore with reverse bypass.
else
    existing code to generate /tmp/openvpn/firewall-start-openvpnkillswitch.sh
fi

and something to additionaly think about and/or clearly mention in the FAQ:
kamoj_reverse_bypass_vpn=1 only does br0 towards table novpn
an optional tun0 would still go via VPN, even with reverse bypass.
so I in my case also still need this:
kamoj_interfaces_to_bypass_vpn="tun0"

but also this new option would need some additional modifications in the killswitch file.

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn does not contain tun0 then tun0 should still go via VPN??
and thus killswitch.sh should also have
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"

if reverse_bypass = 1 and kamoj_interfaces_to_bypass_vpn=tun0
then killswitch.sh shouldn't have any reject rule for tun0

if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn has some values and "no killswitch for bypassed devices=1"
for each $interface_to_bypass in kamoj_interfaces_to_bypass_vpn do
iptables -w -I FORWARD -i $interface_to_bypass -j br0_fwd
#question here: should you validate the interfaces? And I think the only supported interfaces for kamoj_interfaces_to_bypass_vpn would be br0 and tun0 ??


if reverse_bypass=0 or not set and kamoj_interfaces_to_bypass_vpn is not set then:
in the existing logic, also add a rule for this: (if (tun0 exists):
iptables -w -I FORWARD -i tun0-o ${WAN_IF} -m state --state NEW -j REJECT"
(this rule should have been already in file. But nobody noticed it was missing.


And the trick is to ensure these kill-switch rules are inserted in the right order.

I'm going on holiday tomorrow, so I cannot really do much more than this.
 
Last edited:
VPN Bypassing is also broken in b32

Code:
root@R7800:/$ ip route show table novpn
Error: argument "novpn" is wrong: table id value is invalid

root@R7800:/$ ip rule show
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

root@R7800:/$ /usr/bin/addon_bypassvpnip.sh force
grep: /etc/iproute2/rt_tables: No such file or directory
Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: invalid table ID

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: table id value is invalid

Error: argument "novpn" is wrong: "table" value is invalid

Error: argument "novpn" is wrong: invalid table ID

Starting Firewall...
Done!


quick fix, reverted this line
Code:
[ "$(grep -c "^\<${TID}\>.*\<${NOVPN_TABLE}\>$" /etc/iproute2/rt_tables)" = "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables

back to what is was in the previous version:
Code:
   [ "$(grep -c "${NOVPN_TABLE}$" /etc/iproute2/rt_tables)" -eq "0" ] && [ "$(grep -c "^$TID" /etc/iproute2/rt_tables)" -eq "0" ] && echo "$TID $NOVPN_TABLE" >> /etc/iproute2/rt_tables

Updated to b32 recently and experiencing some glitches on various devices attached. Discovered my vpn bypass devices were not bypassing (R9000 Voxel V1.0.4.52HF & Kamoj V5.4b32)

Used your quick fix and it is now working OK

Thanks, would not have been able to fix it without your info
 
Hello. I registered something wrong in Telnet and the VPN client stopped working altogether. Since the stable work of the VPN client is very necessary, I had to return to the previous version (Add-on V5,4 b31). But I noticed the same log-file warnings in both versions of the Add-on. As I understand it, the VPN client lacks some kind of libraries. And two warnings pop up after the start. Please tell me what is important I have to do.
 

Attachments

  • Screenshot (328)_LI.jpg
    Screenshot (328)_LI.jpg
    152.7 KB · Views: 78
Hello Kamoj, I have a question for you. Do you plan to establish communication between incompatible features in the future? With pop-up recommendations. For example, if I have a VPN client activated, then when Wireguard client is activated, a window immediately pops up with a warning that this is impossible. (And so on.) Pop-up windows can also be useful when configuring your application. For example, if I want to activate (Killswitch On), then a window with a description of this function immediately pops up. In Germany, such applications are very popular, even among professionals, because they are quick tuning and memory training. These applications are called (Kinderleicht). This means that even a child can customize the application!
This is not a recommendation, this is a simple question.
Best regards to your work!
Baursak
 

Attachments

  • Screenshot (327)_LI.jpg
    Screenshot (327)_LI.jpg
    87 KB · Views: 88
For now it's still working - only warnings.
The issue is that NordVPN is not up-to-date!
In next OpenVPN version, NordVPN will possibly stop working unless you add e.g. this string to the configuration file:
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-256-CBC
or possibly even:
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-256-CBC:ChaCha20-Poly1305

The ping error is also because of a faulty NordVPN configuration.

I suggest you write to their support and report these errors.

(The add-on does not create the configurations for NordVPN, they are downloaded via NordVPNs official API,
so they should be "modern" configuration files. At worst it means that NordVPN is not using latset OpenVPN version...)

Hello. I registered something wrong in Telnet and the VPN client stopped working altogether. Since the stable work of the VPN client is very necessary, I had to return to the previous version (Add-on V5,4 b31). But I noticed the same log-file warnings in both versions of the Add-on. As I understand it, the VPN client lacks some kind of libraries. And two warnings pop up after the start. Please tell me what is important I have to do.
 

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