Bezeq International IP Ranges
Bezeq International is the international and business arm of Israel's Bezeq group, and AS8551 is the number its backbone announces under, registered with RIPE as BEZEQ-INTERNATIONAL-AS with the plain description Bezeqint Internet Backbone. Its largest allocation, 82.80.0.0/15, was created on 12 May 2003 under the netname IL-BEZEQ-INTERNATIONAL-20030512. Since Israel's Ministry of Communications cancelled the regulatory split between infrastructure providers and ISPs in 2022 and the company closed its private-customer division, the mix of what sits on this space has moved toward business circuits and hosting.
- Provider
- Bezeq International
- Primary ASN
- AS8551
- Category
- ISP
- Headquarters
- Petah Tikva, Israel
- Announced IPv4 prefixes
- 857
- Registry
- RIPE
Known IP ranges
These prefixes are currently announced to the global routing table by AS8551 (BEZEQ-INTERNATIONAL-AS Bezeq International Ltd.). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
82.80.0.0/15
62.219.0.0/16
81.218.0.0/16
212.179.0.0/16
31.168.0.0/16
79.179.0.0/18
109.67.0.0/18
212.179.0.0/18
79.181.0.0/18
79.177.0.0/18
2a10:8000::/27
2001:4cd0::/29
2a10:8004::/32 (IPv6)
What does a Bezeq International IP mean in a privacy test?
AS8551 puts a session in Israel and on Bezeq International specifically, which is a narrower statement than it first looks. The registry is more useful here than the geofeed, because the company writes the role into its own objects: route descriptions on 82.80.0.0/15 run from a bare BEZEQINT through BEZEQINT-CUST with a second descr line reading ADSL-LAN, and 82.80.246.0 to 82.80.255.255 is a separate ASSIGNED PA inetnum whose netname is BEZEQINT-HOSTING. One ASN therefore covers a subscriber line, a sub-allocated business customer and a rented server, and a leak test should read those three very differently. One entry worth knowing about is 82.80.10.0/24, whose route object is labelled BEZEQINT-HONG-KONG on Israeli-registered space, which is the kind of thing that makes a whois lookup and a commercial geolocation database disagree about the same address. Nothing here is a VPN exit by default, but the hosting inetnum is where one could plausibly sit.
Where Bezeq International publishes its address data
The company registers a geofeed in the RIPE database itself: the allocation object for 82.80.0.0/15 carries a geofeed: line pointing at https://media.bezeqint.net/geofeed.csv, which is the RFC 8805 way of saying the operator will state where its own blocks are used. The file is served as plain CSV, runs to a few hundred rows, and is deliberately coarse: each row is a prefix followed by a single country code, so a line reads 31.168.0.0/20,IL and the file ends on 85.130.128.0/17,IL. RFC 8805 allows two further fields after the country, an ISO 3166-2 region and a city, and Bezeq International leaves both empty on every row.
The second source is the routing policy, and it is unusually complete. The aut-num for AS8551 was last modified on 7 July 2025, is maintained under AS8551-MNT, and holds dozens of RPSL import and export lines naming individual peers, with the set AS-BEZEQINT exported at DE-CIX Frankfurt and LINX London; the PeeringDB record nominates the same set and calls the policy selective. The contact addresses in these objects do not share one domain, which is worth knowing before you send anything: peering goes to peering@bezeqint.co.il and network questions to networkingisp@bezeqint.co.il, while the allocation's own remark asks that abuse complaints go only to abuse@bezeqint.net. What none of it covers is which customer holds a given sub-allocation, so for that you drop to the more specific inetnum and the descr on the covering route object.
Subscriber line, customer block, or hosted machine
Bezeq International writes the role into its own objects instead of leaving them blank, so the covering record is the fastest separator on this network. A bare BEZEQINT descr marks general access space; BEZEQINT-CUST, which carries a second descr line reading ADSL-LAN, marks space handed to a customer; and 82.80.246.0 - 82.80.255.255 is not a route label at all but a distinct ASSIGNED PA inetnum named BEZEQINT-HOSTING, maintained under AS8551-MNT. Reverse DNS lines up with that split rather than restating it: hostnames take the form bzq- plus the octets plus a middle label, and the observed labels differ by role, with bzq-84-111-82-182.red.bezeqint.net on access space, bzq-179-65-82.cust.bezeqint.net on customer space, and bzq-82-80-249-158.dcenter.bezeqint.net on an address that falls inside the BEZEQINT-HOSTING inetnum. The label tells you the pool, never the individual line.
Inbound reachability follows the same division. Access pools behave like any consumer broadband, reachable only if the line is configured for it and reassigned between subscribers, while the customer and hosting records are sub-allocated and exist to answer, so an inbound connection from AS8551 is more likely a server than a household. That has become more true since 2022, when Israel's Ministry of Communications cancelled the split between infrastructure providers and ISPs, subscribers began buying internet as a single product from one company, and Bezeq International closed its private-customer ISP division and cut about half its workforce. Read the covering record before calling any AS8551 address residential.
Related tools
Frequently asked questions
What IP ranges does Bezeq International use?
They are announced under AS8551, registered with RIPE as BEZEQ-INTERNATIONAL-AS. The largest allocation, 82.80.0.0/15, was created on 12 May 2003 under the netname IL-BEZEQ-INTERNATIONAL-20030512. The full per-prefix list the company stands behind is the geofeed it links from its own RIPE record at media.bezeqint.net/geofeed.csv.
Does Bezeq International publish a geofeed?
Yes. Its RIPE allocation record carries a geofeed attribute pointing at media.bezeqint.net/geofeed.csv, and the file is a two-column list: a prefix and the country code IL. RFC 8805 allows a region and a city after the country, and Bezeq International leaves both blank on every row, so the file settles the country and nothing finer.
What does a Bezeq International address mean in a leak test?
AS8551 puts a session in Israel and on Bezeq International specifically, which is a narrower statement than it first looks. The registry is more useful here than the geofeed, because the company writes the role into its own objects: route descriptions on 82.80.0.0/15 run from a bare BEZEQINT through BEZEQINT-CUST with a second descr line reading ADSL-LAN, and 82.80.246.0 to 82.80.255.255 is a separate ASSIGNED PA inetnum whose netname is BEZEQINT-HOSTING. One ASN therefore covers a subscriber line, a sub-allocated business customer and a rented server, and a leak test should read those three very differently. One entry worth knowing about is 82.80.10.0/24, whose route object is labelled BEZEQINT-HONG-KONG on Israeli-registered space, which is the kind of thing that makes a whois lookup and a commercial geolocation database disagree about the same address. Nothing here is a VPN exit by default, but the hosting inetnum is where one could plausibly sit.
Why does a Bezeq International address geolocate to the wrong city?
Because the operator never states a city. Its geofeed gives a country code only, so any city a lookup shows came from a commercial database's own inference rather than from Bezeq International. Sub-allocated and hosting space drifts furthest, and one prefix on this Israeli-registered range, 82.80.10.0/24, is labelled BEZEQINT-HONG-KONG in the routing registry.
Is an AS8551 address a home line or a server?
Check the record covering it. A bare BEZEQINT descr is access space, BEZEQINT-CUST with an ADSL-LAN line is customer space, and 82.80.246.0 to 82.80.255.255 is its own inetnum named BEZEQINT-HOSTING. Reverse DNS agrees: the middle label reads red, cust or dcenter depending on which of the three the address sits in.