0

In my company's VPN app we have a disable-able feature which excludes below List of non-web-site IP-address ranges from being routed into the VPN server.

This allows local-net Apps to continue working even if the VPN is active, and in addition, some Anti-VPNs check these addresses (to see if VPN is active or not).

My qustion is, is there any IP-range we should add and/or remove from the list?

In addition, mentioning related RFC would be helpful, but not required.

WARNING: adding too much to List means leaking Web-site packets, and removing too much means local-net Apps may not work.

List:

Legend:

  • For example, the {172,16,0,0 , 12}, entry means 172.16.0.0/12.
  • Where, first 4 fields of MyType specify the IP address's base.
  • The 5th field specifies the "mask".

Entries:

MyType localSubnets[] = { // Address ranges below are reserved by IANA for private intranets, // and not routable to the Internet // (For additional information, see RFC 1918). {10,0,0,0 , 8}, {10,170,60,224 , 27}, {172,16,0,0 , 12}, {192,168,0,0 , 16}, // Reserved and special use addresses: {0,0,0,0 , 8}, // Current network (only valid as source address) RFC 1700 {127,0,0,0 , 8}, // Loopback IP addresses (refers to self) RFC 5735 {192,0,0,0 , 24}, // Reserved (IANA) RFC 5735 {192,88,99,0 , 24}, // IPv6 to IPv4 relay. RFC 3068 {198,18,0,0 , 15}, // Network benchmark tests. RFC 2544 {198,51,100,0 , 24}, // TEST-NET-2. RFC 5737 {203,0,113,0 , 24}, // TEST-NET-3. RFC 5737 {224,0,0,0 , 4}, // Reserved for multicast addresses. RFC 3171 // Reserved (former Class E network) RFC 1700 {255,255,255,255 , 32} // Broadcast address (limited to all other nodes on the LAN) RFC 919 }; 

2 Answers 2

1

You can consider to add:

  • 169.254.0.0/16 - RFC 3927 - The block designed for local-link addresses. These addresses are automatically assigned to devices on local network when DHCP server is unavailable. They have limited scope and are not routable beyond the local network segment
  • 240.0.0.0/4 - This block is reserved for future purposes and should not be used for any current applications (IANA IP Address Space Registry)
  • 64.44.0.0/16 - RFC 6459 - Used for Private Use for Carrier-grade NAT. This block allows service providers to create private address spaces for their customers behind a large NAT device.
  • 100.64.0.0/10 - RFC 6598 - Designated for Shared Address Space for Carrier-grade NAT. This allows multiple service providers to share a pool of addresses for their customers behind NAT devices.
  • 233.252.0.0/14 - RFC 791 - Multicast for Local Scope. It allows for efficient communication within a local network segment without needing individual routing for each device
  • 239.255.0.0/16 - RFC 3171 - this block is designated for limited-scope multicast addresses. These addresses are used for specific purposes like service discovery within a local network.
2
  • I will accept this later, because some people don't bother answering if there is something already accepted. Commented Mar 8, 2024 at 5:38
  • The 64.44.0.0/16 (CGNAT) allows ISP's local to catch and redirect to internet (instead of providing real public-IP-addresses to customers), however, our App targets normal-user's LAN, not ISP's LAN, else would add CGNAT to our exclude-list, but maybe will add a separate check-box to exclude CGNAT as well. Commented Apr 22, 2024 at 7:00
0

I think OP should add 169.254.203.0/24 to said list, like:

{169,254,203,0 , 24}, // Link-local address. 

Note that I am the OP'er, but was yet not sure enough to add it to the list.

1
  • As the other answer(s) mentioned, the correct notation is 169.254.0.0/16 - however, may not delete this for historical reasons. Commented Mar 8, 2024 at 5:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.