I am a somewhat newbie to OpenWrt and networking. I've been running OpenWrt on BTHH5A router for a few months. My ISP is Virgin Media UK. I am using SuperHub3 as a modem.
My OpenWrt router address is 192.168.n.1 ( n ≠ 100 ). The modem address is 192.168.100.1. The modem is ping4 reachable from the router. But I can't access it from wireless client laptop ( br-lan address 192.168.n.m, n ≠ 100 ). No pings, no http to 192.168.100.1:80.
As a workaround I put an L tunnel from my laptop port 8080 to the router and forwarded the destination to the modem's port 80. This way I could access the modem via http. It's still not ping4 reachable from the laptop. But that's fine. I can live without it.
The question is, is there any elegant way to route the traffic to the modem? I have a WireGuard vpn client running on the router. I also have a OpenVPN client on the router, which is down. I suppose vpn-policy-routing should help. However, the problem is which interface the modem is connected to? And how do I make that interface available in the interface list on vpn-policy-routing page?
My firewall settings :
-------------------------------
Zones Input Output Forward
-------------------------------
lan A A A
wan R A A
tun0fwz R A R
-------------------------------
Wireguard interface ( wg0if ) is included in wan firewall zone. tun0fwz is OpenVPN firewall zone. But I shut down the openvpn interface tun0.
Please let me know your views about routing the traffic to the modem from br-lan's member laptop.
config zone 'wan'
...
list network 'docsismodem'
...
The ellipsis dots are just to indicate whatever config you have set, you just basically need to add the name of the network interface created, which you can do via LuCI rather than modifying the /etc/config/firewall directly.
fwiw, I'm no expert and someone will correct me if I'm wrong, but as you have VPN client(s) set up and working, isn't all the LAN traffic going to go via the VPN tunnel, unless you implement policy based routing or vpn bypass etc?
Like @bill888 said, if you have a VPN client running on that is redirecting your default gateway by default, all traffic is going through your VPN. This traffic will essentially be swallowed by your VPN client, you will need to implement a PBR rule to essentially stop requests to 192.168.100.1 being routed via the VPN and instead use your WAN interface. This can be done via the vpnbypass package which is handy for managing a few rules or perhaps VPN Policy Routing for more control.
The loss of internet was likely a syntax issue with the firewall config. You'll notice that your interfaces were all under a single variable in quotes, but the additional interface was added outside of this, where as my example uses the list format. Depending on what process modifies this firewall interfaces, it can produce different results.
Thank you for pointing out the vpn factor. I switched off all my vpns, made their interfaces not come up on boot, disabled the vpn-policy-routing service, and rebooted. The only interfaces are br-lan, wan and modem.
I get a "404 Not Found" error upon connection to https://192.168.100.1:443 . But the L tunnel works well. " tcpdump | grep 192.168.100.1 " shows data packets going forward and backward between my laptop on br-lan and modem over direct https as well as L tunnel.
I've changed to most generous firewall choices as :
Yes, something is in between. The http browser attaches "/cgi-bin/luci/" to make the url look "https://192.168.100.1/cgi-bin/luci/". Don't know how or why.
Anyways, the tracert from my laptop (192.168.0.11) shows :
C:\Windows\System32>tracert 192.168.100.1
Tracing route to 192.168.100.1 over a maximum of 30 hops
1 5 ms 1 ms 1 ms iStation.lan [192.168.0.1]
2 7 ms * 2 ms 192.168.100.1
Trace complete.
And yes, 192.168.100.2 is ping4 reachable from my laptop ( lan client ).
Usually cable modems (and possibly also DSL modems) are just plain http (port 80) as follows: http://192.168.100.1 (note that there is nothing appended to the end).
Try using a different browser, an incognito window, or clearing your browser history+cache and that should hopefully solve the issue.
I can confirm being a Virgin Media UK customer that the Hub 3 does listen on TCP 443, but a bit strange how LuCI is getting involved with the request.
As advised clearing cache and cookies is a good step, the fact your traceroute was able to get to 192.168.100.1, that suggests there is a route to it with the steps you've done, if there wasn't it would timeout.
Aha yes, clearing the browser cache and using incognito mode worked. Should have realised that before. I will enable vpns one by one and keep testing at every step.
If possible, could you please share your firewall settings?
You've basically exposed your entire network and your router to the internet.