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!

What would be the format to test MASQUARADE (I have lost track of which of the various commands I should be using)? Otherwise I agree you would need to have a script for up/down which checks the current WAN IP and updates it.
It would be:
Code:
ip6tables -t nat -I POSTROUTING -s <wg21Ipv6>/64 -o eth0 -j MASQUERADE

But you should remove your snat rule also
 
It would be:
Code:
ip6tables -t nat -I POSTROUTING -s <wg21Ipv6>/64 -o eth0 -j MASQUERADE

But you should remove your snat rule also
All good - tested with 1 IP inside my current ISP allocated range and 2 outside. As previously noted, the 'internal' address works perfectly irrespective of the MASQUERADE rule, whereas the 'external' IPs needed the rule.
 
I started with a /48 and was able to reduce down to /8 without problem. However 2000::1/4 was a problem (though 1000::1/4, 3000::1/4 to e000::1/4 were fine) as was f000::1/4. I then tested some fc.../8 and fd.../8 addresses and as previously noted, no ping and no IPv6.
I think that part of your problems are the huge addresses you are using causing a variety of conflicts (i.e. f000/4 is conflicting with link-local and ULA's). wg21 should always be /64 or even /120. none the less, I think we got the information. as long as we keep off fe8, fc or fd addresses, at appears to work.

The Unique-Local prefix is drawn from the IPv6 Global Unicast Address range, but is specified as not globally routed.
yes, this is probably what is bugging us... although the package should be dropped at the interface then, not during routing as we change the source address in POSTROUTING. NAT6 was a late addition to ipv6 so this may be cause by out-dated software in our routers (or hardware as Broadcom could be involved).

2. If you are choosing a random address, check the IANA preassigned and reserved addresses and make sure your range does not straddle any of these.
3. A better solution may be to find out your ISP's reserved range and then choose a random address within it. You 'might' have a clash with another user for the same ISP, but the odds are extremely small. For SKY (my ISP approximately I in 1.2676506002282*e^30)
yes, this appears to be the two available options. like choosing between 2 bad deceases.

guess the preferred choice would be to convert your ULA to something reserved, like changing the 2 first numbers from "fd" to "aa" and to minimize conflict risk to slim down wg21 range to /120.

so if your ULA if
fdff:aaaa:bbbb:cccc:dddd::/64
change to reserved space:
aaff:aaaa:bbbb:cccc:dddd::/64
add a unique subnet outside /64 and slim down range:
aaff:aaaa:bbbb:cccc:dddd:100::/120
The first address is then our wg21 address:
aaff:aaaa:bbbb:cccc:dddd:100::1/120
and wg21 devices will be
aaff:aaaa:bbbb:cccc:dddd:100::2 - aaff:aaaa:bbbb:cccc:dddd:100::ff

from this point is would be best to NPT this over to our WAN address, like:
Code:
ip6tables -t mangle -I POSTROUTING -s aaff:aaaa:bbbb:cccc:100::/120 -o eth0 -j SNPT --src-pfx aaff:aaaa:bbbb:cccc::/64 --dst-pfx <wanIpv6Prefix>/64
ip6tables -t mangle -I PREROUTING -i eth0 -d <wanIpv6Prefix>:100::/120 -j DNPT --src-pfx <wanIpv6Prefix>/64 --dst-pfx aaff:aaaa:bbbb:cccc::/64
So, what is basically happening is that all packages cooming in to wan within
<wanIpv6Prefix>:100::/120
Will be one-to-one translated to
<aaULAIpv6Prefix>:100::/120

Since no connection tracking is needed then address translation would be much more efficient and you will be able to recieve icmpv6 critical flow control messages.

I'll just need to work on getting these commands automated using nvram varables (help!)

but ofcource the Masquarading rule is more convenient...
 
Last edited:
I think that part of your problems are the huge addresses you are using causing a variety of conflicts (i.e. f000/4 is conflicting with link-local and ULA's). wg21 should always be /64 or even /120. none the less, I think we got the information. as long as we keep off fe8, fc or fd addresses, at appears to work.


yes, this is probably what is bugging us... although the package should be dropped at the interface then, not during routing as we change the source address in POSTROUTING. NAT6 was a late addition to ipv6 so this may be cause by out-dated software in our routers (or hardware as Broadcom could be involved).


yes, this appears to be the two available options. like choosing between 2 bad deceases.

guess the preferred choice would be to convert your ULA to something reserved, like changing the 2 first numbers from "fd" to "aa" and to minimize conflict risk to slim down wg21 range to /120.

so if your ULA if
fdff:aaaa:bbbb:cccc:dddd::/64
change to reserved space:
aaff:aaaa:bbbb:cccc:dddd::/64
add a unique subnet outside /64 and slim down range:
aaff:aaaa:bbbb:cccc:dddd:100::/120
The first address is then our wg21 address:
aaff:aaaa:bbbb:cccc:dddd:100::1/120
and wg21 devices will be
aaff:aaaa:bbbb:cccc:dddd:100::2 - aaff:aaaa:bbbb:cccc:dddd:100::ff

from this point is would be best to NPT this over to our WAN address, like:
Code:
ip6tables -t mangle -I POSTROUTING -s aaff:aaaa:bbbb:cccc:100::/120 -o wg11 -j SNPT --src-pfx aaff:aaaa:bbbb:cccc::/64 --dst-pfx <wanIpv6Prefix>/64
ip6tables -t mangle -I PREROUTING -i wg11 -d <wanIpv6Prefix>:100::/120 -j DNPT --src-pfx <wanIpv6Prefix>/64 --dst-pfx aaff:aaaa:bbbb:cccc::/64
So, what is basically happening is that all packages cooming in to wan within
<wanIpv6Prefix>:100::/120
Will be one-to-one translated to
<aaULAIpv6Prefix>:100::/120

Since no connection tracking is needed then address translation would be much more efficient and you will be able to recieve icmpv6 critical flow control messages.

I'll just need to work on getting these commands automated using nvram varables (help!)

but ofcource the Masquarading rule is more convenient...
I must admit to being very confused (and I don't speak iptables, or not yet) so please correct me if I have completely misunderstood the above and post #820 on NPTv6.

In your first block you are creating a small subnet for the server (wg21) and its devices. You have chosen to modify a ULA range, but in practice this is simply a non-proscribed ipv6/120 range. For users with dynamic DNS I don't follow what the advantage is over using a /120 subnet from their ISPs full range (for my ISP that is a /29 range.)

Also you refer to the /120 range above as being outside the /64 range - but the range given is within the /64 range (i.e. it is a subset) Is this a matter of nomenclature?

I also don't see how using NPTv6 adds any benefit unless it can be used to translate a ULA subnet to a subnet of the current WAN range; you are still starting out with a 'borrowed' IPv6. It would seem that NPTv6 should or is intended do this, so for me the questions seem to be
  • does this work on Asus routers?
  • how do we configure and test?
As I understand it the icmp6 packets are happily reaching the WireGuard server wg21 but then fail to get routed, presumably due the default restrictions on routing ULA packets. (in the POSTROUTING example above you are sending the packets to wg11, did you mean wg21 or if not what are you referring to?)
If this is correct then should we be translating the incoming packets (from ULA to LAN subnet) before they get routed and is this the intention of the PREROUTING rule above

If the designated range refers to aaff:aaaa:bbbb:cccc:dddd:100::/120 and the designated prefix to aaff:aaaa:bbbb:cccc:dddd, then as I read them POSTROUTING is saying 'take packets from the designated range, send them to the wg11(?) interface and swap the designated prefix for the WAN prefix' and the PREROUTING rule is saying 'with packets from the restricted WAN subnet received on the wg11(?) interface, swap the wan prefix for the designated prefix'

However for incoming traffic, the packets would be from the designated subnet (not the WAN subnet) and would need to be swapped before they could be routed? As I said I am getting myself very confused and apologise if I have completely misunderstood.
 
It is confusing for me too, which is probably why I suck at explaining it.

You have chosen to modify a ULA range, but in practice this is simply a non-proscribed ipv6/120 range. For users with dynamic DNS I don't follow what the advantage is over using a /120 subnet from their ISPs full range (for my ISP that is a /29 range.)
Yea, just minimizes the risk for future conflicts, also don't know how not will react if you recieved same prefix again. But it works too.

Also you refer to the /120 range above as being outside the /64 range - but the range given is within the /64 range (i.e. it is a subset) Is this a matter of nomenclature?
Outside /64 means outside (to the right of) the 64 most significant bits. The 100 added is outside /64 but inside /120.

I also don't see how using NPTv6 adds any benefit unless it can be used to translate a ULA subnet to a subnet of the current WAN range; you are still starting out with a 'borrowed' IPv6. It would seem that NPTv6 should or is intended do this, so for me the questions seem to be
  • does this work on Asus routers?
  • how do we configure and test?
The intention is to translate ula prefix to wan prefix exactly as you describe. In my post I showed how to use it and it successfully translated source prefix. But I cannot test the other way.
Benefits, hmm. Faster processing would be one benefit. Each wg21 devices will use its own ipv6 ip address on wan as just the prefix are translated so it would be transparent with no connection memory. The list goes on, but the point is that this was how ipv6 was intended.

(in the POSTROUTING example above you are sending the packets to wg11, did you mean wg21 or if not what are you referring to?)
I don't have ipv6 wan at all so I'm running ipv6 over wireguard internet client on wg11. So to demonstrate above I sent a ping from wg21 device (fc00:192:168:100::2) to my wg11 and before adding the command it exit wg11 with original prefix but after adding the command the prefix is changed. This is the only test I can do. For me it won't work as my wg11 is /128 so I need to use exact ip, not only prefix, but for you it should work.

If the designated range refers to aaff:aaaa:bbbb:cccc:dddd:100::/120 and the designated prefix to aaff:aaaa:bbbb:cccc:dddd, then as I read them POSTROUTING is saying 'take packets from the designated range, send them to the wg11(?) interface and swap the designated prefix for the WAN prefix' and the PREROUTING rule is saying 'with packets from the restricted WAN subnet received on the wg11(?) interface, swap the wan prefix for the designated prefix'
Ok, I may have messed up the wording abit but if you exchange wg11 with eth0 it makes better sense?

However for incoming traffic, the packets would be from the designated subnet (not the WAN subnet) and would need to be swapped before they could be routed? As I said I am getting myself very confused and apologise if I have completely misunderstood.
Hmm... the point would be more like (Priv = wg21 /64 prefix, pub = wan prefix):
Postrouting: if source address is <Priv>:100::1 - <Priv>:100::ff and outgoing interface is eth0 then change <Priv> to <Pub>
Prerouting: if destination address is <Pub>:100::1 - <Pub>:100::ff and incoming interface is eth0 then change <Pub> to <Priv>

So the device suffix 100::1 - 100::ff is used both on wg21 devices and wan so it needs to be locally unique.

Is this better:
Code:
ip6tables -t mangle -I POSTROUTING -s <wg21Prefix>:100::/120 -o eth0 -j SNPT --src-pfx <wg21Prefix>/64 --dst-pfx <wanIpv6Prefix>/64 
ip6tables -t mangle -I PREROUTING -i eth0 -d <wanIpv6Prefix>:100::/120 -j DNPT --src-pfx <wanIpv6Prefix>/64 --dst-pfx <wg21Prefix>/64

Does it make more sense to you?

I'm trying to put this in a script that could be pasted into wg21-up.sh and look-up wan prefix itself since the command gets confusing.
 
Last edited:
@archiel

Well, my scripting skills is alittle embarrassing, but it would be great if you want to give it a try:

Code:
###############################################################################
# Example for wg21 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg21Prefix=aa00:aaaa:bbbb:cccc:: #Wg21 ULA prefix with aa instead of fd
Wg21Suffix=100::1  #Wg21 Device suffix (last 64 bits)
Wg21PrefixLength=120   #Wg21 Prefix Length (120 recommended)
WanInterface=eth0
 
# Changing below lines should not be needed:
WanIp6Prefix=${nvram get ipv6_prefix}     #WanIp6Prefix=2001:1111:2222:3333::
Wg21_PrefIp=${Wg21Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}      #aa00:aaaa:bbbb:cccc:100::1/120
WanWg21_PrefIp=${WanIp6Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}   #2001:1111:2222:3333:100::1/120

# Execute firewall commands:
ip6tables -t mangle -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j SNPT --src-pfx ${Wg21Prefix}/64 --dst-pfx ${WanIp6Prefix}/64
ip6tables -t mangle -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j DNPT --src-pfx ${WanIp6Prefix}/64 --dst-pfx ${Wg21Prefix}/64
###############################################################################

The idea is to change the first lines according to your choice of wg21 address (note the suffix must not be ::1 and since wgm varies last digits it is convenient to use 100::1) the creation of wg21 must match prefix+suffix/cidr.

The target would be to put this in wg21-up.sh and in wg21-down.sh (change -I to -D) but for test each line could just be executed from shell.
 
@archiel

Well, my scripting skills is alittle embarrassing, but it would be great if you want to give it a try:

Code:
###############################################################################
# Example for wg21 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg21Prefix=aa00:aaaa:bbbb:cccc:: #Wg21 ULA prefix with aa instead of fd
Wg21Suffix=100::1  #Wg21 Device suffix (last 64 bits)
Wg21PrefixLength=120   #Wg21 Prefix Length (120 recommended)
WanInterface=eth0

# Changing below lines should not be needed:
WanIp6Prefix=${nvram get ipv6_prefix}     #WanIp6Prefix=2001:1111:2222:3333::
Wg21_PrefIp=${Wg21Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}      #aa00:aaaa:bbbb:cccc:100::1/120
WanWg21_PrefIp=${WanIp6Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}   #2001:1111:2222:3333:100::1/120

# Execute firewall commands:
ip6tables -t mangle -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j SNPT --src-pfx ${Wg21Prefix}/64 --dst-pfx ${WanIp6Prefix}/64
ip6tables -t mangle -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j DNPT --src-pfx ${WanIp6Prefix}/64 --dst-pfx ${Wg21Prefix}/64
###############################################################################

The idea is to change the first lines according to your choice of wg21 address (note the suffix must not be ::1 and since wgm varies last digits it is convenient to use 100::1) the creation of wg21 must match prefix+suffix/cidr.

The target would be to put this in wg21-up.sh and in wg21-down.sh (change -I to -D) but for test each line could just be executed from shell.
Thanks, I think I understand a little more and will have a go tomorrow evening and report back.
 
I have used Wireguard server in RT-AC86U for a few months but suddenly my iPhone stopped connecting. In more detail the Wireguard app connects but no internet. I updated to the latest merlin firmware 386.5 and wgm 4.16b5 but no solution.

Where to start debugging?
 
Last edited:
I have used Wireguard server in RT-AC86U for a few months but suddenly my iPhone stopped connecting. In more detail the Wireguard app connects but no internet. I updated to the latest merlin firmware 386.5 and wgm 4.16b but no solution.

Where to start debugging?
If the iPhone connects then hopefully the Endpoint DDNS (or the IP) is still valid? so no need to check on the router?

i.e. I prefer to use this (if you have Entware tcpdump installed) - assumes 'server' Peer is configured with ListenPort = 51820
Code:
tcpdump -i $(ip route | awk '/^default/{print $NF}')  -l -n -c 1 -p "dst port 51820 and udp" | awk '{print $3 }'
but if you haven't this will work
Code:
conntrack -E --event-mask UPDATE -p udp -o timestamp | grep -E "51820"
Now try to connect inbound to your WireGuard 'server' Peer from your iPhone and confirm the trigger message.


Handshake RX: TX: values are shown non-zero?

Pings?

Have you tried falling back to wireguard_manager v4.15?
Code:
e  = Exit Script [?]

E:Option ==> uf
or even the latest Beta v4.16b5

Have you tried deleting the iPhone Road-Warrior 'device' Peer and creating/importing a new one?

Have you tried deleting the both the 'server' Peer and the iPhone Road-Warrior 'device' Peer and re-creating/re-importing?
 
If the iPhone connects then hopefully the Endpoint DDNS (or the IP) is still valid? so no need to check on the router?

i.e. I prefer to use this (if you have Entware tcpdump installed) - assumes 'server' Peer is configured with ListenPort = 51820
Code:
tcpdump -i $(ip route | awk '/^default/{print $NF}')  -l -n -c 1 -p "dst port 51820 and udp" | awk '{print $3 }'
but if you haven't this will work
Code:
conntrack -E --event-mask UPDATE -p udp -o timestamp | grep -E "51820"
Now try to connect inbound to your WireGuard 'server' Peer from your iPhone and confirm the trigger message.


Handshake RX: TX: values are shown non-zero?

Pings?

Have you tried falling back to wireguard_manager v4.15?
Code:
e  = Exit Script [?]

E:Option ==> uf
or even the latest Beta v4.16b5

Have you tried deleting the iPhone Road-Warrior 'device' Peer and creating/importing a new one?

Have you tried deleting the both the 'server' Peer and the iPhone Road-Warrior 'device' Peer and re-creating/re-importing?
Thanks! Quick reply: I wiped usb stick and jffs and tried to do clean install of amtm, entware and wgm 4.16b5. Didn't help but I'll continue testing with your tips later on.

Just to be sure how I should remove server and device?
 
Just to be sure how I should remove server and device?
Code:
e  = Exit Script [?]

E:Option ==> peer help

    peer help                                                               - This text
    peer                                                                    - Show ALL Peers in database
    peer peer_name                                                          - Show Peer in database or for details e.g peer wg21 config
    peer peer_name {cmd {options} }                                         - Action the command against the Peer
    peer peer_name del                                                      - Delete the Peer from the database and all of its files *.conf, *.key
    peer peer_name ip=xxx.xxx.xxx.xxx                                       - Change the Peer VPN Pool IP
    peer category                                                           - Show Peer categories in database
    peer peer_name category [category_name {del | add peer_name[...]} ]     - Create a new category with 3 Peers e.g. peer category GroupA add wg17 wg99 wg11
    peer new [peer_name [options]]                                          - Create new server Peer             e.g. peer new wg27 ip=10.50.99.1/24 port=12345
    peer new [peer_name] {ipv6}                                             - Create new Dual-stack server Peer  e.g. peer new ipv6
    peer new [peer_name] {ipv6 noipv4}                                      - Create new IPv6 Only server Peer   e.g. peer new ipv6 noipv4
    peer import peer_conf [options]                                         - Import '.conf' into SQL database e.g. import Mullvad_Dallas
                                                                                     e.g. import SiteA type=server
    peer peer_name [del|add] ipset {ipset_name[...]}                        - Selectively Route IPSets e.g. peer wg13 add ipset NetFlix Hulu
    peer peer_name [add] subnet {IPSubnet[...]}                             - Configure downstream subnets e.g. peer wg13 add subnet 192.168.5.0/24
    peer peer_name {rule [del {id_num} |add [wan] rule_def]}                - Manage Policy rules e.g. peer wg13 rule add 172.16.1.0/24 comment All LAN
                                                                                                       peer wg13 rule add wan 52.97.133.162 comment smtp.office365.com
                                                                                                       peer wg13 rule add wan 172.16.1.100 9.9.9.9 comment Quad9 DNS
    peer serv_peer_name {passthru client_peer {[add|del] [device|IP/CIDR]}} - Manage passthu' rules; 'server' peer devices/IPs/CIDR outbound via 'client' peer
                                                                                         peer wg21 passthru add wg11 SGS8
                                                                                         peer wg21 passthru add wg15 all
                                                                                         peer wg21 passthru add wg12 10.100.100.0/27
    peer serv_peer_name {bind device_peer}                                  - Bind a Road Warrior 'device' Peer to a 'server' Peer e.g. peer wg21 bind SGS20
So to delete your iPhone
Code:
e  = Exit Script [?]

E:Option ==> peer iPhone del
Assuming your server Peer is wg21
Code:
e  = Exit Script [?]

E:Option ==> peer wg21 del
To recreate wg21 (as per original install) and the iPhone profiles
Code:
e  = Exit Script [?]

E:Option ==> peer new wg21 port=51820
Code:
e  = Exit Script [?]

E:Option ==> create iPhone wg21 tag=iPhone is My LIFE!
 
Last edited:
FYI... I usually have to add the ? at the end, otherwise wg21 won't delete:
Works for me :rolleyes:

e.g. even if the Peer is UP, and in the case of a 'server' Peer, it has devices defined.
Code:
e  = Exit Script [?]

E:Option ==> peer wg21 del

    Deleting 'server' Peer (wg21)


    Warning: 'server' Peer wg21 has 4 'client' Peer

# Phone#1 device
[Peer]
PublicKey = cdHiEhMQC3oeQyUm5caBI237RAYFdVWvdszZKSpChSY=
AllowedIPs = 10.50.1.2/32
PresharedKey = brlQjPDGAvWIXmDsqzUNjs18vvoWP2RwoiZ7DhfhN7E=
--

<snip>


    You can manually reassign them to a different 'server' Peer by using command 'peer wg2x bind
    Press y to CONFIRM or press [Enter] to SKIP.
y

    Requesting WireGuard VPN Peer stop (wg21)


    WireGuard-server1: WireGuard VPN 'Server' Peer (wg21) on 10.50.1.1:51820 (# RT-AX58U (IPv6) Simulate Server 1) Terminated

    'server' Peer wg21 DELETED
NOTE: If there are bugs then they should always be formally reported.

P.S. I do take personal umbrage at the persistent unauthorised disclosure, publically, of internal developer's (ONLY) debug related Beta commands.
 
Last edited:
P.S. I do take personal umbrage at the persistent unauthorised disclosure, publically, of internal developer's (ONLY) debug related Beta commands.
Please elaborate. you mean the force-delete? You publically disclosed this 7th July 2021: http://www.snbforums.com/threads/se...discussion-2nd-thread-75129.70787/post-698701

I will, as soon as time permits, go through my tutorial and check against your github and in-script help and remove all that is not part of your publicly announced commands (but its hard to tell which is intentional and which is "internal debug").

Edit:
Script confirms deletion of peer test but still asks me to reassign it?
Code:
E:Option ==> peer test del

        Deleting 'device' Peer (test)

        Press y to CONFIRM or press [Enter] to SKIP.
y
        'device' Peer test DELETED

<snip>

E:Option ==> peer wg21 del

        Deleting 'server' Peer (wg21)


        Warning: 'server' Peer wg21 has 1 'client' Peer

# test device
[Peer]
PublicKey = +EwtN8C9cUZSCaRVtf/YL5UgZj9V5IzOK20Z1jg4zzM=
AllowedIPs = 192.168.100.2/32,fc00:192:168:100::2/128
PresharedKey = 7KI5g/+cxz2lW1yod/Wh5tAK5FYMwrbPp7jR2KXi4dY=

        You can manually reassign them to a different 'server' Peer by using
command 'peer wg2x bind
        Press y to CONFIRM or press [Enter] to SKIP.
 
Last edited:
Please elaborate. you mean the force-delete?
...sometimes it is necessary to dictate a change in the execution path within the code.
Now this can be because the original path of execution is either (seemingly) currently flawed or the developer needs to evaluate if an alternative execution flow actually provides a tangible enhancement/fix/work-a-round whilst ensuring that it does not confuse the end user with their expectations.

Hopefully the developer thoroughly tests the new execution flow, and depending on the outcome may adopt or discard the new code execution path proposed.

So in the case of my script, if/when I'm happy that the beta del execution path is acceptable, I can simply retain the end user del command (with which the end user is familiar) but internally, replace the underlying logic, without incurring support queries such as

"I'm confused, why are there two forms of the Peer removal command syntax (del/del?) to remove the designated Peer from the configuration? - which is better?"
When originally posted, seemingly some unidentified corruption was occurring, preventing the physical removal of the Peer simply using del

Now if you (or many others) are still experiencing Peer del issues, then I can either ask for debugging output in order to investigate further or make del always use brute-force, but since it is FORCING the deletion, there is no validation which was its raison d'être in the first place....so compounding one unfortunate possibly? PEBKAC moment with another entirely preventable "whoops there goes the other foot!" outcome wouldn't go down well. ;)
 
Last edited:
If the iPhone connects then hopefully the Endpoint DDNS (or the IP) is still valid? so no need to check on the router?

i.e. I prefer to use this (if you have Entware tcpdump installed) - assumes 'server' Peer is configured with ListenPort = 51820
Code:
tcpdump -i $(ip route | awk '/^default/{print $NF}')  -l -n -c 1 -p "dst port 51820 and udp" | awk '{print $3 }'
but if you haven't this will work
Code:
conntrack -E --event-mask UPDATE -p udp -o timestamp | grep -E "51820"
Now try to connect inbound to your WireGuard 'server' Peer from your iPhone and confirm the trigger message.


Handshake RX: TX: values are shown non-zero?

Pings?

Have you tried falling back to wireguard_manager v4.15?
Code:
e  = Exit Script [?]

E:Option ==> uf
or even the latest Beta v4.16b5

Have you tried deleting the iPhone Road-Warrior 'device' Peer and creating/importing a new one?

Have you tried deleting the both the 'server' Peer and the iPhone Road-Warrior 'device' Peer and re-creating/re-importing?
Thanks I got it fixed! endpoint IP wasn't updated. Should it even update automatically? I had to manually change DDNS in the Wireguard app to some random one and then back to the correct one. After that the client app got the correct IP and the connection works fine.
 
Thanks I got it fixed! endpoint IP wasn't updated. Should it even update automatically?
Simples eh? ;)

The failure to keep the Endpoint = destinations current is an unfortunate WireGuard failing, but acknowledged by the WireGuard developer


wireguard_manager contains a hacked version of Jason's script called (wg_ChkEndpointDDNS.sh) and Site-to-Site users should notice the cron job @JGrana

On Android, in theory you may be able to use a tool such as Tasker to perform something similar, or if you can't update the WireGuard config dynamically on the device, with Tasker you probably could be able to simply bounce the WireGuard App during the night if convenient etc.

(IOS no idea)
 
Last edited:
P.S. I do take personal umbrage at the persistent unauthorised disclosure, publically, of internal developer's (ONLY) debug related Beta commands.
I get yor point, I really do, and I agree to your explanation, however I feel that this is really not deserved. I don't know if you realized my post was a reply to YOU. When I had this issue I did the same as we tell others: I searched the forum to find a solution, which I did in the linked post. Altough not knowing I was unauthorized publically disclosing something (altough already disclosed) (?!). This type of reasoning would defy the purpose of forums were people are helping each other based on previous experience.
I probably have my history to blame for your reaction, but I try to improve as I go.

there is no validation which was its raison d'être in the first place...
Well, the validation does not seem to work for me, as it clearly states that the peer was deleted altough it is not.
 
wireguard_manager contains a hacked version of Jason's script called (wg_ChkEndpointDDNS.sh) and Site-to-Site users should notice the cron job @JGrana


(IOS no idea)
Hmm, I don't see the cron job (cru l only shows wg_manager.sh generatestats).
I probably should re-do all my setups with 4.16b5?

I have been updating using uf dev, but haven't re-run the setup for site-to-site in a while.
 
Hmm, I don't see the cron job (cru l only shows wg_manager.sh generatestats).
I probably should re-do all my setups with 4.16b5?

I have been updating using uf dev, but haven't re-run the setup for site-to-site in a while.
If the Endpoints are actual IP addresses, then the cron job won't be created as there is no way to swap the Endpoint to a new IP anyway.

However, if you are using a DDNS reference, then clearly the script can simply inform WireGuard to refresh the IP it had resolved previously at the point that the 'server' Peer was started.

Unless there is a stupid :rolleyes:bug in this code...

P.S. No need to recreate the Site-to-Site configuration, but if you are definitely using DDNS Endpoints, then it might be worthwhile running a debug on the wg_server script when it starts the interface.
Code:
sh -x /jffs/scripts/addons/wireguard/wg_server wg21 disable
Code:
sh -x /jffs/scripts/addons/wireguard/wg_server wg21

and PM the output.
 

Sign Up For SNBForums Daily Digest

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