Blocking specific WAN IP disable LAN access to the Internet?
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Blocking specific WAN IP disable LAN access to the Internet?
Region : Brazil
Model : TL-R470T+
Hardware Version : V3
Firmware Version : 5.2.2 Build 20140422 Rel.59140s
ISP :
I´m running a private server at LAN address 192.168.1.7 and it can be accessed without trouble by external users thanks to the router Virtual Server setup.
Recently a given public IP (a.b.c.d) starts hammering the router in a Stationary source UDP Flood. The router was then setup to block the attack by lowering
the threshold down to the lowest limit (100). This worked fine and the server is no more flooded. Furthermore, the server firewall was updated to drop all
traffic from that a.b.c.d host.
There is a cable connection to WAN1 (the only WAN enabled), using dynamic IP. Eventually, other LAN devices must be accessed thru the Internet on different
ports, so the corresponding virtual server setups were defined and enabled when the external access is required, by request.
To block access to the LAN servers by a.b.c.d, the following was set in Firewall > Access Control > Access Rules:
Policy: Block
Service: All Services (I inserted also a new service "GenBlock" including TCP/UDP ports 1 to 65535)
Interface: WAN
Source: IP/MASK a.b.c.d/32 (the bad guy)
Destination: IP/MASK 192.168.1.0/24 (Hosts in LAN)
Effective Time: Always
This blocked the bad guy (I noticed that the LAN activity LED stopped blinking in sync with the WAN LED, wich blinks continuosly thanks to the bad guy) but
another unexpected effect takes place: Now my hosts in the LAN cannot access the Internet (e-mail, web surfing, external host pinging), apparently only when
DNS resolving must be used to get the public IP. Pings to external hosts using their current IP's work fine, but failed when using their domain name.
In another attempt, the above access rule was changed to:
Policy: Block
Service: The same (and only) service used by the server at 192.168.1.7 (same local port specified in the virtual server setup)
Interface: WAN
Source: IP/MASK a.b.c.d/32 (the bad guy)
Destination: IP/MASK 192.168.1.7/32 (Now the specific LAN server)
Effective Time: Always
Since the bad guy can only access the server above via Virtual server at the specific port, it cannot get access to other LAN hosts due to the router
firewall. So the rule above must suffice to cut any flood attempt/access to the host at 192.168.1.7. Again it was blocked and I noticed that the LAN activity LED
stopped blinking in sync with the WAN LED, but the same problems occur with the other hosts in the LAN. This was really surprising.
But the more surprising is that in the 2 cases above, when I login to the the LAN server at 192.168.1.7, it was possible to ping Internet hosts by
domain name, something that was not possible in the other LAN hosts. Maybe that was possible due to the virtual server setup for the server at 192.168.1.7.
So I decided another approach. In my oppinion, not the best one, because the best one is to drop any traffic from the bad guy as it enters the router.
The idea now was to cut outbound traffic to the bad guy, so it doesn't know what was going on at the other side.
The access rule was then changed again:
Policy: Block
Service: All Services (I inserted also a new service "GenBlock" including TCP/UDP ports 1 to 65535)
Interface: LAN
Source: IP/MASK 192.168.1.0/24 (Hosts in LAN)
Destination: IP/MASK a.b.c.d/32 (the bad guy)
Effective Time: Always
That worked as expected, hosts in LAN regain Internet access to all services and the bad guy cannot be even pinged, the same occurred at the LAN server
192.168.1.7.
The question is: what was wrong? In the first two access rules, I supposed that the incoming traffic in the given interface triggers the expected action. As
we can read in the manual, "The entry will take effect when the interface to which the data is flowing is selected". The router configuration help page is
much more specific, "The rule will take effect when the interface for receiving packets is the specfied interface".
So, at the moment, I'm using this access rule.
Any comments will be very much appreciated. Thank you for all the patience!
Model : TL-R470T+
Hardware Version : V3
Firmware Version : 5.2.2 Build 20140422 Rel.59140s
ISP :
I´m running a private server at LAN address 192.168.1.7 and it can be accessed without trouble by external users thanks to the router Virtual Server setup.
Recently a given public IP (a.b.c.d) starts hammering the router in a Stationary source UDP Flood. The router was then setup to block the attack by lowering
the threshold down to the lowest limit (100). This worked fine and the server is no more flooded. Furthermore, the server firewall was updated to drop all
traffic from that a.b.c.d host.
There is a cable connection to WAN1 (the only WAN enabled), using dynamic IP. Eventually, other LAN devices must be accessed thru the Internet on different
ports, so the corresponding virtual server setups were defined and enabled when the external access is required, by request.
To block access to the LAN servers by a.b.c.d, the following was set in Firewall > Access Control > Access Rules:
Policy: Block
Service: All Services (I inserted also a new service "GenBlock" including TCP/UDP ports 1 to 65535)
Interface: WAN
Source: IP/MASK a.b.c.d/32 (the bad guy)
Destination: IP/MASK 192.168.1.0/24 (Hosts in LAN)
Effective Time: Always
This blocked the bad guy (I noticed that the LAN activity LED stopped blinking in sync with the WAN LED, wich blinks continuosly thanks to the bad guy) but
another unexpected effect takes place: Now my hosts in the LAN cannot access the Internet (e-mail, web surfing, external host pinging), apparently only when
DNS resolving must be used to get the public IP. Pings to external hosts using their current IP's work fine, but failed when using their domain name.
In another attempt, the above access rule was changed to:
Policy: Block
Service: The same (and only) service used by the server at 192.168.1.7 (same local port specified in the virtual server setup)
Interface: WAN
Source: IP/MASK a.b.c.d/32 (the bad guy)
Destination: IP/MASK 192.168.1.7/32 (Now the specific LAN server)
Effective Time: Always
Since the bad guy can only access the server above via Virtual server at the specific port, it cannot get access to other LAN hosts due to the router
firewall. So the rule above must suffice to cut any flood attempt/access to the host at 192.168.1.7. Again it was blocked and I noticed that the LAN activity LED
stopped blinking in sync with the WAN LED, but the same problems occur with the other hosts in the LAN. This was really surprising.
But the more surprising is that in the 2 cases above, when I login to the the LAN server at 192.168.1.7, it was possible to ping Internet hosts by
domain name, something that was not possible in the other LAN hosts. Maybe that was possible due to the virtual server setup for the server at 192.168.1.7.
So I decided another approach. In my oppinion, not the best one, because the best one is to drop any traffic from the bad guy as it enters the router.
The idea now was to cut outbound traffic to the bad guy, so it doesn't know what was going on at the other side.
The access rule was then changed again:
Policy: Block
Service: All Services (I inserted also a new service "GenBlock" including TCP/UDP ports 1 to 65535)
Interface: LAN
Source: IP/MASK 192.168.1.0/24 (Hosts in LAN)
Destination: IP/MASK a.b.c.d/32 (the bad guy)
Effective Time: Always
That worked as expected, hosts in LAN regain Internet access to all services and the bad guy cannot be even pinged, the same occurred at the LAN server
192.168.1.7.
The question is: what was wrong? In the first two access rules, I supposed that the incoming traffic in the given interface triggers the expected action. As
we can read in the manual, "The entry will take effect when the interface to which the data is flowing is selected". The router configuration help page is
much more specific, "The rule will take effect when the interface for receiving packets is the specfied interface".
So, at the moment, I'm using this access rule.
Any comments will be very much appreciated. Thank you for all the patience!