Ping from wan to lan network - why masquerading on LAN zone is needed?

Hi, it is pretty simple "laboratory" installation.
I have PI4 running OpenWRT connected to my home network.
my regular lan is 192.168.10.0
PI4 is connected using its wan port to it, and gets 192.168.10.124
PI4 has its own "local" network 192.168.9.0, where PI4 has IP of 192.168.9.237
There is one PC connected to it, with IP of 192.168.9.143.

There is no practical purpose in this installation, I just want to understand why it behaves differently from what I expect.

I am playing with this setup from my desktop, connected to lan with 192.168.10.10
This PC has persistent route.

route -p add 192.168.9.0 mask 255.255.255.0 192.168.10.124

From 192.168.9.0 I can browse the internet, ping computers on 192.168.10.0 etc.

From 192.168.10.0 I can ping OpenWRT on 192.168.10.124 and on 192.168.9.237

I can't ping 192.168.9.143 (PC connected to "internal" network on OpenWRT).
If I ping it directly from the OpenWRT box then it works (so PC isn't blocking pings).

I copied firewall traffic rule "Allow Ping" and created "Allow Ping Lan" rule, allowing "forwarding" to any zone.
I get timeout when pinging 192.168.9.143 from 192.168.10.10.

If I disable "Allow Lan Ping" I get

Pinging 192.168.9.143 with 32 bytes of data:
Reply from 192.168.10.124: Destination port unreachable.
Reply from 192.168.10.124: Destination port unreachable.

So looks like ping gets to the PC but answer is lost.
I tried it with and without masquerading on wan zone.

The question is:

  1. Why it requires masquerading on lan zone to get ping responses?
  2. Why I get ping responses with TTL 127 from PC on internal network, but with TTL 64 from OpenWRT itself ?
Pinging 192.168.9.237 with 32 bytes of data:
Reply from 192.168.9.237: bytes=32 time<1ms TTL=64
Reply from 192.168.9.237: bytes=32 time<1ms TTL=64
Reply from 192.168.9.237: bytes=32 time<1ms TTL=64
Reply from 192.168.9.237: bytes=32 time<1ms TTL=64

Pinging 192.168.9.143 with 32 bytes of data:
Reply from 192.168.9.143: bytes=32 time<1ms TTL=127
Reply from 192.168.9.143: bytes=32 time<1ms TTL=127
Reply from 192.168.9.143: bytes=32 time<1ms TTL=127
Reply from 192.168.9.143: bytes=32 time<1ms TTL=127


Firewall configuration:

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option output 'ACCEPT'
        option synflood_protect '1'
        option input 'REJECT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        list network 'wlan'

config zone
        option name 'wan'
        option output 'ACCEPT'
        option mtu_fix '1'
        list network 'wan'
        option input 'REJECT'
        option forward 'REJECT'
        option masq '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        list proto 'icmp'
        option src 'wan'
        option target 'ACCEPT'
        option name 'Allow-Lan-Ping'
        option family 'ipv4'
        option dest '*'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option family 'ipv4'
        option target 'ACCEPT'
        list icmp_type 'echo-request'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

Network configuration:

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd35:0d59:3896::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.9.237'
        option gateway '192.168.10.250'
        option delegate '0'
        list dns '192.168.10.244'

config interface 'wlan'
        option proto 'dhcp'
        option delegate '0'
        option metric '10'

config interface 'wan'
        option proto 'dhcp'
        option device 'eth1'

config route
        option target '192.168.9.0/24'
        option gateway '192.168.9.237'
        option interface 'lan'
        option type 'anycast'
        option disabled '1'

config rule
        option in 'wan'
        option out 'lan'
        option dest '192.168.9.0/24'
        option lookup 'main'
        option src '192.168.10.0/24'
        option disabled '1'

This cannot work. The gateway must be within the same subnet as the network being defined here (192.168.9.0/24 --> 192.168.9.1 - 192.168.9.254)

1 Like

When you do a PING from the router, the computer at 192.168.9.143 receives a local packet from 192.168.9.237. When you do a PING from the 192.168.10.0 network without using NAT, the computer at 192.168.9.143 receives a remote packet from 192.168.10.0.

it works.. OpenWRT has 3 IPs
A:192.168.9.237 (internal network where it is used as a router)
B:192.168.10.124 (home lan, assigned from DHCP from our main router)
C:192.168.10.25 (home lan/wifi, assigned from DHCP from our main router), same network as A.

For network A I don't know if gateway setting on this network is used at all, but in practice all network access, browsing from PCs on network 192.168.9.0 and from the router itself work perfectly.

Let me explain source of my confusion.

ICMP is an incoming traffic coming from wan to lan.
There are multiple cases when such traffic should go through the router, get to some local node (i.e. 192.168.9.143) and get back (i.e. VPN server hosted on 192.168.9.143).

There are multiple firewall rules installed by default (i.e. Allow-IPSec-ESP), allowing inbound traffic to lan.
If those rules are supposed to work without masquerading on lan zone - why simple ping requires it ?
If those rules won't work without masquerading on lan zone, but they are preconfigured and enabled by default - why masquerading is not enabled on lan zone by default as well (AFAIK masquerading doesn't create any cyber risk by itself, contrary to traffic rules) ?

Ok... now I understand. I didn't realize that the wan network was in use here.
That said:

  • typically, the gateway address is omitted from the lan network definition when there is an upstream connection. The router will 'do the right thing' with respect to the routing based on the internal routing tables, and it is usually not good practice to specify the gateway as you have done.
  • It is often not desirable to have two connections to the same upstream network in this way. The metric value should theoretically help avoid issues, but you generally only want one connection per network.

Meanwhile...

Now I understand what you are trying to do... but your topic title and premise is slightly wrong.

So... masquerading -- this is the idea that an entire network (or multiple networks) can 'hide behind' one single IP. This is the typical use case for most IPv4 end-networks (home, business). Often there is one public IPv4 address issued to the customer by the ISP. Behind a router with NAT masquerading, the entire customer's private network (maybe dozens of devices or more) will share the single public IP. This part you may already know, but I've provided this definition for context, just in case.

Typically, masquerading is only enabled on the wan firewall zone, based on the above use case.

What you are seeing is the fact that hosts on 192.168.10.0/24 (wan side) cannot ping hosts on 192.168.9.0/24 (lan side) because of both masquerading (they are 'hidden') and the firewall. The firewall does not allow forwarding from wan > lan. The firewall does allow lan > wan, and then will allow the return traffic that is 'established or related' back from wan > lan.

If your goal is to be able to reach 192.168.9.0/24 from hosts on 192.168.10.0/24, you actually want to achieve this by disabling masquerading on the wan zone, and then allowing forwarding from wan > lan (this is safe to do if the 'wan' in this example is a trusted network; otherwise don't do this, or make the firewall rules granular in terms of what hosts/ports are allowed from the wan side, possibly with specific hosts on the lan side). This also requires the installation of a static route on the main router, or at least the hosts on 192.168.10.0/24 that are expected to understand how to reach 192.168.9.0/24.

I still don't understand why other types of traffic are supposed to work (from wan to lan) when allowed by firewall rules, without masquerading applied on lan zone.

I don't understand your phrase

hosts on 192.168.10.0/24 (wan side) cannot ping hosts on 192.168.9.0/24 (lan side) because of both masquerading (they are 'hidden') and the firewall.

Let's assume classic example that I have now running using regular, non-wrt router between real WAN and my home network. This router doesn't have any options to enable/disable masquerading. I can browse the internet. and I have firewall rule allowing incoming VPN traffic, which succesfully reach my internal VPN server.

If I want to replicate same setup using openwrt - I'd have to define a firewall rule (like already existing default rules) and to enable masquerading on LAN zone ?

Plus masquerading on WAN (if WAN is real internet) is required for browsing right ?

I just want to make sure that in order to accept any communication from WAN to LAN in "openwrt" masquerading must be also enabled on LAN zone.

I am familiar with concepts on Full-Cone NAT, Restricted-Cone NAT, Symmetric NAT, they are not used in openwrt. Does enabling masquerading on WAN and LAN zones create an equivalent of full-cone NAT ?

I'm not sure I'm following your line of questioning here, but I'll try to address what I think you're asking...

  • In general, no unsolicited traffic is allowed from WAN > local (the router itself) or WAN > LAN, unless you allow it by means of adding firewall traffic rules or port forwards.
  • LAN > WAN traffic is allowed, unrestricted, by default on OpenWrt and most routers. The traffic that comes back in response to that (say a LAN device requests a web page from the internet) is considered related/established, and is allowed back in.
  • There are some special case firewall rules that are included by default that deal with some artifacts of NAT masquerading that can affect certain services (such as ftp, some VPN protocols, etc.) which you may find in the default rules.
  • The routing tables handle the traffic routing between LAN and WAN broadly speaking, and the NAT masquerading process keeps track of inidivual connections to ensure that each of your local devices gets the expected return data (it essentially acts like a mailroom at an office building -- getting mail addressed to you at the company (Joe smith, interesting company, llc, 123 Main Street, anytown, awesome state --> your desk).

There is no reason to masquerade the lan zone under normal operation. This can be useful when a router is operating as a dumb AP + guest wifi network, or if it is running a VPN server/endpoint while connected LAN-LAN to the upstream network.

This is only necessary if the upstream connection is connected to the LAN network of the router in question. In other words, a LAN-LAN connection rather than a LAN-WAN connection.

Yes, for IPv4 in the vast majority of contexts. For the normal home network, yes, it is required on the WAN zone. In the edge case of only a single device connecting to a the internet, it is not required because you could just plug your computer directly into your ISP's connection (this isn't a good idea in most cases because you can't share that connection with other devices and you don't gain the benefit of the firewalls found in normal routers).

No, if you want to make the WAN > LAN routing 'open', you need to disable masquerading on the wan zone. And it should not be enabled on the LAN zone, either (just leave that off). You do need to allow forwarding from wan > lan, as I described earlier, and you usually need to add a route (as I also said earlier).

These terms get thrown around every so often... they mean something in specific contexts with certain NAT/masquerading implementations (sometimes people will even post articles/definitions to describe it), but it's better to define the actual outcome rather than using these terms because of the relative ambiguity of the terms themselves.

In OpenWrt, NAT masquerading is enabled by default and it sets up a scenario where the single IPv4 address on the WAN is shared by all devices on the LAN(s), and that the individual hosts on those LAN(s) are effectively hidden with respect to the point-of-view of the ISP. The ISP sees one device connected to their network (the router), and all the traffic appears to originate from/terminate on that device (even though it is actually usually destined for devices on the LAN(s)).

1 Like

Thanks.
I understand what you are saying, what I don't understand, apparently, is why there is a difference between "normal", standard scenario

(WAN-LAN, firewall rule allowing ICMP traffic, WAN browsing is enabled, WAN masquerading is on) and my "lab setup"

(WAN (from point of view of the openwrt, but it is essentially lanA of my home work)-LAN(let's call it lanB), firewall rule allowing ICMP traffic, WAN (also LanA) browsing is enabled (from LanB), masquerading is ON on WAN zone (which governs LanA)).

I thought that in my Lab setup LanA (where WAN interface of openwrt is connected) looks and behaves as real "internet", and if I can't ping from LanA node LanB node without enabling masquerading on Lan zone (which governs LanB), then I won't be able to ping from the internet my lan network, if I install my OpenWRT as the main and the only router (standard WAN-LAN connection).

Ping in this case is kind of canary, I assume if I can't configure ping working then I wouldn't be able to configure network for WWW, FTP, VPN sites neither.

I'm still not understanding your issue.

Masquerading is simple -- the upstream network (i.e. your LanA, or the internet in the standard case), issues a single IP to the 'WAN' interface of your router. Behind that is a private network (LanB). From the perspective of the upstream network, everything on LanB appears to come from a single device (the router), as the rest is hidden (masqueraded) behind the WAN address.

Between masquerading and the firewall, hosts on the upstream network (LanA) cannot initiate any of the devices connected to the downstream network (LanB) in the standard/default configuration.

If you want to enable services (that are hosted behind the router's NAT masquerade), you use port forwarding to do this.

OR

If you have control over the upstream network (in your case, LanA) you can disable masquerading on the wan zone for the OpenWrt router (and you must add a route to the main router (LanA's router)) and then you achieve symmetric routing. Typically you also need to change the firewall rules to allow traffic to flow from the WAN > LAN of the Openwrt router -- you can do this broadly (effectively no firewall), or you can make targeted rules for what is accepted vs dropped/rejected).

What is your ultimate goal???

NATing of pings is completely different since they aren't port-based. It's very limited what can be done compared to TCP or UDP which has origin and destination ports.

1 Like

The first scenario (LanA is not under my control, as it "imitates" real internet) is the relevant one.
I understand how NAT works (in general, no how to configure openwrt).
So if I combine your answers and what mk24 wrote - regular "exposure" of local network services that use UDP/TCP protocols can be done with masquerading on WAN zone (LanA in test setup) and frewall rule, no need to define masquarading on lan zone, and it is required only for ICMP.

Normal internet service for the vast majority of users requires masquerading on the wan as I have explained. That is how a single IPv4 address from the isp is shared among all of the devices on the user’s network. Masquerading on the lan zone is not required or desired in this case, or pretty much any case except where the lan, in effect, is being used as a wan (such as the dumb ap + guest WiFi configuration).

If you want to expose services on hosts behind the nat masquerading layer, use port forwarding.

That is it. There is nothing more to do.

Thanks for your patience :slight_smile:

If you want to expose services on hosts behind the nat masquerading layer, use port forwarding.

This is true when I have only one public IP.

If I have for example 2 public IPs, one of the router itself, another one of some internal node connected through the router (let's assume global routing table knows how to route packets addressed to this internal node to the router), then I don't have to configure port forwarding, I have to configure firewall rule on the router, and (this is a question, not statement) masquerading on Lan zone ?

If you have multiple ips from your isp, you would use firewall rules and maybe policy routing or mwan3 to achieve this goal.

You will not need masquerading on the lan zone.

1 Like

You will not need masquerading on the lan zone.
Then why pinging from WAN to this internal node doesn't work without masquerading ?

Ping is a special case. Stop worrying about that.

Masquerading is not needed on lan. Period.

What is your goal???

I am not worrying, I am learning :slight_smile:

The goal is to "debug" network installation "at home", emulating internet and "future" local network, before connecting it to the real internet. Actually everything besides ping WAN->LAN node works (only IPV4 now), so now I'll start adding IPV6 (not because I need it, just as a learning experience).

So far router advertisement messages from my ISP router are blocked and do not propagate to LAN network at all, but I see they contain wrong DNS servers, so I'll have to publish my own ra on LAN, overriding IPV6 DNS servers that openrt will get from ISP.

But this is a different topic, I'll ask separate question if I meet any difficulties there.

Thanks for your explanations.

Why do you want/need to ping devices on the LAN from the WAN? There are a number of reasons that this is not practical or possible on the real internet.

I can ping www.cnn.com, for instance, so it is not like ping can't traverse internet.

Pinging cnn-tls.map.fastly.net [151.101.67.5] with 32 bytes of data:
Reply from 151.101.67.5: bytes=32 time=65ms TTL=55
Reply from 151.101.67.5: bytes=32 time=66ms TTL=55
Reply from 151.101.67.5: bytes=32 time=73ms TTL=55

I understand that this "ping" in case of cnn is meaningless and there are tens of WAFs, NLB and other infrastructure components before request reaches first front-end server/CDN, and who knows which one sends a reply to ICMP, but in my case those ping results actually have some value.

There are monitoring systems assuming "peer system" could be pinged. It is not a must, but if I provide them an ability to ping then roll out of the new deployment will be easier (transparent, they will just have to replace current url hosted elsewhere with new url hosted on my lan).