Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
the rule I had post above says that icmp packets that are forwarded from the internet to the internal network IPs (NET_INT=172.22.1.0/23) are accepted. My doubt is: how can an icmp packet be addressed to the internal network, containing the private IP address of the internal network, if the firewall performs NAT?
By the way, how NAT/PAT operates in the case of icmp packets if there is no 'port' to control requests/responses?
The $NET_INT variable sounds like it's meant to represent any IP address in your LAN's subnet, in which case it would match packets regardless of which LAN host IP is set by DNAT. In that case, the script could be made tighter by making sure the $NET_INT variable doesn't contain a subnet, but only a single IP (the one of the box you actually want to receive the ICMP packets).
--to-destination [ipaddr][-ipaddr][:port-port]
which can specify a single new destination IP address, an inclu‐
sive range of IP addresses, and optionally, a port range (which
is only valid if the rule also specifies -p tcp or -p udp). If
no port range is specified, then the destination port will never
be modified. If no IP address is specified then only the desti‐
nation port will be modified.
In Kernels up to 2.6.10 you can add several --to-destination
options. For those kernels, if you specify more than one desti‐
nation address, either via an address range or multiple --to-
destination options, a simple round-robin (one after another in
cycle) load balancing takes place between these addresses.
Later Kernels (>= 2.6.11-rc1) don’t have the ability to NAT to
multiple ranges anymore.
That tells me you could make it so that the packet gets DNATed to a range of IPs, but I've never done that so I don't know. It's pretty easy for you to give it a shot and see for yourself whether it works or not. That said, if you want to be able to ping each IP in your LAN individually from the WAN, you can do it easily if you have enough public IPs on the WAN interface. You could, for example, make echo requests which arrive at 203.134.233.23 get DNATed to 192.168.1.123, and those that arrive at 203.134.233.24 get DNATed to 192.168.1.124, etc.
Code:
iptables -t nat -A PREROUTING -p ICMP -i $WAN_IFACE --icmp-type 8 \
-d 203.134.233.23 -j DNAT --to-destination 192.168.1.123
iptables -t nat -A PREROUTING -p ICMP -i $WAN_IFACE --icmp-type 8 \
-d 203.134.233.24 -j DNAT --to-destination 192.168.1.124
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -p ICMP -i $WAN_IFACE -o $LAN_IFACE --icmp-type 8 \
-d 192.168.1.123 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p ICMP -i $WAN_IFACE -o $LAN_IFACE --icmp-type 8 \
-d 192.168.1.124 -m state --state NEW -j ACCEPT
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.