Hello!
I have replaced my router recently, a port forward was working, but now I just can't figure out how to get it to work. Here are some screenshots from my config:
(https://photos.app.goo.gl/hj6ZpubYRqf49tKU9)
What's interesting that from the local network querying the WAN ip, the port forward works.
Thanks very much for your help!
Let's start with the two major issues I see:
The wan zone should never have input=accept when the upstream connection is untrusted (i.e. the internet). It should always be reject or drop. Your current situation is extremely dangerous.
You've also allowed forwarding from wan > lan. This is also very dangerous as it basically renders the firewall as useless. Fortunately, the NAT masquerading makes direct access to your devices difficult, but still this is a major issue that should be fixed.
Once those are fixed, lets take a look at the configuration in text form:
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/network
cat /etc/config/firewall
Thanks very much for your quick response, I have set from wan to lan the input and forward to reject.
Here are my configs:
network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'xxxx'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.0.1'
list dns '192.168.0.99'
config interface 'wan'
option type 'bridge'
option proto 'dhcp'
option devide 'eth0'
option device 'eth0'
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option auto '0'
option reqaddress 'try'
option reqprefix 'auto'
firewall:
config defaults
option input 'REJECT'
option output 'ACCEPT'
option synflood_protect '1'
option forward 'ACCEPT'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option output 'ACCEPT'
option mtu_fix '1'
option masq '1'
option input 'REJECT'
option forward 'REJECT'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config forwarding
option src 'wan'
option dest 'lan'
config redirect
option dest 'lan'
option target 'DNAT'
option src_dport '51820'
option dest_ip '192.168.0.99'
option dest_port '51820'
option name 'Wireguard'
option src 'wan'
list proto 'udp'
Remove this forwarding. You only need the lan->wan.
Remove the duplicate eth0 and the bridge.
The wan IP is 172.16-31.X.Y by any chance?
Thanks! No, it starts with 178, and there is no '-' in it, and when I check my outside IP from the https://whatismyipaddress.com/ site, it returns the same as listed on the interface.
While this is unrelated to your issue, you have 2 items in your wan network interface definition that should be removed. Remove the two lines below (note: "devide")
Meanwhile, can you connect to your wireguard peer when you point the 'remote' peer to 192.168.0.99 (it must be on the same network for this to work, of course).
Thanks, I have removed those lines.
Yes I can connect from local when I change the config to 192.168.0.99.
Great. Just to confirm -- you do get the expected connectivity of your 'remote' peer via the 192.168.0.99 peer, right? It makes sense to verify that the tunnel is actually working (wg show on the .99 machine should show the "latest handshake").
Next, are you using your WAN IP to make the connection, or are you using a domain name? If the latter, please make sure that your domain name does indeed resolve to the WAN IP as expected.
Finally, how are you testing? Is the 'remote peer' a phone? If so, turn off wifi and use your cellular connection for the test.
Yes, I have connected from the local network previously:
bash-5.0# wg show
interface: wg0
public key: **********
private key: (hidden)
listening port: 51820
peer: *********
preshared key: (hidden)
endpoint: 192.168.0.217:42371
allowed ips: 10.8.0.2/32
latest handshake: 9 minutes, 42 seconds ago
transfer: 13.29 MiB received, 139.35 MiB sent
Yes, I'm using a dynamic DNS service, the resolving works just fine.
Yes, I'm using a phone to test it via cellular.
In addition I'm using a pihole as a dhcp server, it is running on the same machine as the wireguard server (both are running in docker).
What's really interesting, is that from the local network the client can connect with the WAN domain. How is that possible?
There are two angles here -- one is the local DNS (via your pihole) could be resolving to the LAN IP, but it appears that you are connecting via the ddns domain name. Or, your router is doing a hairpin.
If you are unable to connect while you are on cellular, but you can connect while you are on the LAN, that may suggest that your ISP is blocking the port.
I have tried using the WAN IP (not the domain) from the local network, and it has still connected to the wireguard server.
I don't think that the ISP is blocking this port, because a few days ago this worked fine with another router.
I have a modem, and I'm using that to plug it in the router's WAN port (this was the case with the older router as well), I think this should work.
Thanks for your effort!
Can you swap in that old router for a test?
Yes, I will do that.
Keep an eye on your WAN IP as you test a different router -- if it changes (which it may), that sometimes can be relevant.
Well, interesting story 
. I have installed back the old router, it received a perfectly different public ip starting with 89 not 178. At first it didn't work either, but I had an idea to restart my phone, after that it worked, then I switched to the new router, and now that also works :: . I'm so sorry, and thank you very much for your help!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.