In openwrt i have config lan forward to wan with masqenabled. And my lan network is when some pc ping with other network ip e.g:, tcpdump will get some local packet in wan, which cause wan close. (my wan is a 3g modem).

openwrt firewall config:

config defaults
    option syn_flood '1'
    option input 'DROP'
    option output 'DROP'
    option forward 'DROP'

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

config zone
    option name 'cellular'
    list network 'cellular'
    option input 'DROP'
    option forward 'DROP'
    option output 'ACCEPT'
    option masq '1'
    option mtu_fix '1'

config forwarding
    option src 'lan'
    option dest 'cellular'

When pc in lan exec:

 ping -I

I can catch some invaild packet in ppp

 tcpdump -i 3g-cellular -s 0 -w a.pcap

enter image description here

iptables -t nat -L -v:

Chain POSTROUTING (policy ACCEPT 119 packets, 7439 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 337 24011 zone_wan_postrouting  all  --  any    3g-cellular  anywhere             anywhere             /* !fw3 */

Chain zone_wan_postrouting
 pkts bytes target     prot opt in     out     source               destination         
  337 24011 MASQUERADE  all  --  any    any     anywhere             anywhere             /* !fw3 */

In other words, the openwrt firewall seems to only NAT packets coming from its own LAN. So probably the iptables rule has additional restriction on the source.

You can verify this by inspecting all iptables rules your current firewall configuration generates (with iptables -S etc.)

As a workaround, you can modify the iptables NAT rule directly into a variant without the source filter.

I don't know how to change the openwrt firewall configuration so it produces the iptables rules you want. Possibly the OpenWRT community will know.


Example for a condition where not all packets will end up on zone_wan_postrouting, from an existing OpenWRT firewall configuration:

# iptables -S -t nat
-A POSTROUTING -j delegate_postrouting
-A delegate_postrouting -m comment --comment "user chain for postrouting" -j postrouting_rule
-A delegate_postrouting -o br-wan -j zone_wan_postrouting
-A delegate_postrouting -o br-client -j zone_client_postrouting
-A delegate_postrouting -o local-node -j zone_local_node_postrouting
-A zone_wan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_wan_rule
-A zone_wan_postrouting -j MASQUERADE

So as you can see, the chain POSTROUTING jumps (-j) to delegate_postrouting, there it checks if the packet has an outgoing interface of br-wan, and in that case it jumps to zone_wan_postrouting, where it unconditionally masquerades this packet. Other outgoing interfaces (br-client, local-node) are forwarded to different chains.

So the condition is outgoing interface of br-wan. It's easy to add other conditions to that, like some source or destination range:

-A delegate_postrouting -o br-wan -s -j zone_wan_postrouting

or even more complex ones with packet marks, protocols, ports, and lots of other stuff.

So without actually looking at all your iptables rules, we won't know. Maybe indeed all packets go this way, and the problem is elsewhere. Maybe there's an extra condition that doesn't show up in iptables -L. Maybe not.

  • iptables -t nat -L -v, masq will nat all packet get in from any nic. – jianxi sun Nov 30 '18 at 15:38
  • iptables -L doesn't always list all conditions, please use -S. Also, you'll have to check all rules, not all packets will end up in chain zone_wan_postrouting, and the filter may be in the rules leading up to this chain. Yes, there are probably many rules, I know. You still have to work through them. – dirkt Nov 30 '18 at 15:45
  • I think all packet will get in nat postrouting. What's the meaning of not all packets will end up in chain nat postrouting? Please give an example of packet that will not pass NAT POSTROUTING. tks. – jianxi sun Dec 1 '18 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.