user@netcalc ~/calc $
ipv4_calculator
Calculate network, broadcast, mask, hosts, class and binary for any IPv4 address
ip:
mask:
✓ stdout — ipv4_calculator
Enter runs the calculation · Shift+Enter inserts a new line
user@netcalc ~/calc $
ipv6_calculator
Calculate network info for IPv6 addresses in CIDR notation
ipv6:
pfx:
✓ stdout — ipv6_calculator
user@netcalc ~/calc $
vlsm_calculator
Variable Length Subnet Mask — assigns optimal blocks for each network segment
net:
pfx:
// Subnets required
name:
hosts:
name:
hosts:
name:
hosts:
✓ stdout — vlsm_calculator
| # | Name | Hosts Req | Hosts Avail | Prefix | Network | First Host | Last Host | Broadcast | Mask |
|---|
user@netcalc ~/calc $
usable_ip_range
Shows the exact usable host range for a given network
ip:
mask:
✓ stdout — usable_ip_range
user@netcalc ~/calc $
binary_ip_calc
Convert IP addresses to binary and vice versa, with per-octet visualization
dec:
bin:
✓ stdout — binary_ip_calc
user@netcalc ~/network $
cidr_converter
Convert between CIDR, decimal mask and wildcard. Includes full /1–/32 reference table.
in:
✓ stdout — cidr_converter
📋 CIDR Reference Table
| CIDR | Subnet Mask | Wildcard | Hosts | /24 subnets | Block |
|---|
user@netcalc ~/network $
wildcard_mask_calc
Calculate the wildcard (inverse) mask for Cisco ACLs, OSPF and firewall rules
mask:
✓ stdout — wildcard_mask_calc
user@netcalc ~/network $
supernet_calculator
Find the minimum supernet containing all specified networks (route summarization)
nets:
✓ stdout — supernet_calculator
user@netcalc ~/network $
subnet_splitter
Split a network into equal subnets by specifying a new prefix
net:
mask:
new:
✓ stdout — subnet_splitter
| # | Network | First Host | Last Host | Broadcast | Hosts | Mask |
|---|
user@netcalc ~/network $
range_to_cidr
Convert an IP range (start–end) to the minimum set of CIDR blocks
start:
end:
✓ stdout — range_to_cidr
| # | CIDR Block | Network | Broadcast | Hosts |
|---|
user@netcalc ~/network $
ip_to_integer
Convert IPv4/IPv6 addresses to integer and vice versa
ip:
int:
✓ stdout — ip_to_integer
user@netcalc ~/network $
ipv6_normalize
Expand and compress IPv6 addresses — normalize any valid format
ipv6:
✓ stdout — ipv6_normalize
user@netcalc ~/network $
hex_ip_converter
Convert between hexadecimal and IP address — useful for Windows route tables and Cisco logs
ip:
0x:
✓ stdout — hex_ip_converter
user@netcalc ~/network $
vlan_calculator
802.1Q VLAN info: tag encoding, PCP, DEI, VID, range and compatibility
vlan:
pcp:
dei:
✓ stdout — vlan_calculator
user@netcalc ~/dns $
reverse_dns_generator
Generate the PTR in-addr.arpa zone for an IPv4 network
net:
pfx:
dom:
✓ stdout — reverse_dns_generator
user@netcalc ~/dns $
ipv6_ptr_generator
Generate the PTR ip6.arpa record for an IPv6 address
ipv6:
host:
✓ stdout — ipv6_ptr_generator
user@netcalc ~/dns $
ip_geolocation
Locate a public IP or resolve a domain and geolocate its public address
Domains are resolved through DNS first; geolocation is based on the resulting public IP.
geo:
✓ stdout — ip_geolocation
user@netcalc ~/dns $
ip_address_planner
Interactive IP address space planner — click cells to edit, export to CSV
📋 IP Address Plan
| # | Name | Network | Mask/CIDR | Gateway | VLAN | Location | Notes |
|---|
user@netcalc ~/legal $
Privacy
Data stored in your browser
Theme, language, promotion dismissal and calculation history are stored in localStorage on this device.
Calculations
Calculations are sent through this site's same-origin Worker proxy to the private calculation service.
Performance metrics
LCP, CLS and INP may be stored as aggregate performance measurements by tool and language. Calculation inputs and persistent user identifiers are not included.
GeoIP
Only GeoIP lookups are processed by an external provider. The requested IP address is sent for that lookup.
Issue reports via Telegram
A report link opens the public Telegram bot and includes only the current page slug in the bot start parameter. Calculator inputs and report text are not sent by this website. Text you choose to send inside Telegram is handled by Telegram and the bot.
Cookies and advertising
Advertising is controlled by the production configuration. When Google AdSense is enabled, consent is handled through a certified CMP before personalized advertising is used where required.
Delete local data
Use the button below to clear calculation history. To remove every local preference, clear this site's data in your browser settings.
This page provides operational information; it is not a legal-compliance certification.
WireGuard handshakes but no traffic: a practical troubleshooting path
Trace routes, AllowedIPs, MTU, firewall state and return paths when a WireGuard tunnel handshakes successfully but applications still fail.
01
A handshake proves identity, not reachability
A recent WireGuard handshake proves that the peers exchanged authenticated packets. It does not prove that the protected prefixes are routed correctly, that return traffic knows the tunnel, or that a stateful firewall permits the inner flows. Treat the handshake as the beginning of the forwarding diagnosis, not the end.
02
Check AllowedIPs as both policy and route intent
AllowedIPs controls which destinations are sent to a peer and which source prefixes are accepted from that peer. Overlapping entries, missing remote LANs or a default route assigned to the wrong peer can produce a healthy handshake with zero useful traffic. Compare both ends rather than reading only one configuration.
03
Prove the forward and return paths separately
Trace the destination from the source router, then inspect how the remote endpoint would return to the original source. A route that exists only in one direction often looks like packet loss inside the tunnel even though the real defect is ordinary routing outside it.
04
Test MTU after routing is correct
If small pings work but HTTPS, file transfers or some applications stall, calculate the tunnel MTU and test packet sizes deliberately. WireGuard adds UDP and encryption overhead, and an already-reduced underlay such as PPPoE can leave the inner path in the low 1400s.
05
Inspect firewall zones and NAT after routing
Once routes are correct, verify that the tunnel interface is in the expected firewall zone and that NAT rules do not rewrite traffic unexpectedly. A peer can decrypt a packet and still drop it immediately because forwarding between zones is denied.
06
Check for overlapping remote networks
If the remote prefix is also considered local on the source side, the host may ARP locally instead of sending the packet to the tunnel gateway. This is common when both sites use popular RFC1918 ranges.
07
Keep the working proof with the tunnel configuration
Document AllowedIPs, effective MTU, route table and one successful end-to-end test. That turns the next incident from “WireGuard is broken” into a short comparison against a known-good baseline.
EX
Worked example
- Confirm a recent handshake, then ping the remote tunnel address.
- Check that the remote LAN is present in AllowedIPs and in the routing table on the correct peer.
- Trace the return path from the remote router back to the original source subnet.
- If only larger flows fail, calculate MTU and test DF-sized packets.
✓
Operational checklist
- Handshake is recent.
- AllowedIPs are non-overlapping and complete.
- Forward and return routes both exist.
- Firewall forwarding and NAT are deliberate.
- MTU is validated with real traffic.
Tools to apply it
Standards and references
🕐 History