This has been bugging me for some time. When creating fiewall rules and similar constraints we often specify source address or protocol/port, as well as destination ip or protocol or port.
As far as the router is concerned which is source and which is the destination? If an external IP triggers the connection, that IP would be the source. But if local IP initiated the connection, then they would be the source. Do we have to create double the rules depending on who triggers it? Or is source always local, and destination always external?
The source IP/port and destination IP/port are based on the information in the packets being sent. So the short answer is, “yes, you would need double rules depending on which way the traffic is flowing”.
When your computer makes a request to Google’s DNS server, it sends a UDP packet from its address (for example, assume 192.168.88.100), on a randomly chosen high-numbered port, to Google’s DNS server ( 8.8.8.8 ) on port 53. So, the packet the router would see is:
Source - 192.168.88.100:49974 (or some other random port number)
Destination - 8.8.8.8:53
Protocol - UDP
The router’s NAT rule would then re-write the source IP to its external address (for example, assume 1.2.3.4), on a randomly chosen high-numbered port. When sent to your ISP, the packet would look something like:
After Google’s DNS handles the request, it will send a reply back to the source IP and port number it received the request from. Once it gets back to your router, your router will see the incoming response packet as:
And then its NAT table will remember that it translated that request onto 1.2.3.4:55555, and will reverse the translation so it can send the response back to your computer. The packet sent to your computer would look like:
However, if your firewall was initially set up to block outbound (source 192.168.88.0/24 to destination ANY) UDP port 53 traffic, the first packet would have gotten dropped, and none of the next three packets would ever occur. So, the longer answer is usually: once you set up rules to prevent requests from the inside (or requests from the outside), you don’t need the reverse rule, because no response will occur if the initial request is dropped.
