Hi. I'm having problems with directing HTTP traffic to other ports than 80, and it does feel like it's a web browser issue, but it appears as it's not.
I'm using several ports for other traffic and although they're not web browsers/servers, they're working flawlessly, but as soon as I try to set up another web server, for instance, a Raspberry Pi Zero running Apache2 with Wordpress that is running on port 80 by default (Tried changing this too, nu success), this has then been set to port 8080, 8888, 81 and a few others, and when I try accessing this port externally, I automatically get routed back to port 80.
When I close down port 80 (Which is directed on another machine on the LAN) I get connection problems, meaning it does take the time to check the connection on any other ports than 80.
When the port is re-enabled it takes like a second before it re-routes to 80 again.
In other words, if I type this in the address field;
[ http:xxx.xxx.xxx.xxx:8080 ]
it becomes
[ xxx.xxx.xxx.xxx ]
I'm curious how come this, if it now is the router, doesn't affect other servers that I'm running..?
I'm also connecting from the outside through VPN client software on my main PC.
Also using WireGuard on the router.
Firewall-> Port mapping points to the VPN-connection, not WAN of course.
Same as the other mappings I've got already configured.
This is a common function of web browsers where they hide the URL info past the domain name, including the port number.
But to understand the details, we'd need to see your firewall configuration. It is also critical to understand from where you are testing this... testing redirects requires that you are outside your own network. This means using a cellular or other remote network (work/school/other location, etc.) and then connecting to your network's public WAN address.
Please connect to your OpenWrt device using ssh and 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:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
root@OpenWrt:~# cat /etc/config/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 'fdbf:3c38:9e60::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0.1'
option acceptlocal '1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.5.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
config interface 'wan6'
option device 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 5t'
config interface 'wg0'
option proto 'wireguard'
option private_key '***Redacted***'
list dns 'x17.x4.xxx.xxx'
list dns '192.1xx.9xx.xx7'
list dns '2f02:b810:4ce1:12a0:adb::1'
list dns '2f0e:63c:bed:1:acb::1'
option force_link '1'
list addresses 'xxx.xxx.xxx.xxx/32'
config wireguard_wg0
option description 'Imported peer configuration'
option public_key '***Redacted***'
option endpoint_host 'xxx.xxx.xxx.xxx'
option endpoint_port '****'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option route_allowed_ips '1'
config interface 'test'
option proto 'dhcp'
option device 'eth0.1'
config device
option name 'eth0'
option acceptlocal '1'
root@OpenWrt:~# cat /etc/config/firewall
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
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 input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
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 zone
option name 'vpn'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'wg0'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'vpn'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '5001'
option dest_ip '192.168.5.152'
option dest_port '5001'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '7878'
option dest_ip '192.168.5.152'
option dest_port '7878'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '20009'
option dest_ip '192.168.5.152'
option dest_port '20009'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '2009'
option dest_ip '192.168.5.152'
option dest_port '2009'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '20010'
option dest_ip '192.168.5.152'
option dest_port '20010'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '411'
option dest_ip '192.168.5.152'
option dest_port '411'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Web'
option family 'ipv4'
option src 'vpn'
option src_dport '80'
option dest_ip '192.168.5.204'
option dest_port '80'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '2018'
option dest_ip '192.168.5.193'
option dest_port '2018'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
option src 'vpn'
option src_dport '6001'
option dest_ip '192.168.5.150'
option dest_port '6001'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Web2' <-Other web server
option src 'vpn'
option src_dport '81'
option dest_ip '192.168.5.193'
option dest_port '80'
option family 'ipv4'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Redacted' <-Third (and forgotten before this post) web server not working
option src 'vpn'
option src_dport '7878'
option dest_ip '192.168.5.203'
option dest_port '7878'
config rule
option name 'RedactedName'
option src 'lan'
option dest 'vpn'
option target 'DROP'
list src_ip '192.168.5.203'
list src_ip '192.168.5.204'
list src_ip 'fd8c:80e8:f2e1:4::c17'
list src_ip 'fd8c:80e8:f2e1:4::2e7'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'RedactedName'
list proto 'tcp'
option src 'vpn'
option src_dport '6666'
option dest_ip '192.168.5.208'
option dest_port '6666'
' * * * . * * * .* * * .* * * ' are the internal IP addresses that I removed.
Also, missed this one, at the beginning of your reply, but as I wrote, I'm attempting to connect from outside, meaning the Internet via the VPN connection
Edited a few times. Difficult to keep the code blocks intact
Can you put them back, actually? RFC1918 addresses do not reveal anything sensitive about your network, but it is actually difficult to troubleshoot without.
If you're originating from within the network (even with a VPN enabled), it might work, but it is still possible you may not be getting an accurate result because of potential local network access (depending on the way the VPN is being handled, and especially if the VPN is on the router itself, which is what it appears to be). It is always best to test using cellular or a true external network so that your origination machine is indeed not able to have any local network access.
My connection is this:
Router 1 via VPN: This computer + another router
Router 2 also via VPN (This has a static IP and can't be first as it would be considered over-use of bandwidth by my VPN ISP thus it would be much more expensive): Connected to this PC also via separate NIC, although internet traffic has been blocked for that. Note that this "block" was put in place some time after I first attempted the port mapping, so it has nothing to do with the problem. This I'm sure of!
Other computers (Raspberry PI and a PC) are also behind this second router, otherwise unrestricted.
On my computer (referred to as "this computer") I have a VPN client software which uses any available internet connection and tunnels through that to whatever external address I'm accessing
Both of these forwards are only valid for traffic originating from the VPN > inbound into the network. Do you have a VPS or your own dedicated public IP from the VPN provider such that you can forward ports like this?
Yes, I only need access to them from the Internet connection as I can reach them internally if I should desire to do so since they're on the internal network.
My VPN provides me with a so called IPv4 addon service which gives me one "static" IP address which I then can aquire via WireGuard, which is what I've done on the second router.
Regular DHCP can also be configured the same way, which is done on the first router.
There's no outside servers and no VPS, just my Internet connection at home with these two routers and a bunch of computers behind them.
As I mentioned, all other traffic to these other ports via client software (FTP and other specialized clients) are working perfectly with no connectivity issues so in other words, all other port traffic works.
So to be clear, are you testing your port forwards with the static IP provided by your VPN service as part of the "IPv4 addon service"?
The port forwards will not work with your normal WAN address (from your ISP).
Can you draw a system topology diagram? a photo of a sketch on paper will be sufficient, but it will help us to understand how things are connected together.
Ok. This got more complicated than it should be.
It's simple really.
I have two routers, both with WireGuard VPN, first with regular DHCP, second, connected in series (A.K.A. cascaded), with IPv4 which is for all intents & purposes configured the exact same way.
It's only the second router that has a problem, which basically could just as well have been connected first. Really doesn't matter how since it creates a tunnel to my VPN ISP and connects to the internet from there.
This VPN connection is doing all the communicating with the world, and the WAN-port isn't used other than to establish a connection to the Internet, or i in this case via the first router.
I just tried connecting from another Internet connection on my laptop using a Wifi connection that I have access to which doesn't have VPN (Same ISP though, but doesn't matter) and it still re-routes from port 81 back to 80.
I wouldn't know how to draw any diagram to make it any easier to understand. I think I just explained it pretty simple.
I also have dual NICs so I connect to both routers which are on different C-nets.
I disabled internet access for the IP given to this PC (Dual NIC) so it won't route through there.
Other than that, that has nothing to do with that access since I recently added this rule in the Firewall.
My connection is this:
Router 1 via VPN: This computer + another router
Router 2 also via VPN (This has a static IP and can't be first as it would be considered over-use of bandwidth by my VPN ISP thus it would be much more expensive): Connected to this PC also via separate NIC, although internet traffic has been blocked for that. Note that this "block" was put in place some time after I first attempted the port mapping, so it has nothing to do with the problem. This I'm sure of!
If traffic is flowing though any service, it doesn’t matter if it is plain text or vpn encrypted - they will meter by the actual bandwidth going though the pipe. Thst is unless your inner-most tunnel is the one the that is the most restrictive in terms of the bandwidth allocation.
Yes, and previously I only used the IPv4 on my main router (and client software on the computers) and I got an email from my VPN ISP telling me to either fork up more dough (Enterprise subscription) or stop using IPv4 excessively, so I chose the latter.
Anyway, getting a bit OT here. Main focus isn't the VPN but the router.
Ok. I don't see that it would be any problem. As I see it, from this routers perspective, it's connection to the outside is the VPN connection through WAN, which is configured via the WireGuard plugin which utilizes a virtual interface and a custom firewall rule.
In short all traffic goes through this interface and it works. I can access the other ports listed above from client software, just not the web browser which keeps re-directing back to port 80 no matter which port I enter in the address field.
I don't see how that would be affected by how many tunnels or routers I have between me & the Internet. Only time would be a factor and any potential glitches in routers and/or other services involved.
Path mtu discovery could be broken or if you have to many tunnels you can not add more on top because you have reached the lower end of what mtu you can set.
If the browser itself is being told to go back to port 80 then there's either something in the browser that's doing this (e.g. no URI scheme is being set so it tries https and falls back to http) or the webserver endpoint is sending the redirect.
Using the KISS principle, use cURL to debug this on the client you're trying to use:
curl -vv http://[IP.add.re.ss or hostname]:[port]/
That way you'll see what the browser/client, in this case cURL, reports.
It could very well be down to the webserver configuration, especially if using bare IP addresses in the URI.
Ok, but wouldn't I have noticed other issues by now if that was the cause? Everything is working pretty well. How would I be able to tell if that limit has been reached and how do I compensate/unbreak it?
I got this:
curl -vv http://redactedAddress:81
* Trying xxx.xxx.xxx.xxx:81...
* Connected to redactedAddress (xxx.xxx.xxx.xxx) port 81 (#0)
> GET / HTTP/1.1
> Host: redactedAddress:81
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 18 Dec 2023 12:26:26 GMT
< Server: Apache/2.4.56 (Raspbian)
< X-Redirect-By: WordPress
< Location: http://redactedAddress/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host redactedAddress left intact
