NAT

Network Address Translation (NAT) modifies address information inside packet headers while traffic is in transit. In NexappOS, NAT primarily enables private hosts to access public networks using one or more public IP addresses.

By default, all local hosts access the internet through masquerading. Masquerade is a NAT form that automatically rewrites the source address of outbound packets to the WAN IP address of the NexappOS unit. As a result, external services see traffic as originating from the unit’s public IP.

---

NAT Page Overview

Open:

• Firewall → NAT

The NAT page contains two tabs:

1. Rules and NETMAP
2. NAT Helpers

All NAT rules apply to every network protocol, unless a rule explicitly limits traffic by source/destination/protocol.

Note
Destination NAT (DNAT), commonly used to expose internal services, is configured in Firewall → Port Forward.

---

Rules and NETMAP

This tab lets you configure these rule types:

• Source NAT (SNAT)
• Masquerade
• Accept (Disable NAT / No-NAT)
• Netmap (1:1 network mapping)

---

Source NAT (SNAT)

SNAT rewrites the source IP of outbound packets.
It is commonly used when you want a specific internal host to always exit through a specific public IP.

Example Use Case

Scenario
You have two public WAN IPs. You want your internal mail server to always send traffic from a dedicated public IP to improve reputation and sender policies.

• Internal mail server: 192.168.1.33
• Dedicated public IP: 1.2.3.4

Problem
Without SNAT, your mail server shares the same WAN IP as the rest of the network, which can hurt email reputation.

Solution 1. Configure the alias public IP (1.2.3.4) on your WAN interface. 2. Create an SNAT rule:

• Source address: 192.168.1.33
• Translation address: 1.2.3.4
• Outbound zone: WAN
• Action: SNAT

Result
All outbound traffic from the mail server uses only the dedicated public IP.

---

SNAT in a MultiWAN Scenario

If multiple WANs exist and SNAT translates to a specific WAN public IP, you must also ensure routing uses the same WAN.

Steps: 1. Create a custom MultiWAN policy containing only the WAN tied to the SNAT public IP. 2. Add a MultiWAN rule: - Source address: internal host IP
- Destination: any
- Protocol: any
- Policy: custom policy created above

This guarantees traffic exits through the correct WAN.

---

Masquerade

Masquerade rewrites outbound traffic so it appears to originate from the NexappOS outbound interface IP.

Masquerading is: - enabled by default for local traffic to WAN - also useful for VPN-to-LAN access scenarios

Example Use Case

Scenario
A VPN subnet (example 192.168.7.0/24) needs to reach a LAN host that has no default gateway configured.

Problem
The LAN host cannot reply because it doesn’t know how to route back to VPN subnet.

Solution Create a NAT rule:

• Source: VPN network (192.168.7.0/24)
• Destination: LAN network (192.168.1.0/24)
• Outbound zone: empty / any
• Action: MASQUERADE

Result
LAN hosts see VPN traffic as coming from NexappOS, so replies work normally.

---

Accept (Disable NAT / No-NAT)

An ACCEPT NAT rule disables translation for matching traffic.
This is useful when you must preserve original private IPs for routing or tunnel policies.

Example Use Case

Scenario
Your NexappOS unit sits behind another router that routes traffic into private remote networks via CDN or IPsec tunnels.

Problem
Masquerading hides local IPs, so the upstream router doesn’t match tunnel policies.

Solution Create a NAT rule:

• Source: local LAN (192.168.1.0/24)
• Destination: remote private network (192.168.50.0/24)
• Action: ACCEPT

Result
Traffic keeps original LAN IPs and matches upstream routing policies correctly.

---

Netmap (1:1 Network Translation)

Netmap performs 1:1 translation of an entire subnet without changing the last host octet.
It is especially useful when two sites have overlapping networks.

Example Use Case (Overlapping Networks)

Two sites both use 192.168.1.0/24, connected by VPN.

Translate each site into a non-overlapping alternative:

• Site A real: 192.168.1.0/24 → ALT_A: 10.1.1.0/24
• Site B real: 192.168.1.0/24 → ALT_B: 10.2.2.0/24

A host in Site A (real 192.168.1.10) reaching Site B host (real 192.168.1.20) must target: - 10.2.2.20 (ALT_B)

Before leaving Site A firewall, the source becomes: - 10.1.1.10 (ALT_A)

Return traffic is reversed automatically.

How Netmap Rules Work

To allow A → B, you need:

1. Source Netmap rule

   • maps source network to ALTA when going to ALTB

2. Destination Netmap rule

   • maps ALT_A destination back to real B side for replies

If you need B → A access, repeat symmetric rules on Site B.

---

Source Netmap (UI)

Go to Firewall → NAT → Rules and NETMAP
Click Add source NETMAP

Fill:

• Name
• Destination network: 10.2.2.0/24
• Source network: 192.168.1.0/24
• Mapped network: 10.1.1.0/24

Optional advanced settings: - input / output devices

---

Destination Netmap (UI)

Click Add destination NETMAP

Fill:

• Name
• Source network: 10.2.2.0/24
• Destination network: 10.1.1.0/24
• Mapped network: 192.168.1.0/24

Optional advanced settings: - input / output devices

---

Netmap via CLI (Optional)

Create SOURCE netmap ```bash uci set netmap.r1=rule uci set netmap.r1.name=sourcenat uci set netmap.r1.dest=10.2.2.0/24 uci set netmap.r1.mapfrom=192.168.1.0/24 uci set netmap.r1.map_to=10.1.1.0/24

optional devices

uci addlist netmap.r1.devicein='eth0' uci addlist netmap.r1.deviceout='tunrw1'

uci commit netmap ns-netmap