What's new

Beta Asuswrt-Merlin 388.1 Beta is available for select models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Is Asus even aware of the problem ? Do you think you will be able to fix this on your end or will it require you to wait for an upstream fix. I can live with bugs but i hate security issues.
Don't enable the IPv4 Inbound Firewall Rules option as mentioned or don’t upgrade your firmware or go back to stock if it’s potentially fixed upstream. I’m sure it’ll get fixed somehow-someway and there’s probably a few other security issues lurking nearby that nobody knows about yet that once uncovered in testing you’d want a fix NOW for too, but here it is, you come across as an entitled Karen and it’s annoying. Hi, since I’m still new to the forums so I’ll show myself out but wanted to drop a line.

On a separate note, running Beta 3 on AX86u and not experiencing any issues since beta release. To the show runners, thanks for your continued support with these firmware updates.
 
and there’s probably a few other security issues lurking nearby that nobody knows about yet that once uncovered in testing you’d want a fix NOW for too, but here it is, you come across as an entitled Karen and it’s annoying.

The only thing annoying is your worthless post. This forum is getting a bit to picky for me and it's getting old. Just STFU and bud out unless you have something constructive to say. Now go away.
 
@RamGuy I think you are misunderstanding what enabling UPnP does. The scenario you describe with Call of Duty would only be true if UPnP was disabled. When UPnP is enabled (and the application uses it) it creates a port forwarding rule without restriction on the source address. In effect, this is the same as using Full-Cone NAT without UPnP, or manually creating a port forwarding rule.

Reading through your post again I think what you are calling "UPnP" is actually conntrack, the NAT connection tracking.
 
@RMerlin

It was spoke a lot here but without any reasonable answer, this port forward rule- what makes it?
I have no fetaure available for Parental Control, or Trend Micro...
Something you are aware of?

Taken from AX88U

Thank you
View attachment 45816
You've enabled a setting that denies access to the internet for a specific device or devices.
 
The only thing annoying is your worthless post. This forum is getting a bit to picky for me and it's getting old. Just STFU and bud out unless you have something constructive to say. Now go away.
And if you can’t make your point without profanity and rudeness, then don’t post. You’ve earned a timeout.
 
And if you can’t make your point without profanity and rudeness, then don’t post. You’ve earned a timeout.

Feels like some people had a terrible Thanksgiving lol. I'd never bring a garbage attitude online though - just childish.

I configured my GT-AX6000 yesterday, I've been using the RT-AX88U for the past few years and when testing it still works with Full-Cone NAT. It's only the GT-AX6000 that seems not to so I've had about 28 hours so far with Symmetrical NAT instead of Full-Cone NAT.

NAT =! Security. I don't really understand why some people pretend otherwise. The added security is simply a side effect of NAT. I work as a senior cyber security consultant, and I work mostly with Check Point and Palo Alto deployments. As all government services in my country are being enforced to have native IPv6 supported by Q1 2023 I get into these discussions all the time where people are so afraid of deploying IPv6 because they don't want to have public routable IP addresses within their network. They utilise NAT as some kind of security barrier and have forgotten all about how to manage proper firewalls to safeguard their networks. There is zero need for NAT from a security perspective as long as you have proper firewalling in place.

For home networks it becomes different and most home networks need to rely on UPnP, and as a result of UPnP running on your router it will not only provide you with NAT port mappings, but it will also automatically allow for traffic through the router SPI firewall so you lose all control. For enterprise this is obviously not going to be the case, when doing NAT on an enterprise firewall you will still have to manage your firewall policy accordingly to allow for traffic to traverse NAT.


The reason why I prefer Full-Cone NAT over Symmetrical NAT is that it's pretty much the only way to get around the limitation of having just a single public IPv4 address. If you have a home network that features multiples of the same gaming console, multiple gaming PC's using the same gaming services etc. You run into several frustrating scenarios. Regular UPnP through Symmetrical NAT is not always going to work. There are still a lot of games where P2P is required. You can't really do proper P2P through Symmetrical NAT unless the P2P connection is going to just between you and the game server.

Take a game like Call of Duty: Blackout (I'm not sure if this has changed with more recent Call of Duty games). When doing a private lobby within this game your system (Xbox, PlayStation or gaming PC) is going to host your private lobby locally from your system. UPnP ensures that it is working by telling the router that your local system running 192.168.1.50 is establishing a connection to 193.130.123.40 using local port 34923, and remote port 27031. With Symmetrical NAT return traffic will work, but only when it comes from 193.130.123.40. But your friend A is 193.130.123.40, your friend B is 82.342.23.140. Friend B is not able to connect to your lobby as Symmetrical NAT will not allow for 82.342.23.140 to use the existing port 27031 in order to reach your local system on 192.168.1.50 on local port 34923.

A lot of services do work with Symmetrical NAT as the game is just going to keep utilising UPnP to have additional sessions going. Allowing friend B to reach the lobby via the game utilising UPnP to tell the router that your local system running 192.168.1.50 is establishing a connection to 82.342.23.140 using local port 34924 and remote port 27032.


Things get worse when you start tossing multiple gaming systems into the mix as you are running out of ports. Gaming consoles and games tend to have a limited range of ports they use, so if you exhaust the number of ports you are out of luck.


Full-Cone NAT makes this so much better, as it allows for your gaming session to simply do a 1:1 NAT for whatever ports it needs. Your local system running 192.168.1.50 can simply tell your router that anything you receive on the remote port 27031, just send it to me. Thus friends A and B can utilise the same inbound connection to reach you. From a security perspective, this is less secure, so for people that have no control over their network in any meaningful way, this might not be the way you would like it to be. But for someone who has control, this is vastly superior and is causing a lot fewer headaches.

Port Forwarding will do the same, the problem with manual port forwarding is that you can't forward the same port to multiple IP addresses so you run into a huge mess when you have multiple systems wanting the same ports. Manual port forwarding will be even less secure as it will have the port openings running 24/7, even when they are not needed.


UPnP + Full-Cone NAT is by far the best way for this to work. Then you can have multiple gaming systems battling for the same ports all working. The only scenario where it won't work is if you have too many gaming systems going on all at once and you still run out of ports available for your specific game because even with Full-Cone NAT you can't use the same port twice, but you will most likely never exhaust the number of ports available for whatever game as Full-Cone NAT at least ensures that each gaming device can have multiple incoming connections to the same UPnP opening without having to get a new one going for each remote connection.



With all that being said it's not like you won't survive. If you are on a network that is incapable of doing P2P when gaming, you are still able to connect to others that are capable.
You know, another solution is to purchase an IP block from your ISP and dish out IPs accordingly. Yeah it brings its own set of issues, but it's an idea.
 
All we know is the issue exists in 21224. It's possible they might have already fixed it in newer versions.

I have my AX86U on clean 388_21709. Just need to know what to check and can provide the result.
 
I have my AX86U on clean 388_21709. Just need to know what to check and can provide the result.
 
Do I need to have IPv6 enabled? I can do Passthrough in 60 seconds, but need more time for Native.
 
What I need to do? The output of the commands with IPv4 rules enabled and disabled, I guess?
 
IPv4 Inbound rules disabled:

0
ACCEPT
(nothing)

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination      
   71 24610 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    8   576 WGSF       all      *      *       ::/0                 ::/0            
    8   576 OVPNSF     all      *      *       ::/0                 ::/0            
    8   576 ACCEPT     all      br0    eth0    ::/0                 ::/0            
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0            
    0     0 DROP       all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0            
    0     0 WGCF       all      *      *       ::/0                 ::/0            
    0     0 OVPNCF     all      *      *       ::/0                 ::/0            
    0     0 DROP       all      *      *       ::/0                 ::/0

IPv4 Inbound rules enabled:

1
ACCEPT
(nothing)

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination      
    7   446 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    0     0 WGSF       all      *      *       ::/0                 ::/0            
    0     0 OVPNSF     all      *      *       ::/0                 ::/0            
    0     0 ACCEPT     all      br0    eth0    ::/0                 ::/0            
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0            
    0     0 DROP       all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0            
    0     0 ACCEPT     all      eth0   br0     ::/0                 ::/0           
    0     0 WGCF       all      *      *       ::/0                 ::/0            
    0     0 OVPNCF     all      *      *       ::/0                 ::/0            
    0     0 DROP       all      *      *       ::/0                 ::/0
 
Last edited:
IPv6 port scan here……

IPv4 Inbound rules enabled (default is disabled on this firmware):

1669608283932.png


Passthrough mode though. My ISP device is in router mode. Can't switch it in Bridge right now.

Does this help you guys?
 
IPv4 Inbound rules enabled:

View attachment 45821

Passthrough mode though. My ISP device is in router mode. Can't switch it in Bridge right now.

Does this help you guys?
“STLTH” (green colour) is what I get with IPv4 rules disabled.

Rules enabled, I get all yellow boxes marked “refused”. STLTH is the desired result so far as I know.

Refused must be like telling someone to go away, whereas stealth is just totally ignoring them & not responding at all?

I can’t speak to pass through, but maybe your result means all is ok with the firmware you’re using?
 
“STLTH” (green colour) is what I get with IPv4 rules disabled.

I get all green STLTH with IPv4 Inbound rules enabled or disabled. I can test Native a bit later if it makes a difference. I believe IPv6 firewall is operational in both Passthrough and Native. At least must be. Not sure how it works on Asuswrt
 
Last edited by a moderator:
Is Asus even aware of the problem ?
They've been notified. But as I said, for all we know, it's very possible they had already fixed it.
 
“STLTH” (green colour) is what I get with IPv4 rules disabled.

Rules enabled, I get all yellow boxes marked “refused”. STLTH is the desired result so far as I know.

Refused must be like telling someone to go away, whereas stealth is just totally ignoring them & not responding at all?

I can’t speak to pass through, but maybe your result means all is ok with the firmware you’re using?

Basic TCPIP protocols will say that if a port is closed and a packet is sent to that port, the server will respond with a port closed response. "Stealth" ports basically do not send a status in response, leaving the other end without a reply.
 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top