Understanding Network Infrastructure · Part 5 · Connecting the enterprise network to branches, clouds, and the Internet

How do enterprise networks connect to branches, clouds and the internet?

A working office network does not automatically make services at a branch or in the cloud accessible. The two networks need more than a link between them: their addresses must not overlap, traffic needs routes in both directions, and access policies must allow it through. Following a PC at headquarters as it connects to branch and cloud servers, we examine what both sides need to check beyond the campus boundary.

Address assignment and route advertisement are separate steps↑

Being assigned a public address does not tell every router on the internet how to reach it. The right to use an address and the process of advertising a route to its prefix are separate matters. Private addresses also need to be planned so they do not overlap across networks that will be connected.

Different organizations can each use the same private address space. A problem arises if headquarters and a newly connected branch both use 10.0.0.0/24. A headquarters PC may treat the branch's 10.0.0.10 as a device on its own local network. If headquarters also has a device with that address, the destination address alone cannot distinguish them. A faster link or enabling BGP does not resolve this ambiguity.

Before connecting the equipment, compare the two networks' enterprise private address plans. Our example uses distinct prefixes: 10.0.0.0/24 at headquarters, 10.30.0.0/24 at the branch and 10.40.0.0/24 in the cloud. A real plan must account for additional branches and services, not just current use. If overlapping networks must be joined, consider renumbering or limited address translation. Also examine how translation would affect name resolution, access policies and operational records.

For public addresses, check registration and delegation relationships and who is responsible for advertising routes. A small office may use a public address and default route supplied by its carrier, while the carrier advertises a prefix containing that address to the internet. An organization using multiple carriers and managing policy for its own prefix may need separate agreements and route exchange. Which registry records an address and which network advertises it on the internet are different questions.

The same distinction applies when creating a cloud server. Check, in order, that a private address has been assigned, connectivity to the other network is ready, and routes and access rules are in place. Connection requirements differ between cloud services, so a generic diagram cannot be copied directly into configuration commands. See public IP address allocation for the delegation hierarchy, and the BGP article for route selection.

Sources: RFC 1918 — private addressing and merging networks; IANA — Internet number resources.

Trace outbound packets and return packets separately↑

A route from headquarters to the branch is not enough to receive a response. The branch server also needs a route back to the headquarters PC, with policies on both sides permitting the traffic. Checking how far the request reached and how far the response returned makes it easier to locate the direction and segment where communication failed.

Suppose headquarters PC 10.0.0.25 sends a request to branch server 10.30.0.10. The PC uses the gateway's MAC address to build the frame, but the IP destination is the branch server. A router looks up the branch route for that destination and forwards the packet to the next hop. In ordinary IP routing, the link header changes as required at each hop. Unless a separate function such as NAT is applied, the final destination IP address stays the same. The headquarters PC does not look up the MAC address of the branch server across the internet.

With a VPN tunnel, the original packet may be carried inside an outer packet used to cross the tunnel. Distinguish the business addresses at headquarters and the branch, the tunnel endpoint addresses, and the path across the internet. After the branch device finishes tunnel processing, it still needs to forward traffic to the server and check policy. Test connectivity between the tunnel endpoints separately from the business traffic carried inside it.

For the response, the branch server uses a route to 10.0.0.25. If the branch router has no route to the headquarters prefix, the response may take another exit or be dropped along the way. The return path does not have to use the same physical links as the request. However, if traffic passes through a firewall that checks connection state or through NAT, the device receiving the response must have the required state and mappings. Redundant devices do not remove the need to verify that condition.

NAT is not always necessary for this connection between private networks. If the addresses do not overlap, each side is reachable and policy permits the traffic, the design can retain the original addresses. If translation is used for internet access or to resolve overlapping addresses, record the values before and after translation. Different addresses in two captures do not necessarily indicate different communications. Compare mappings and timestamps to match the same request and response.

Sources: RFC 1812 — packet forwarding; RFC 4301 — IPsec security architecture; RFC 3022 — bidirectional NAT translation.

BGP: decide which routes to exchange, and with whom, before enabling it↑

Connecting to an external network does not make BGP necessary at every site. A single exit and a simple set of destination prefixes may be served by default or static routes. First decide whether routes can be managed manually or whether route changes need to be exchanged automatically with the other network. If you need direct control over which routes are accepted and advertised, also assess how to implement that policy.

For example, a default route may be sufficient when headquarters reaches the internet through one carrier. Static routes may suit a headquarters-to-branch connection with a small number of prefixes that rarely change. Dynamic route exchange can be useful when multiple carriers advertise the same destination or when route selection must respond to changes and failures. Some connectivity services require BGP, however, so check both the organization's needs and the provider's technical requirements.

With BGP, the checks continue after a session is established. Define the prefixes to accept from the peer, the prefixes to advertise, the preferred exit and policies to reject unexpected routes. An established session does not make every route usable. A received route may not be used for forwarding if policy rejects it or its next hop is unreachable. The article on BGP path selection examines this distinction in detail.

Needing routes from both internal OSPF and external connections does not mean every route should be exchanged between them. First decide whether a default route is sufficient or whether only specific prefixes are needed. If redistribution is required, control its scope and route origins, and prevent routes passed into another routing system from being fed back into the original system. Route redistribution and route tags are easier to understand at this boundary between different routing systems.

Once the connection is in place, test real business requests and responses at headquarters, the branch and the cloud. Also test that unauthorized access is blocked. Record link and tunnel failure scenarios, the capacity of the remaining paths and the conditions for rolling back a change. The roles, capacity requirements and failure boundaries established in campus design extend beyond internal equipment to connections with external providers. These records let you assess the business impact when addresses or routes change.

Sources: RFC 1812 — inter-network connectivity without an exterior routing protocol and static routing; RFC 4271 — BGP route exchange and selection.

Glossary↑