I've adapted in mij app "endpoint" to my Interface WAN IP but still nothing unfortunately...
Does your ISP give you a public IP address directly? If so, then it should be possible to get this working... hopefully. If not, then you may need to have a chat with your ISP.
First off, what are the first two octets of the Address in the "IPv4 Upstream" section on the main Status page? Don't need the complete address, just the first two octets.
Second, what are the contents of /etc/config/network and /etc/config/firewall? Please redact any keys or passwords which may be revealed.
1 Like
My IPS is Telenet (Belguim), I do think they provide an Public IP directly (yet this is not a fixed Public IP).
These are the data in IPv4 Upstream:
What SSH command do I need to run to read out these folders?
I've ran "SSH root@routIP" in powershell and got connected.
When trying to read both folders with command "sl /folder" return is "-ash: sl: not found".
Folders seem to be non existing...
Your router's WAN IP address in your screenshot is a private address (RFC 1918), not a public one. What's the WAN interface physically connected to?
It's "ls", not "sl". But that just lists the files, similar to "dir" under DOS/Windows. To see the contents of the files, use "cat" (equivalent to the DOS/Windows command "type").
1 Like
My WAN is physically connected to my Modem from ISP (Telenet). This is a modem with Routerfunctionality included but disabled (no bridging active).
Firewall read below and Networkconfig in screenshot:
root@OpenWrt:~# cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan wg0'
config zone 'wan'
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6'
config forwarding 'lan_wan'
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 src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
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 include
option path '/etc/firewall.user'
config zone
option input 'REJECT'
option forward 'REJECT'
option name 'Guest'
option output 'ACCEPT'
option network 'Guest'
config zone
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option name 'IOT'
option network 'IOT'
config forwarding
option dest 'IOT'
option src 'lan'
config forwarding
option dest 'wan'
option src 'Guest'
config rule
option dest_port '53 67 68'
option src 'Guest'
option name 'Guest DHCP - DNS'
option target 'ACCEPT'
config forwarding
option dest 'lan'
option src 'IOT'
config rule
option target 'ACCEPT'
option proto 'udp'
option dest_port '51254'
option name 'Allow-Wireguard-Inbound'
option src 'wan'
Your network and firewall configurations both appear to be fine for what you want to achieve, but the underlying problem might be outside your control: your OpenWRT router does not have a public IP address. This means that at least one upstream device will also have to be configured, not just your router.
If you have sufficient access to that device to configure it, you may be able to set up the necessary port-forwarding to your OpenWRT router for WireGuard to work. If not, then you'll have to talk to your ISP to find out what can be done to allow WireGuard inbound. Your ISP might permit the necessary ports to be opened, or might even allocate you a public IP address.
Another forum member had a similar issue to yours (private IP address, unable to get inbound traffic working). I knocked up a quick diagram to illustrate the cause of the issue: How to port forward to my Jellyfin server? - #46 by iplaywithtoys
1 Like
If understoot correctly I'd just have to forward my ISP modem / router port towards my OPENWRT router?
How do I check / verify which port I should exactly forward?
I know I can forward ports from my ISP router, hence this should be an option.
If you can forward ports from your ISP device, then hopefully - fingers crossed! - it might be as simple as forwarding port 51254/udp from your ISP device to your router's WAN address (192.168.0.x). If that's the case, then your scenario is called "double NAT".
is my forwarded port (51254) internal or external? And what should I set as the other setting?
If understoot correctly this should be correct?
My apologies. I put 192.168.0.1 in my diagram. As I mention in my forum profile, my diagrams are shoddy and knocked up in a hurry.
That setting looks good to me. It says, in essence, "if any inbound traffic is received at the WAN interface for port 51254/udp, send it internally to the device at 192.168.0.186 and keep the same port number."
1 Like
Okay, Ill try these settings, if these are correctly active should me "IPv4 upstream" adress become a different RFC format?
and adittionally, is it better / cleaner to use DMZ towards my Router then port forwarding?
It appears, as far as I can tell, that your ISP device is behaving as a router, hence the need for the additional port forward. If that's the case, your OpenWRT WAN address ("IPv4 Upstream") should remain the same.
As for DMZ being "better" or "cleaner", that comes down to how much administration you want to carry out. Double-NAT works, but requires a bit more attention to detail, that's all.
1 Like
So I've applied the port forwarding, rebooted my ISP and openWRT router, yet stil the same... Upon connecting to the VPN, I get no internet acces on my mobile and in OpenWRT no handshake get established.
Is there a way to verify that the port forwarding towards my Openwrt router is working correctly?
EDIT: I am now going to deactivate port forwarding and trying with placing my openWRT router in DMZ in mij ISP settings
There is indeed.
There's an optional utility called tcpdump, which is used to capture/inspect network traffic. It's not included in OpenWRT by default, but can be installed as an extra package, either from the command line or via Luci.
In its simplest form, you can tell it to listen to all traffic on an interface. Depending on how busy that interface is, you might see nothing, or you might find your screen filling up with information faster than you can read it.
tcpdump supports filters, to help cut down the noise so that you see the traffic you want to see. Using your router as an example, you could tell tcpdump to listen to your WAN interface, on port 51254. It would then ignore all other traffic which isn't on port 51254 so you could easily see if any inbound WireGuard traffic is reaching OpenWRT.
Here's an example of the syntax: tcpdump -ni <interface> port <port number>
Using your OpenWRT router as an example, I think your WAN interface might be eth0.2 based on your screenshot. If that's correct, then this command might work: tcpdump -ni eth0.2 port 51254
By the way, if you have access to your ISP's router, does it have its own status page which tells you its own WAN IP address? And, if it does, is its own IP address a public IP address or does it also have a private IP address?
1 Like
By the way, if you have access to your ISP's router, does it have its own status page which tells you its own WAN IP address? And, if it does, is its own IP address a public IP address or does it also have a private IP address?
My WAN for my ISP is 94.227.xx.xx -> the same as googling "what is my IP"
Using your OpenWRT router as an example, I think your WAN interface might be
eth0.2based on your screenshot. If that's correct, then this command might work:tcpdump -ni eth0.2 port 51254
When using command tcpdump -ni eth0.2 as command I am reading indeed faster then I can read. When narrowing down with Port 51254 no more traffic is being read. Hence I suspect (if that conclusion is correct) and issue with connection from my mobile or ISP not letting the traffix trough (as nothing is received on the openWRT port)...
It might be possible to test this. Your ISP might be blocking all inbound traffic. Your ISP might be blocking some inbound traffic but allowing other inbound traffic. Or, your ISP might be blocking nothing, and something else might be wrong.
Try forwarding some well-known ports from your ISP router to OpenWRT, e.g. 80/tcp, 443/tcp, 21/tcp, 22/tcp, 23/tcp, 25/tcp, and so on. Then use tcpdump on OpenWRT to listen to those ports on the WAN interface. If your Internet connection is anything like mine, it's probably getting port-scanned all day long. If it is, you might see something immediately on OpenWRT.
But, just in case your public IP address isn't getting bombarded by external scans, you can trigger a scan yourself. Two public websites I used to test my own port-forwarding are grc.com's ShieldsUP! and pentest-tools.com's Online Port Scanner. If you have those well-known ports open and forwarded, tcpdump should show you some information if you trigger an external scan.
By the way, once you finish your tests, remember to remove those port forwards; it's never a good idea to leave open ports unless you actually need them for a specific reason.
1 Like
I think these tests are not really needed as I had a Raspi with homeassistant and port forwarding towards it working flawlessly (to acces from outside of my network). Hence port forwarding is working and incoming traffic is not blocked. I'd just need to find a test to see if port forwarding to this specifc port is working or not I think 
1 Like
In that case, it sounds like you're familiar with the principle, and just need to troubleshoot this particular application.
WireGuard only sends traffic when it needs to, which might not be ideal for troubleshooting port-forwarding. If there's a netcat app or an nmap app for your phone, or another app which lets you generate traffic on the port/protocol of your choice, that may help you to troubleshoot.
1 Like
No port forwarding - DMZ enabled to IPv4 Upstream from openWrt router.
Whilst troubleshooting I just noticed that when connected to my own WIFI (created by the openWRT router) a handshake with Wireguard is established correctly.
Is this normal beheaviour or does it confirm that config is correct / incorrect?
It suggests that the keys are exchanged correctly, at least. But it doesn't conclusively explain why it doesn't work from the outside world.
Of course, it's entirely possible that your ISP isn't blocking anything. It's possible that your mobile network provider might be intercepting traffic.
It comes down to two possibilities:
- Something you can control might not be configured correctly, or;
- Something you can't control might be stopping the traffic.
1 Like