It's probably something due to major upgrade to 23.05.2, but I'm not sure what it is. I checked all contents of /etc/config/firewall manually, but did not find anything that seems incompatible with fw4 or whatever is new in 23.05. Background, I'm having a site-to-site wireguard tunnel from a device inside my lan zone. My openwrt router should just redirect udp/1199 traffic to that host which is terminating the tunnel. Doing a packet capture on wan interface now, it seems that the router is rejecting the traffic destined to port 1199 by sending ICMP port unreachable messages.
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '443'
option dest_port '443'
option name 'HTTPS nginx'
option dest_ip '192.168.1.212'
config redirect
option dest_port '80'
option src 'wan'
option name 'HTTP nginx'
option src_dport '80'
option target 'DNAT'
option dest_ip '192.168.1.212'
option dest 'lan'
option proto 'tcp'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'WG'
option proto 'udp'
option src 'wan'
option src_dport '1199'
option dest_ip '192.168.1.9'
option dest_port '1199'
First two redirects are working fine. The bootom one isn't. ICMP unreachables seem to be sent by the router itself since capturing on lan interface does not reveal anything regarding port 1199.
Hmm i think best is to check if wireguard atleast does the handshake.
Icmp is a protocol on its own, like udp, tcp often to ping or arp reply, though not something to worry about.
The only guess is how did you troubleshoot?, did you ping? Then it makes sense it doesn't work icmp is not allowed.
The problem is wireguard is udp, even with a port scan you will not see its open which makes the difference for tcp, if the global or zone firewalls input is set to reject and someone port scans it probably responds with a icmp reply that it is rejected this is because port scans look for tcp, you may want to drop it.
^ i think it may be this above
A other possibility is that you have just to reload the firewall, it seems that it not always happen in luci for some reason , it can be done with a cli command: /etc/init.d/firewall restart
and a other possibility although i don't think it makes a huge difference is remove this line:
The portforward to lan, but again it will be the same result regardless.
It does not since wireguard packets now do not reach the device on the lan side on 192.168.1.9. Checked with packet captures
Captured ICMP packets are Type 3 Code 3 which are supposed to be generated when a device explicitly rejects the incoming packet as opposed to silently drop.
No, not ping. The remote wireguard endpoint actively tries to connect (shown in the capture above), but the packet does not traverse the router.
The other UDP redirects work fine, for example this one I used to test with another OpenVPN host inside my lan network
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option dest_ip '192.168.1.160'
option name 'OpenVPN'
option dest_port '1194'
option proto 'udp'
option src_dport '1194'
What would happen if you remove the dest firewall zone from the portforward (lan zone) and only keep the dest ip?
And what happens if above does not work, if you create two traffic rules one from src lan to wan with wg port as dest port, and the other inverse from wan to lan, and you keep your portforward rule intact?
Maybe the portforward works as device, but it may has a interzone issue it sound strange but that should 100% work if that also fails i wonder if the wg instance is open
Check that this machine is indeed listening on port 1199 for incoming WG connections.
The best way to do this is to use a local device (like a phone or computer) on the same 192.168.1.0/24 network, and setup WG on that device with an endpoint host of 192.168.1.9:1199 -- does it handshake properly?
Yes, it was listening. I checked with another client from local device. Packet captures confirmed that nothing was received on port 1199 from remote public IP...
I ended up flashing clean image and painstakingly restoring backup line by line. It works now and all packet captures are as expected. Thanks for the help anyway.
, it can be done with a cli command: 