firmware upgrade kills dyndns or portforwarding or both

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

firmware upgrade kills dyndns or portforwarding or both

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
firmware upgrade kills dyndns or portforwarding or both
firmware upgrade kills dyndns or portforwarding or both
2023-10-11 11:48:01
Model: Archer AX1500  
Hardware Version: V1
Firmware Version: AX12(EU)_V1_1.0.25 Build 20230809

I recently bought this Archer AX1500 for home use, I have a setup of the router, a mikrotik hapac2 configured as a dumb switch, my server and my laptop is connected through the switch and they have fix IP. I configured the dns service provided by tp link, and portforwarding for RDP for both my computers.

yesterday I updated my firmware for the router, and I found out, that it broke either the dns or the portforwarding, because I could not access my computers anymore through the DNS:port format.

I double checked everything, deleted, and re added the configs, rebooted the router, rebooted the computers, did not help. I was able to access the computers via direct IP, so it was not the issue.

after downgrading to 1.0.6 Build 20230616 Rel. 49716(4555), it is working again

please check this problem and issue a new fw, because I can't update until this is fixed.

otherwise great product, for a good price (except the missing vpn client function)

  0      
  0      
#1
Options
2 Reply
Re:firmware upgrade kills dyndns or portforwarding or both
2023-10-12 07:31:54

  @p0l1c3c4r You can log in to the router to check whether the IP resolved by DDNS is consistent with the WAN IP.

 Also, you mentioned accessing computers by using direct IP successfully. Is it saying that another device accesses the PC via the IP(WAN of router): port?

  0  
  0  
#2
Options
Re:firmware upgrade kills dyndns or portforwarding or both
2023-10-12 13:37:22

  @DIDADI 

I restored the old firmware now, but if I'll have time, I'll check later

no, I was accessing the other machine typing it's IP in the RDP client, while both machines were on the same network. meaning, I went around portforward, and dns checking that it was not the fault of the RDP connection itself

  0  
  0  
#3
Options