IPv6 being issued by BSNL Broadband!

  • Thread starter Thread starter Ameen
  • Start date Start date
  • Replies Replies 346
  • Views Views 63,489
@Dark_Nate
AFAIK,CG-NAT have inbuilt UPnP implementation to avoid any conflict of interests.So,yes.... Technically,UPnP works locally for a user....
 
When upnp is enabled..packets which go out and when they return in a cgnat it is lost as they are glued to a private ip with port ..upon return they are unable to hook back to source device. if more than one device is locally used...such packets use udp and they are not passed to issuing device upon return.they are lost and lag occurs in ipv4. in ipv6 this is reduced as ipv6 is mostly public ip... and if you read carefully public ip with upnp enabled is harmful for an ordinary user , not for advanced guru :) Many manufacturers are now disable upnp in default settings as it creates more issues if upnp is enabled. Its is safe for a normal user to keep it off unless he uses a specific app/device which need ports open and use remote login functions such as remote access of say cctv for example. Few protocal need upnp . Upnp works best with public ip that too preferred a static ip with no hassles of ddns. But all that is for advanced user with proper firewall protection
 
@popcorn A properly configured firewall on both network equipment and on client devices is good enough to mitigate the risks of UPnP on public IPv4.

I'm using RouterOS with UPnP fully enabled and IPv4 and IPv6 firewall configured as per documentation and expert suggestion.

I've been using UPnP for years, not a single security attack has occurred successfully.

I do not understand why people fear UPnP like it's a malware.
 
Last edited:
@Dark_Nate Issue is that any client application can forward a port as needed without any user or admin input. Say your PC or device is infected with malware, it can open a port and do whatever it wants. That is the risk.

Regarding ping over IPv6 from an external network, it definitely works, if it isn't it is definitely in your firewall rules.

Code: 
admin@ip-172-31-21-109:~$ ping -c 4 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a
PING 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a(2001:4490:4e4d:7b21:854f:fde:ceb9:d88a) 56 data bytes
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=1 ttl=44 time=116 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=2 ttl=44 time=116 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=3 ttl=44 time=105 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=4 ttl=44 time=118 ms

--- 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 105.296/113.847/117.716/4.982 ms
admin@ip-172-31-21-109:~$
 
@Dark_Nate
Adding to @varkey - The enable upnp is fine with ipv4 public ip and strong firewall as I mentioned earlier, but its purpose fails as soon as you are behind a ipv4 NAT with private IP to end devices. This creates packet losses specially during live streaming. Like majority users are ordinary users who whatsapp/video chat/ live stream zoom / meet, those will face loss of packets and the user experience will be jerky. The damage adds when there are many users on that same router who get private 192.168.x.x series ip from the main router which is upnp enabled.

In short the packets go to servers fine, comes back to your main router fine, but when they pass your router back to the specific device, that time it is lost if upnp is enabled. Streaming applications use mostly use a udp protocol and when packet is received, it will not verify the user who initiated the packet.
Unlike tcp, this packet is not resent and lost and next packet comes in. If lucky it may find the right destination and in this bargain a frame may be lost in case you are on a video chat.

IPV6 is different as the end public ip is assigned to the end user device. Hence this packet loss problem is not that relevant in ipv6. Only a strong firewall is required as you are already master in :)
 
@popcorn I'm not sure how that would happen. All that uPnP does is, create a firewall rule (port forwarding) automatically based on the request from the client application.

Perhaps a misconfig on your end or an implementation bug on the specific device you tried? I've never faced such an issue (and I've tried many different ISPs with CGNAT)
 
varkey said:
@Dark_Nate Issue is that any client application can forward a port as needed without any user or admin input. Say your PC or device is infected with malware, it can open a port and do whatever it wants. That is the risk.

Regarding ping over IPv6 from an external network, it definitely works, if it isn't it is definitely in your firewall rules.

Code: 
admin@ip-172-31-21-109:~$ ping -c 4 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a
PING 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a(2001:4490:4e4d:7b21:854f:fde:ceb9:d88a) 56 data bytes
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=1 ttl=44 time=116 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=2 ttl=44 time=116 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=3 ttl=44 time=105 ms
64 bytes from 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a: icmp_seq=4 ttl=44 time=118 ms

--- 2001:4490:4e4d:7b21:854f:fde:ceb9:d88a ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 105.296/113.847/117.716/4.982 ms
admin@ip-172-31-21-109:~$
Click to expand...
UPnP is perfectly safe if user takes basic security measures on their PCs and devices.

Regarding IPv6 on BSNL FTTH, I've spoken to NOC CGM in Bangalore via phone call, he said he'll look into it. The issue is BSNL is dropping/rejecting ICMPv6 packets and/or broken MTU/PMTU.

On my side, I disabled IPv6 firewall completely and still had the same issue. I discussed with Mikrotik veterans and they all say my firewall config is fine, it's the ISP's problem.
 
popcorn said:
@Dark_Nate
Adding to @varkey - The enable upnp is fine with ipv4 public ip and strong firewall as I mentioned earlier, but its purpose fails as soon as you are behind a ipv4 NAT with private IP to end devices. This creates packet losses specially during live streaming. Like majority users are ordinary users who whatsapp/video chat/ live stream zoom / meet, those will face loss of packets and the user experience will be jerky. The damage adds when there are many users on that same router who get private 192.168.x.x series ip from the main router which is upnp enabled.

In short the packets go to servers fine, comes back to your main router fine, but when they pass your router back to the specific device, that time it is lost if upnp is enabled. Streaming applications use mostly use a udp protocol and when packet is received, it will not verify the user who initiated the packet.
Unlike tcp, this packet is not resent and lost and next packet comes in. If lucky it may find the right destination and in this bargain a frame may be lost in case you are on a video chat.

IPV6 is different as the end public ip is assigned to the end user device. Hence this packet loss problem is not that relevant in ipv6. Only a strong firewall is required as you are already master in :)
Click to expand...
Whats a "strong firewall". How do i get/configure one :P
 
You must log in or register to reply here.

Similar threads

A
BSNL Broadband Installation is a torture
2
Replies
11
Views
5,620
icycool25
Back