[BUG] Packets don't get forwarded when non-default port is used

[dotlineX]

In raising this issue, I confirm the following:

{please fill the checkboxes, e.g: [X]}

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting is directly related to the pivpn installer script.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

Describe the bug

When the installer script asks for which port to be used, I entered 51821. However the packets don't get forwarded when this is done. I can still ping the raspberry pi itself and clients connected but trying anything else doesn't work, for example the home router (different subnet).

I have checked with tcpdump (this command to be exact: tcpdump -i eth0 port not 22)

The packets are recieved by wireguard but not forwarded to the wide internet.

To Reproduce
Steps to reproduce the behavior:

1. Run installer script.
2. Change default port when asked.
3. Try to connect to example.com while connected to the VPN.

Expected behavior
Packets should get forwarded

Screenshots
No screenshots provided

Desktop (please complete the following information):
Didn't use a desktop/laptop. Here is some info on the server instead:

• VPN Protocol -> Wireguard
• OS: RaspberrypiOS lite 64-bit (same issue on 32 bit)
• Version latest?

Smartphone (please complete the following information):

• VPN Protocol -> Wireguard
• Device: -
• OS: Android 11
• Version v491

[orazioedoardo]

Please add the debug log pivpn debug. Can you at least confirm with the FAQ tutorial that your phone can reach the raspberry pi?

[dotlineX]

Please add the debug log pivpn debug. Can you at least confirm with the FAQ tutorial that your phone can reach the raspberry pi?

I checked the debug but there wasn't anything interesting in my opinion.

Yes I could reach the raspberry pi. I could ping it with its wireguard ip (10.6.0.1)

[coolapso]

1 - This is not a bug!
2 - Moving to Discussions
3 - Debug output is not for you to find interesting or not, If its requested, then you should provide it and hide any sensitive data.

[dotlineX]

1 - This is not a bug!

Why? I tried it twice, once on a RPI3 (32 bit OS) and twice on a RPI4 (64 bit OS). In both scenarios moving to the default port fixed it.

3 - Debug output is not for you to find interesting or not, If its requested, then you should provide it and hide any sensitive data.

Problem was I tried solving it on my own and checked the debug. After that I just gave up and reinstalled it. That's why I couldn't provide a valid debug.

[orazioedoardo]

If you are unable to provide the debug log when the issue occurred, there is not much we can do, apart from waiting in case you can reproduce the behaviour.