Recent content by Alfred

I think you are correct. Sounds familiar: https://www.snbforums.com/threads/iphash-maxelem-not-supported-in-ipset-v4-5.35076/

Hello Adamm, Regarding your notice: ______________________________________ UPDATED 15/12/2017 Currently this script is only supported for Asus Routers with IPSet v6 (AC56U and later) Minimum supported Firmware Versions MerlinWRT v380.68 (or newer) Johns Fork V26E3 (or newer)...

Stubborn as I am, I first tried the hard way... I have read several posts regarding the harder way by forwarding in the PREROUTING chain of the nat table, in which a puzzling IP address 10.8.10.8 was used, which I did not understand, so I did not succeed with that. However, I managed to fix it...

Nevermind... Just solved my own mystery after weeks of pulling my hair out. It appears that in my hunt for NAS-awaking traffic some time ago, I made a firewall rule on the NAS that denies any traffic originating from the router. Normally that is ok, but for port-share it is not because OpenVPN...

As a handy alternative, I have my 2nd OpenVPN server available at TCP:443 instead of the standard UDP:1194 However, I also prefer to have my NAS available over https:443 For this I added the following custom configuration in the advanced settings: port-share <internal NAS IP> 443 This redirects...

Interesting. Thank you for coining that option.

Of course there is a reason why I would like to use TCP 443 for my OpenVPN. That way I can pass through firewalls which only allow outgoing TCP on ports 80 and 443. Do I understand correctly that a listening process on TCP port 443 reserves this port on the hardware it runs on and not only on...

I ran into a conflict in a specific situation, and I am not sure where to post this question: Running AB solution 3.9.1 with Pixelserv-tls on 192.168.#.2 Running Asuswrt-Merlin 380.67 on 192.168.#.1 Trying to start OpenVPN Server 2 on TCP port 443 instead of UDP port 1194 gives: OpenVPN server...

Thx for confirming. I could have just simply "liked" your message, but I really dont like this at all.

Upgrading my RT-AC66U from 380.66_6 to 380.67_0 a 2nd time crippled URL Filtering again. Can someone confirm this?

Reverting to 380.66_6 restored URL Filtering.

Hm... URL Filter doesnt seem to work anymore. iptables -L -v doesnt show any entries. disabling and enabling doesnt help. Removing and adding new URL's doesnt help either.

Glad to see you have the confidence to name it version 380.67 instead of 380.67_0 ;-)

"Despite this being a security device, your router's password is stored in a well known location, in plain text, coded by Asus themselves." Wtf seriously? Ok now I don't see my point either. Rest assured it takes far more than this to make me leave AB. Very happy with it ;-)

OK, I get your arguments, but since this is a security device, it is the last place I would expect to find plaintext passwords. I do not expose SSH or telnet to the WAN. I understand that the game is over when root level access has been acquired. On the internet, plaintext passwords is a...