Changes included in this update (v2.0.5):
Important Note for TORONTO-N: If you are upgrading from a version earlier than v1.26, your current configuration might be wiped out during this upgrade because of the WiFi driver upgrade. If you use the “Restore Backup” button in the System Settings page to restore from an earlier backup, please restore only Access Control settings. You need to manually enter other settings after restoring Access Control.
Can you give of us an example about the point 3? “Add force IP etc… thanks.
Allow remote control for the router when it’s behind another router/NAT
Tested and working nicely. Shame you can’t check / upgrade firmware remotely though, as that’s basically the only reason I ever log into the thing in the first place once it’s configured, so I still have to change to its Wi-Fi network first.
Oh, and by the way, you have a minor display bug in the router selection page for remote control. Although you can include characters like ‘ in the router display name — and indeed, your guide at https://www.pcwrt.com/forums/topic/how-to-remote-control-the-pcwrt-router/ does so — when you are shown the list of routers to select from, you see the escaping in the display (eg. “Kids\’ Router” instead of “Kids’ Router”).
@casino Let’s assume that www.my-cable-modem.net resolves to IP address 192.168.100.1. If you put 192.168.100.1 in the black list, then http://192.168.100.1 is blocked. However, http://www.my-cable-modem.net is not blocked. That’s the way it should work because multiple web sites may be hosted on the same IP address and you only want to block the domains listed in the black list.
There may be occasions you want to block an IP address, no matter what name is used to access it. That’s when you want to use the forced block syntax: “192.168.100.1!”. When an exclamation mark is appended to the end of the IP address, all domains that resolve to the IP address are also blocked (e.g., www.my-cable-modem.net).
Thanks for the explanation.
@knoxploration Thanks for the feedback. The display bug had been fixed. The problem with remotely upgrading firmware is, you don’t have any options to recover if something goes wrong. As a precautionary measure we don’t support remote upgrade.
“Allow remote control for the router when it’s behind another router/NAT”
that feature has worked for me for ages now. what’s different in 2.05? i think to get it working i had to port forward it through the first router. is this new feature supposed to eliminate the need to port forward in the WAN facing router?
@aaronwilliams You’re right. Port forwarding no longer needed.
Hi. Related to the above comments, I have a more general question. I have set the pcWRT behind a Ubiquiti ER4, and setup static routes between the two subnets (a 192.168.x, and 10.x respectively). The pcWRT routes out fine, and can ping into the Ubiquiti subnet (the 10.x) fine. The reverse isn’t working even if I turn off the iptables in the pcWRT. Even stranger is this: The pcWRT gets assigned a ‘WAN’ IP (10.x) from the Ubiquiti subnet, and I can ping that fine from both subnets; however, I can’t bring up the administrative interface on that ‘WAN’ IP in the Ubiquiti subnet, even though its a LAN IP from the ER4. This doesn’t make any sense to me, particularly since the last comment confirms port forwarding isn’t necessary. Basically, at the end of the day, I want to manage the pcWRT only from the Ubiquiti subnet. Thoughts welcome.
@bigbluesky5151 If the only requirement is to manage the pcWRT router from the ER4 side, the easiest way is to set up port forwarding on the pcWRT for TCP port 80 and/or 443 (to the router itself). This is a security risk when the pcWRT is on the edge. But since you have the ER4 on the edge, this is not a problem.
Since the ER4 subnet sits on the WAN side of the pcWRT, you won’t be able to access the LAN side of the pcWRT even with static routing. Both NATting and the firewall prohibit direct access. The pcWRT firmware is built on the assumption that it functions as a router with NATting & firewall enabled (i.e., with the WAN side exposed to the Internet). Turning off NATting or firewall will bring unexpected behavior.
If you need to access the LAN side network of the pcWRT from the WAN side, the best solution would be to set up a VPN server on the pcWRT.
Per your above, the port forwarding 80 from the ER4 to the pcWRT did the trick, but only after I allowed ICMP traffic through. And I did get to the pcWRT subnet (from the ER4) when I adjusted the ‘next hop’ address of the static route to the ‘WAN’ IP of the pcWRT, not the native subnet gateway. That might explain why it didn’t matter if I have the firewall turned off.
Add forced IP address blocking syntax for black list: 192.168.100.1! With forced IP address block, black list not only blocks access when the IP address is used, but also when a domain name is used and that domain name resolves to the blocked IP address.
It will be very, VERY useless if the same thing is done to the white list too! In this way, when i check “Literal IP Addresses” and i put “whatsapp.net” in the white list, all the IP addresses associated to it will be white listed too. It would be wonderful.
Can you do it?
You must be logged in to reply to this topic.