Posted: Wed Feb 08, 2023 5:15 Post subject: [SOLVED] Rmt rtr's admin pg blocked after local rtr upgrade
Config:
TP-Link Archer A7 (r51576) running WG > Internet > Netgear R7000 (r51589)(no WG) > PiVPN WG Server
Routing tables allow connection from the R7000's subnet to the A7 management page through the VPN. It works fine through the R7000 when on r51184.
After the R7000 firmware upgrade to r51589 the A7's management webpage no longer is accessible from the R7000's subnet. Pinging after the upgrade still works from both the R7000's subnet to the A7 and from the A7 to the R7000. The A7 management page is always accessible from the Pi.
Reverted the R7000 to r51184 with no other changes and the A7's management page is working again from the R7000's subnet.
Are there any new configuration options on r51589 that may be blocking the A7's admin page?
Last edited by raincity on Thu Feb 09, 2023 2:10; edited 2 times in total
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Wed Feb 08, 2023 7:07 Post subject: Re: Rmt router's admin page blocked after local router upgra
raincity wrote:
Config:
TP-Link Archer A7 (r51576) running WG > Netgear R7000 (r51589)(no WG) > PiVPN WG Server
Routing tables allow connection from the R7000's subnet to the A7 management page through the VPN. It works fine through the R7000 when on r51184.
After the R7000 firmware upgrade to r51589 the A7's management webpage no longer is accessible from the R7000's subnet. Pinging after the upgrade still works from both the R7000's subnet to the A7 and from the A7 to the R7000. The A7 management page is always accessible from the Pi.
Reverted the R7000 to r51184 with no other changes and the A7's management page is working again from the R7000's subnet.
Are there any new configuration options on r51589 that may be blocking the A7's admin page?
So the problem is the R7000 which is not running WG.
Are the routers and the Pi daisy chained e.g. connected WAN<>LAN all on their own subnet?
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Wed Feb 08, 2023 7:22 Post subject:
I have a daisy chained router which I normally manage with remote administration.
Alternative I setup a route on my main router and opened up the firewall of the secondary router.
Normally I can open the manage page with the routers IP address but now I cannot, so that seems to confirm your findings, assuming you have the same kind of setup.
Can you do the following upgrade the R7000 so that is is not working again.
Then on the R7000 do the following:
Quote:
iptables -D FORWARD -m state --state INVALID -j DROP
iptables -D INPUT -m state --state INVALID -j DROP
Posted: Wed Feb 08, 2023 8:08 Post subject: Re: Rmt router's admin page blocked after local router upgra
egc wrote:
So the problem is the R7000 which is not running WG.
Are the routers and the Pi daisy chained e.g. connected WAN<>LAN all on their own subnet?
How did you setup to reach the management page, routing, firewall rules etc.
R7000 is connected to the cable modem, Pi is connected via Ethernet to the router. Set up the route to the remote router's network to use the Pi as the default gateway. All ports on both routers are closed with the exception of the WG ports and I don't have the firewalls configured.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Wed Feb 08, 2023 10:45 Post subject:
Did you try these rules below?
egc wrote:
I have a daisy chained router which I normally manage with remote administration.
Alternative I setup a route on my main router and opened up the firewall of the secondary router.
Normally I can open the manage page with the routers IP address but now I cannot, so that seems to confirm your findings, assuming you have the same kind of setup.
Can you do the following upgrade the R7000 so that is is not working again.
Then on the R7000 do the following:
Quote:
iptables -D FORWARD -m state --state INVALID -j DROP
iptables -D INPUT -m state --state INVALID -j DROP
Entered the iptables commands via telnet and they did resolve the problem. They were not persistent upon reboot so I added them to the firewall config.
From what I see those iptables commands won't impact router security at all, am I missing anything?
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Thu Feb 09, 2023 7:11 Post subject:
Great to hear it solves your problem.
The risk of removing the INVALID rules is minimal.
But we are looking for a better solution.
I hope you can test two alternative solutions.
To test the second solution reinstate the INVALID rules:
Remove the -D rules
restart the firewall : restart firewall
Check if the INVALID rules are in place: iptables -vnL FORWARD
check if the management webpage is inaccessible
Now the solution, add the following rule from Command line (telnet/putty/ssh):
iptables -t nat -I POSTROUTING -o br0 -j MASQUERADE
Now check if you can access the management page again.
Third solution
first clean up so that the POSTROUTING rule of the second solution is gone, restart the firewall: restart firewall
check if the management webpage is inaccessible
Now the third solution, add the following three rules in this specific order, it will replace the INVALID rule by a more specific one:
Code:
iptables -D FORWARD -m state --state INVALID -j DROP
iptables -I FORWARD ! -s $(nvram get wan_ipaddr) -o $(get_wanface) -p tcp -m state --state INVALID -j DROP
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
The risk of removing the INVALID rules is minimal.
But we are looking for a better solution.
I hope you can test two alternative solutions.
To test the second solution reinstate the INVALID rules:
Remove the -D rules
restart the firewall : restart firewall
Check if the INVALID rules are in place: iptables -vnL FORWARD
check if the management webpage is inaccessible
Now the solution, add the following rule from Command line (telnet/putty/ssh):
iptables -t nat -I POSTROUTING -o br0 -j MASQUERADE
Now check if you can access the management page again.
Third solution
first clean up so that the POSTROUTING rule of the second solution is gone, restart the firewall: restart firewall
check if the management webpage is inaccessible
Now the third solution, add the following three rules in this specific order, it will replace the INVALID rule by a more specific one:
Code:
iptables -D FORWARD -m state --state INVALID -j DROP
iptables -I FORWARD ! -s $(nvram get wan_ipaddr) -o $(get_wanface) -p tcp -m state --state INVALID -j DROP
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Check if the management webpage is accessible.
I hope you can do that so that we can have some ideas how to permanently solve this.
1. Removed the previous iptables entries and restarted the firewall. Both invalid FORWARD and INPUT rules seemed to be back (if I'm interpreting the output correctly) and the remote router is again inaccessible.
2. Added the "iptables -t nat -I POSTROUTING -o br0 -j MASQUERADE" line and the remote router is accessible.
3. Restarted the firewall. The remote router is again inaccessible.
4. Added the last three entries (Copied and pasted). The remote management page remains inaccessible.
Can try additional configuration options if needed.
