[eITS#200700296, 220700648] When DNS TTL of FQDN object for destination IP timeout, the video stream
So have not tested the policy control for this fix if it fixes it because I need that for USG60 but what I have tested is BWM on the VPN 300 with the new firmware V5.32 and it buffers when TTL goes to 0 and then is removed the for like *ttvnw.net for Twitch video like:
It is then set for BWM to Guaranteed Bandwidth
interface WAN 9280kb
interface DMZ 92160kb
When there is lots of downloading going on P2P all seems fine the video plays fine then the TTL goes to 0 that the video stream is using then this gets removed and the video buffers because lack of bandwidth and because it drops out of BWM Guaranteed Bandwidth.
Can this be fixed so the IP is still in the Guaranteed Bandwidth on active session?
The video stream blocked reason is because the firewall reapplied FQDN object IP again since DNS cache flushed.
Extending the DNS cache may have security concern it is because it may result a new IP address. So We will add a workaround in ZLD4.73 firmware for specific scenario.
It could stop flush old session, then system will keep the session even the DNS cache is expired.0
Without WILDCARD FQDN: Allowing port 53 and 443 from LAN to WAN.
--> Allowing port 53 & 443 traffic from LAN to WAN and without any limitation.
With WILDCARD FQDN: Allowing port 53 and only WILDCARD FQDN for port 443 from LAN to WAN
--> Allowing port 53 & 443 traffic from LAN to specifc IP addresses but blocks othres.
For security concern, firewall will flush FQDN IP sessions once FQDN DNS TTL is expired.
In 4.73 firmware will have workaround to keep old sessions.0
Great can't wait but the test I did was for BWM on VPN300 not the policy control firewall so I hope it fixes both.0
I also do not see how its a security concern if the same session is still going long after the TTL goes to 0 and the IP is flushed.0
If the old IP address used by attacker, and whom known public IP address, then it may attack your PC from Internet. (it is because the NAT session table still exist on firewall)0
Well that true when not using FQDN you allow port 443 outgoing the attacker knows your public IP the NAT session table still exist on firewall.
Just to break it down why I see no problem should I of missed something
Without WILDCARD FQDN just allowing port 53 and 443 from LAN to WAN
You DNS to go to Twitch
You DNS to get the video stream IP 188.8.131.52
You continue to stream video under the same session long after DNS TTL to 0
With WILDCARD FQDN just allowing port 53 and only WILDCARD FQDN for port 443 like *Twitch and *ttvnw.net from LAN to WAN
You DNS to go to Twitch
You DNS *ttvnw.net to get the video stream IP 184.108.40.206
You should be able to continue to stream video under the same session long after DNS TTL to 0 and IP is removed.
So I just don't see the harm in allowing a session that was trusted at the start and then if you simply allow port 443 outright maybe if session closes and opens another session from another source port I could see it being a problem?
- 8K All Categories
- 1.6K Nebula
- 60 Nebula Ideas
- 54 Nebula Status and Incidents
- 4.4K Security
- 222 Security Ideas
- 963 Switch
- 45 Switch Ideas
- 865 WirelessLAN
- 20 WLAN Ideas
- 5.2K Consumer Product
- 138 Service & License
- 268 News and Release
- 94 Success Stories
- 53 Security Advisories
- 11 Education Center
- 573 FAQ
- 273 Nebula FAQ
- 132 Security FAQ
- 73 Switch FAQ
- 72 WirelessLAN FAQ
- 7 Consumer Product FAQ
- 34 Nebula Monthly Express
- 71 About Community
- 44 Security Highlight