I should clarify that if I factory reset the new firmware (to allow access), regress it to the old firmware and the load my config file all is good again but not of course upgraded! The upgrade/regression loop has been repeated many times!

  @LVW 

 

What is the exact hardware version of your device? On the printed label.

I want to know can you successfully load the backup to 1.2.0 or not. 

From what you described, that is you can load but after you load the backup, nothing previously configured works on 1.2.0.. 

Well, when you cannot ping the IP, what is the IP on your PC when you do the ping? Same subnet with the router that has loaded the backup?

 

  @John1234 

Thanks for your post.

As per my original post:

- Hardware version is V1.0

- All reasonable permutations were tried with pinging (I have 40 years of networking experience) eg:

-- nailing up both laptop and router (via config file),

-- Router as DHCP server, laptop as client

-- DHCP server connected to both laptop and router

-- Always on subnet 192.168.0.0/24,

-- using both my configured address for the router (192.168.0.123) and its default (192.168.0.1).

-- Laptop nailed up at 192.168.0.100 except when trying DHCP.

 

There is one typo in my original post I wrongly quoted 160.x.x.x as the autoconfig IP address seen on browser redirection. That should have read 169.x.x.x

 

 

  @LVW 

Ok, Finger pointing done and bug pinned down. Version 1.2 is wrongly applying a firewall access control rule that works as you would expect and as anyone would want in SW ver 1.1.1.

RULE

Name: IPGROUP_LAN_Isolation (default "IPGROUP_LAN" is subnet 192.168.0.0/24 on VLAN 1)

Source Network: !IPGROUP_LAN (note the "!" at the front meaning "everything that is not IPGROUP_LAN")

Destination Network: IPGROUP_LAN

Policy: Block

Service Type: All

Direction LAN->LAN

Effective Time: Any

With version 1.1.1 software this does what I expect and want which is to block access to IPGROUP_LAN from all other LANs thereby isolating it. I have tailored versions of the rule for each of my 5 networks. This isolates each network from all the others and is a cornerstone of my security policy.. It work well on V1.1.1 frimware.

With version 1.2 the firmware gets carried away and blocks traffic between valid members of "IPGROUP_LAN" as well. This leaves you unable to communicate on any LAN port included in such a rule. Effectively you can't even talk to yourself!

To reproduce the problem (do as a bench setup not connected to a real network)

1. Set factory default config

2. Load 1.2 Firmware

3. Enable remote management via the WAN port (normally taboo for me) with subnet 0.0.0.0/0 permissions (keeping it simple)

4. Nail up the WAN IP to something other than  the default LAN 192.168.0.0/24 subnet (eg 192.168.1.1)

5. Connect a client (laptop etc) to the WAN port nailed up on the same subnet as the WAN (eg 192.168.1.50) (a router reboot may be needed here)

6. You should now be able to use the http interface to gain access to the settings without using the LAN connections (eg via http://192.168.1.1)

7. Using a different client (laptop  etc) on a LAN port You should also be able to ping the router at its default LAN address 192.168.0.1 at this stage

8. You can also access the config screens from the LAN port at this stage.

9. Now go into "Firewall"/"Access Control" and add a rule using the parameters specified in "Rule" above. (it does not matter that you only have one network configured)

10. As soon as you have entered the rule you will be locked out of the LAN interface and unable to even ping it. It will though show up on an ARP scan from another device on the subnet but that is of little use.

11. If you now delete the rule using the WAN interface you will again have access on the LAN side.

 

I can't role out these new routers without knowing a fix is on the way otherwise I would get locked in to V1.1.1 and that might be bad in the future. Does anybody reading this know the best route to get the TP-Link team to pursue a fix? I have a shed full of TP-Link kit but never before a problem like this one. If it can't/isn't going to be fixed then I need toi send the routers back while I still can.

 

Any help much appreciated.

 

  @Hank21 

The next update (v1.2.1) has just been released and this bug is still not fixed.

I'm wondering... how did the developers tested this before releasing the new firmware?

  @Hank21 

My config had been posted on the forum here previously.

 

I wish it was any error by me... but with v1.1.1 it works.

I have selected an unused vlan as source network like this: !vlan99

And the same as destination network: !vlan99

...to ensure that every single vlan is isolated from each other.

 

I can see that others have posted on the forum a slightly different setup, choosing IPGROUP_LAN (or _ALL?) as destination network.

I've never understood why they do that and what's the most proper way to isolate vlans. Also, in my experience, when I tried to block each vlan from others, it wasn't enough doing so one direction. The rule didn't work bi-directionally.

I'd like to find an instruction from a TP-Link expert about how to isolate every vlan from each other, in standalone mode.

 

The thing is, I also tried, based on my configuration, changing that ACL rule from Block to Allow before doing the firmware update and in that case it succeded to reboot, then I changed it back to Block in the new firmware and after a few moments it managed to refresh the config page but only once, then became unaccessable again. Therefore I'm stating that the v1.2.1 still can't work with "!" ACL rules.

 

Edit:

Just a thought. Do I have to create another ACL rule with higher priority that allows all type from !vlan99 to IPGROUP_LAN?

Does IPGROUP_LAN is the management vlan (being 192.168.0.0/24) that operates the router?

Would it solve the operation between the vlans and the router and the traffic to the internet and still not interconnecting any vlans with each other?

  @Hank21 

Have you or your team tested a config similar to mine since then?

 

I'm not in a hurry at the moment as I can't interrupt the router's operation until the end of Fall but I'm curious how is it that for me it doesn't work and for you it did.