MegaFon IP Ranges
MegaFon is one of Russia's national mobile operators, and AS31133 is one of many autonomous system numbers it holds. RIPE created the record on 5 March 2004 under the as-name MF-MGSM-AS, registered to PJSC MegaFon through the organisation handle ORG-OM1-RIPE, and the object is still actively edited, last modified on 12 August 2026. Its aut-num is a full RPSL routing policy rather than a stub, which makes it the most informative document MegaFon publishes about itself.
- Provider
- MegaFon
- Primary ASN
- AS31133
- Category
- ISP
- Headquarters
- Moscow, Russia
- Announced IPv4 prefixes
- 478
- Registry
- RIPE
Known IP ranges
These prefixes are currently announced to the global routing table by AS31133 (MF-MGSM-AS PJSC MegaFon). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
178.176.0.0/14
31.173.0.0/16
188.170.0.0/16
109.188.0.0/16
188.162.0.0/16
84.204.0.0/16
85.26.128.0/17
94.25.128.0/17
37.29.0.0/17
83.169.192.0/18
2a03:d000:2000::/36
2a03:d007:300::/40
2a03:d007:700::/40 (IPv6)
What does a MegaFon IP mean in a privacy test?
A MegaFon address as your visible IP means the traffic left through MegaFon in Russia rather than through a tunnel, but MegaFon is not one network and AS31133 is not the whole of it. The PeeringDB record for this ASN lists 29 autonomous system numbers as MegaFon-managed, 28 of them distinct and one of them AS31133 itself, and RIPE confirms that several sit under the same organisation handle ORG-OM1-RIPE as this one, including AS12714 MEGAFON-AS registered in July 2002 and AS25159 SONICDUO-AS registered a month later. What identifies the kind of connection is therefore the covering address object, not the ASN. RIPE holds labelled child objects beneath MegaFon's allocations, and inside 83.169.192.0/18 alone, 83.169.216.0/25 is netname MegaFon-GPRS while 83.169.200.0/25 is netname MF-PF-Fix, both ASSIGNED PA and each maintained by a different MegaFon team. A lookup that stops at the parent allocation has not told you whether you are looking at mobile or fixed access.
MegaFon's routing policy and address records in RIPE
The most substantial thing MegaFon publishes is its aut-num object, which runs to several hundred import: and export: statements organised by remarks: section headers that name each interconnect in turn: Upstreams, then AMS-IX, DE-CIX, DATA-IX, MSK-IX and NETNOD-IX, then a run of regional Russian exchanges each marked as being for CDN MegaFon, namely NSK-IX, EKT-IX, VLV-IX, KZN-IX, SMR-IX, SPB-IX and RND-IX, and finally Peers and Clients. Read as a document it tells you which exchanges MegaFon treats as CDN delivery points as opposed to general peering, which no third-party list will tell you. PeeringDB gives the IRR as-set as RIPE::AS-MF-MGSM and lists the further ASNs the group manages in its notes field.
On the address side the netname carries information most operators do not put there: MegaFon's allocations are named RU-MEGAFON- followed by a date. 178.176.0.0/14 is RU-MEGAFON-20100122 and its object was created 2010-01-22; 83.169.192.0/18 is RU-MEGAFON-20040420, created 2004-04-20. The convention is useful but not infallible, since 31.173.0.0/16 is named RU-MEGAFON-20110404 while its object carries a created date of 2014-10-16, the record having been recreated later. All three are ALLOCATED PA under MEGAFON-RIPE-MNT. Beneath them MegaFon maintains child objects down to /25 handed to individual branch maintainers such as MF-VLG-MNT, and it delegates its reverse zones in the same database, with 196 in-addr.arpa domain objects covering the single /14 at 178.176.0.0, all pointing at rev-ns1.megafon.ru, rev-ns2.megafon.ru and rev-ns3.megafon.ru under MEGAFON-DNS-MNT. What is absent is a geofeed: no geofeed: attribute appears on the allocations, so the branch and service names in the child objects are MegaFon's most specific published statement of where a block is used.
Telling a MegaFon subscriber pool from MegaFon's own network
Start with the child object rather than the hostname. MegaFon delegates its reverse zones properly, with 196 in-addr.arpa objects registered for one /14 and all pointing at its own nameservers, but the zones are largely empty in practice and sampled addresses such as 178.176.0.1 and 109.188.100.100 return NXDOMAIN. The RIPE child objects do the work instead, and they are unusually informative. A lookup on 83.169.216.5 does not return the /18 allocation; it returns a /25 with netname: MegaFon-GPRS, status: ASSIGNED PA, technical contact MegaFon PJSC GNOC West. A lookup on 83.169.200.1, inside the same /18, returns a different /25 with netname: MF-PF-Fix under the branch maintainer MF-VLG-MNT.
That pair is the whole method. Two /25s carved out of the same /18, one named for GPRS and one named for fixed service, each with its own maintainer, and nothing at the /18 level or in the routing table distinguishes them. So if you need to know whether a MegaFon address was a handset or a fixed line, query the address rather than the prefix and read the netname and the maintainer on whatever object comes back. A bare allocation with no child object beneath it is unassigned or core space and identifies nobody. And because the group announces from many numbers, resolve which MegaFon ASN originates the covering prefix before assuming this one did; a log tool that reports only the holder name will collapse all of them into MegaFon.
Related tools
Frequently asked questions
What IP ranges does MegaFon use?
The blocks listed above are the largest currently announced under AS31133. They are registered with RIPE to PJSC MegaFon under the organisation handle ORG-OM1-RIPE, with netnames of the form RU-MEGAFON followed by a date, and are maintained under MEGAFON-RIPE-MNT alongside the RIPE NCC hostmaster maintainer.
Why does a MegaFon address appear in my privacy test?
Because the request left over a MegaFon connection in Russia rather than through a tunnel. If you expected a VPN exit, the tunnel is not carrying that traffic. It is worth checking the covering registry object before assuming which kind of connection produced it, because MegaFon labels mobile and fixed space differently at the child-object level and not at the ASN level.
Is AS31133 the only MegaFon network number?
No, and it is not close. MegaFon's own PeeringDB record lists 29 autonomous system numbers as group-managed, which is 28 distinct numbers once a duplicated entry is removed, and AS31133 is itself one of them. RIPE confirms that several are registered to PJSC MegaFon under the same organisation handle ORG-OM1-RIPE as this one, among them AS12714 MEGAFON-AS and AS25159 SONICDUO-AS, both registered in 2002.
What do MegaFon netnames like RU-MEGAFON-20100122 mean?
The trailing digits are a date written as year, month and day. Two of the blocks above check out against their object creation dates exactly, 178.176.0.0/14 against 22 January 2010 and 83.169.192.0/18 against 20 April 2004. The convention is not perfectly reliable, because some objects were recreated later than the date in the name: one /16 is named for April 2011 but carries a created date in October 2014. Treat the netname as the original allocation date and the created field as the date of the current record.
Does MegaFon publish a geofeed?
No. There is no geofeed attribute on its RIPE allocations pointing at an RFC 8805 file. The nearest substitute MegaFon does publish is inside the registry itself: the child objects beneath each allocation are named for the service or branch that operates them and are maintained by that branch, which is a coarser but operator-authored statement of where the addresses are used.