Skip to main content

Lab 2 - Addressing, Routing and NAT

image.png

The purpose of this lab is to understand the traffic flow before we build the VPN: what gets routed locally, what gets PAT/NATed to the LTE public IP, and what must later remain un-NATed so IPsec can carry it between sites.

Our addressing is already fixed:

  Site 1 Site 2
Data VLAN 1 172.16.10.0/24 172.17.10.0/24
Voice VLAN 100 172.16.20.0/24 172.17.20.0/24
Data gateway 172.16.10.1 172.17.10.1
Voice gateway 172.16.20.1 172.17.20.1
WAN DHCP via LTE/relayd DHCP via LTE/relayd

The UC540 is doing normal Layer-3 routing between its local BVIs, while Internet traffic exits Fa0/0 and is translated to the LTE WAN address. In CCA, open:

Configure → Security → NAT

Make sure FastEthernet0/0 is still the Outside interface. Do not change anything yet. Cisco CCA manages UC500 NAT from this page.

image.png

Now check the actual IOS NAT configuration on both UC540s:

image.png

image.png

The inside interfaces are the BVIs, while Fa0/0 is ip nat outside. The factory configuration follows exactly this design.

So today, Internet traffic behaves like this:

172.16.10.x
      |
     BVI1
      |
     UC540
      |
      | NAT/PAT
      v
Fa0/0 public LTE IP
      |
   Internet

The same applies to the Voice VLAN if it needs Internet access. The important VPN concept is the opposite. When Site 1 later sends traffic toward Site 2, we must preserve the original private addresses:

172.16.10.x  --->  172.17.10.x

We do not want:

Public-LTE-IP  --->  172.17.10.x

because the IPsec crypto policy is built around the original protected subnets. With IOS PAT, VPN traffic normally needs to be excluded from NAT before encryption; Cisco documents this using a NAT-exemption ACL/route-map design.

For the standard CCA Multisite Manager workflow we are going to use later, CCA focuses on the UC500 Data VLAN when defining the site-to-site VPN. Cisco's Multisite Manager explicitly reads each site's Data VLAN address and subnet and uses that as the internal addressing for VPN configuration.

So for now, do not manually create any NAT exemption. We only want to understand and record the current NAT state before CCA modifies it during the multisite/VPN configuration.

Current NAT behavior

Both sites use the same PAT design:

ip nat inside source list 1 interface FastEthernet0/0 overload

So any source network permitted by ACL 1 is translated to the address currently assigned to FastEthernet0/0.

Site 1

ACL 1 contains:

10 permit 172.16.20.0 0.0.0.255
20 permit 172.16.10.0 0.0.0.255
30 permit 10.1.10.0 0.0.0.3

Therefore NAT currently applies to:

  • 172.16.10.0/24 — Data VLAN 1
  • 172.16.20.0/24 — Voice VLAN 100
  • 10.1.10.0/30 — internal CUE/ServiceEngine network

Site 2

Identical conceptually, using its 172.17.x.x networks.

Inside and outside interfaces

Both routers correctly report:

Outside:
  FastEthernet0/0

Inside:
  Integrated-Service-Engine0/0
  BVI1
  BVI100
  Loopback0

This matches the UC540 architecture we discussed earlier:

BVI1       → Data LAN
BVI100     → Voice LAN
Loopback0/
ServiceEngine → CUE

        UC540 routing/NAT

Fa0/0      → LTE WAN

Everything leaving the internal networks toward the Internet can therefore be PATed through Fa0/0. Site 2 is the clearest example to see PAT working (I started a ping to 8.8.8.8 from Windows XP PC on data network):

Inside local             Inside global
172.17.10.10:512   →     5.205.126.177:512

So the LTE address is reaching the UC540 itself through your OpenWrt/relayd setup exactly as intended. Site 1 simply had no active NAT translation at the instant I ran the command, but it already shows NAT hits and expired translations, so NAT has been used successfully there as well.

Routing

Both UC540s also have a DHCP-learned default route.

Site 2:

0.0.0.0/0 via 5.205.126.178

Site 1:

0.0.0.0/0 via 176.82.173.65

The [254/0] is normal for a default route installed by DHCP: administrative distance 254, metric 0. So Internet routing is already complete.

What changes once we build the VPN

This is the key concept of Lab 2.

Today this traffic:

172.16.10.x → Internet

gets translated:

172.16.10.x → Site 1 public LTE IP

That is correct. But later, traffic such as:

172.16.10.x → 172.17.10.x

must not be translated. IPsec needs to see the original private networks:

172.16.10.0/24 ↔ 172.17.10.0/24

So the final design becomes:

Destination = Internet
        ↓
       NAT
        ↓
Public LTE address


Destination = Other site
        ↓
     NO NAT
        ↓
      IPsec
        ↓
Remote private subnet

Your current NAT rule does not yet distinguish by destination because ACL 1 is a standard ACL and only matches the source address. That is fine right now. When we configure the site-to-site VPN, the NAT configuration must be adapted so VPN traffic is exempted while ordinary Internet traffic continues to be PATed.

Also, those ACL 104 messages such as:

%SEC-6-IPACCESSLOGP: list 104 denied tcp ...

are just unsolicited packets arriving from the public Internet and being blocked on the WAN interface. They are unrelated to the NAT/VPN problem.


Back to top