Rare project developers

[mc36 <>]

well, that single successful ping indicates me that the key exchange was 
successful...
regarding that bad checksum @ udp level, my best guess is that the 
non-freerouter vm
believes it have to use udp&ip checksum offloads whereas freerouter does not 
do it...
if it's the case, you could do two things, both should solve the issue:
run the following on the pure debian (non-freerouter) box:
ethtool -K enp0s31f6 rx off
ethtool -K enp0s31f6 tx off
ethtool -K enp0s31f6 sg off
ethtool -K enp0s31f6 tso off
ethtool -K enp0s31f6 ufo off
ethtool -K enp0s31f6 gso off
ethtool -K enp0s31f6 gro off
ethtool -K enp0s31f6 lro off
ethtool -K enp0s31f6 rxvlan off
ethtool -K enp0s31f6 txvlan off
ethtool -K enp0s31f6 ntuple off
ethtool -K enp0s31f6 rxhash off
ethtool --set-eee enp0s31f6 eee off
alternatively, you can disable udp checksum verification on freerouter by issuing "conf 
t" / "client udp-checksum transmit"
br,
cs


On 4/13/22 13:11, Edgard da Cunha Pontes wrote:
> Hi Csaba,
>
> Thanks for answering!
>
> A few things caught my attention in the debug:
>
> *r2#ping 192.168.1.1 /vrf v1*
> !....
> result=20%, recv/sent/lost/err=1/5/4/0, rtt min/avg/max/sum=2/2/2/4005, ttl 
> min/avg/max=64/64/64, tos min/avg/max=0/0/0
>
> *debug output*
> ...
> debug clntWireguard.sendKeep:clntWireguard.java:786 tx keepalive
> info prtUdp.parseUDPheader:prtUdp.java:105 got bad checksum from 10.65.10.66
> info prtUdp.parseUDPheader:prtUdp.java:105 got bad checksum from 10.65.10.66
> info prtUdp.parseUDPheader:prtUdp.java:105 got bad checksum from 10.65.10.66
> info prtUdp.parseUDPheader:prtUdp.java:105 got bad checksum from 10.65.10.66
> ...
>
> This didn't happen before.
>
> ---
> Edgard