RV340 Unable to Connect to Internet while IPS is switched ON

[ANISHMOHAN77358]

My router is RV340 bearing Firmware  1.0.03.22. I have a weird problem with the router.

I have 2 ISPs providing me internet. Both the ISPs have provided their proprietary router.
I have hooked the 2 ISP routers in 2 WAN ports and set them up as DHCP clients (IP provided by router ISP). However, all the DNS are set as 8.8.8.8 and 8.8.4.4
In Multi WAN setting, the precedence is set up as WAN1=1 and WAN2=2.
Network Service Detention is Switched ON for both the Multi WANs
I have Antivirus switched ON and Intrusion Prevention System switched ON under Security Menu.

The problem is with WAN1. The router is provided by the ISP and the ISP router is in Static IP mode.

With everything working fine at individual router level, the RV340 is NOT able to connect me to Internet.

After a lot of troubleshooting, I have realized the issue.

1. A ping to IP address , say 8.8.8.8 is returning a reply. So that is good.
2. But, a ping made to google.com is not responding since the host is unresolvable.
3. If I switch OFF IPS, a ping to google.com is able to resolve the hostname and ping returns me the results
4. If I switch ON IPS, the same issue appears.
5. The internet is unable to failover to WAN2 since the Network Service Detection is able to receive a ping reply from an IP address viz. 8.8.8.8
6. But as the hostname or URL is unresolvable, There is no internet. Also DNS servers for both WAN are at Google DNS.

For the time being, I have solved this with a very crooked solution. I have placed a TP-Link router between ISP1 router and RV340 WAN1. The router is taking ISP 1 as Input WAN and in Output LAN port , it is connecting to RV340 WAN1 port.

But this is a bad solution and I do not want to rely on the sorcery without understanding the science behind it. What is causing the unavailability of internet when ISP router is directly connected to WAN port of RV340 and why is the hostname not resolvable when the DNS server is ping-able ?

How do I solve this situation and eliminate the middle TP-Link router ?

[nagrajk1969]

1. you say that both your wan1 and wan2 interfaces are assigned ipaddress thru DHCP, and then you mention the below statement:

>>>The problem is with WAN1. The router is provided by the ISP and the ISP router is in Static IP mode.

- what do you mean exactly?

- its to be assumed that the dhcp-server is either on the isp-router connected to the wan1 interface..is this correct?

2. Are your configs as in attached sample screen-shots? (ofcourse in your case the IPS service will be in "ON" state)

- is your firewall configs the "default"?...meaning you have NOT applied any acl rules (especially deny rules) of your own?

kindly post your screenshots

3. you mentioned this below:

>>>>1. A ping to IP address , say 8.8.8.8 is returning a reply. So that is good.
>>>>2. But, a ping made to google.com is not responding since the host is unresolvable.

So lets assume that your network-deployment with wan1 shown is as below:

lanpc1----vlan1[RV34X]wan1----[isp-router]----{internet}----[google-8.8.8.8]---other-website(such as www.yahoo.com, etc)

-

- please confirm that on your lanpc1 the following is the ip-config (configured either thru dhcp or manually)

ipaddr: 192.168.1.x/24

default-gw: 192.168.1.1

dns-server: 192.168.1.1 or any other dns-server ipaddresses

- So where are you pinging from?....from RV34X router itself (using the diagnostic page)?

3. can you try the ping (to ipaddress and to "fqdn") from the lanpc1 ???

- additionally, in case with dns-server config of 192.168.1.1 on the lan-pc1, if you are not able to ping to any internet "fqdn", can you configure on lanpc1 the dns-server ip: 8.8.8.8 and then send the pings to the fqdn addresses and check whether this will work?

thanks

[ANISHMOHAN77358]

Many Thanks for the prompt response. My answers are provided in line

---

@nagrajk1969 wrote:

1. you say that both your wan1 and wan2 interfaces are assigned ipaddress thru DHCP, and then you mention the below statement:

>>>The problem is with WAN1. The router is provided by the ISP and the ISP router is in Static IP mode.

- what do you mean exactly?

The ISP provider on WAN1 has given me Static IP which is configured on the Router that is provided by ISP. Therefore for the CISCO RV340, WAN1 is in DHCP (exactly the manner in which it is present in your first screenshot).

- its to be assumed that the dhcp-server is either on the isp-router connected to the wan1 interface..is this correct?

Yes, you are very much right. The ISP router has DHCP enabled and that is how the WAN1 interface derives its IP address

2. Are your configs as in attached sample screen-shots? (ofcourse in your case the IPS service will be in "ON" state)

Yes, the screenshot that you have provided is very much right and the IPS in my case is ON.

- is your firewall configs the "default"?...meaning you have NOT applied any acl rules (especially deny rules) of your own?

kindly post your screenshots

Posted the screenshots

3. you mentioned this below:

>>>>1. A ping to IP address , say 8.8.8.8 is returning a reply. So that is good.
>>>>2. But, a ping made to google.com is not responding since the host is unresolvable.

So lets assume that your network-deployment with wan1 shown is as below:

lanpc1----vlan1[RV34X]wan1----[isp-router]----{internet}----[google-8.8.8.8]---other-website(such as www.yahoo.com, etc)

-

- please confirm that on your lanpc1 the following is the ip-config (configured either thru dhcp or manually)

ipaddr: 192.168.1.x/24

default-gw: 192.168.1.1

dns-server: 192.168.1.1 or any other dns-server ipaddresses

Posted the screenshots of VLAN config. DNS server is from ISP.

- So where are you pinging from?....from RV34X router itself (using the diagnostic page)?

I am pinging from the Windows PC connected to VLAN1 (LAN#1) of RV340 via Ethernet. The Windows PC gets its IP address assigned by the DHCP server of RV340.

3. can you try the ping (to ipaddress and to "fqdn") from the lanpc1 ???

I am pinging from the Windows PC. When I ping to "ipaddress" , it responds. When I fqdn (like google.com) , it does not work

- additionally, in case with dns-server config of 192.168.1.1 on the lan-pc1, if you are not able to ping to any internet "fqdn", can you configure on lanpc1 the dns-server ip: 8.8.8.8 and then send the pings to the fqdn addresses and check whether this will work?

This is a good point. I am trying that option once I eject all the users from the network. Will keep you posted.

thanks

---

[ANISHMOHAN77358]

CONTINUATION :

I have changed the DNS in the VLAN section now. But unfortunately I have no luck. See screenshots.

[ANISHMOHAN77358]

CONTINUATION :

I have changed the DNS in the VLAN section now. But unfortunately I have no luck. See screenshots.

But Something very interesting came up.

I decided to use the Diagnostic option in RV340 itself and voila, the ping to fqdn was perfectly working inside RV340. See screenshots.

Which therefore begs the question, why can DHCP clients of RV340 unable to ping to google.com as well ? 

[nagrajk1969]

Hi

lanpc1----(pcap-capture1??)----vlan1[RV34X]wan1----(pcap-capture2?)----[isp-router]----{internet}----[dns.google-8.8.8.8]

1. As you mentioned, the pings-to-fqdns (and the nslookups) are working when sent from the RV345 itself...It means that the dns-resolution and communication to 1.1.1.1/1.0.0.1 dns-servers from RV345 is working and is successfull

2. So now coming to the lan-pc:

a) just for completeness of checks, can you confirm that the dns-servers 1.1.1.1/1.0.0.1 are assigned and configured on the lan-pc?

- use the command "ipconfig /all" and check in the output if the dns-server settings are present

3. Now referring to the above network-diagram.....could capture the packets/traffic (from the beginning of sending pings from the lan-pc) at the above points shown?

- this is to see by capturing packets at capture-1 that when we try ping to fqdn (say to www.yahoo.com, google.com, or dns.google, etc), does the PC send the dns-query-request to the configured dns-server of 1.1.1.1 (or 1.0.0.1)...and if yes, does the capture show the reply-packet from the dns-servers?

- also at the same time...the capture at capture2-point will show us whether the dns-requests to 1.1.1.1 are coming out of the RV345-wan interface and getting routed to 1.1.1.1 after getting SNATed/Masqueraded to the public-ipaddress of wan1 interface?....and if yes, the capture should also show whether the dns reply packets are also coming  from the internet side.....

- and if replies to the dns-queries from PC is arriving back...whats happening to the reply-traffic at the RV345 and/or at the PC?

--------------------------------------------------------------------

----------------------------------------------------------------

Some additional info is that:

- i tried the various combinations of configuring the dns-servers and also enabled IPS/AntiVirus on a RV345 in my network....

- and i connected a linux-VM-machine...(i dont have any windows machine accessible to me at this point of time...so i used a linux-host as dhcp-client PC behind the RV345)

- I used the same primary dns-server ipaddress 1.1.1.1 (and also tested with 8.8.8.8 and 8.8.4.4 too

- In all cases of my checks it was working correctly. I did not have to disable IPS or any other services.

- In only 1 config-scenario, the dns-requests to 1.1.1.1 was not working, was when i configured HW-DMZ using ip-range.... this was just to test. I later deleted/disabled the Hw-DMZ (using the ip-range). Here too the issues with dns-ipaddress 1.1.1.1 was an issue due to HW-dmz being enabled with ip-range....and at this time too, i did NOT disable IPS at any time...

In summary iam not able to say what is the cause in your network deployment....the same configurations are working in my network without any issues....

thanks

[ANISHMOHAN77358]

---

@nagrajk1969 wrote:

Hi

lanpc1----(pcap-capture1??)----vlan1[RV34X]wan1----(pcap-capture2?)----[isp-router]----{internet}----[dns.google-8.8.8.8]

1. As you mentioned, the pings-to-fqdns (and the nslookups) are working when sent from the RV345 itself...It means that the dns-resolution and communication to 1.1.1.1/1.0.0.1 dns-servers from RV345 is working and is successfull

2. So now coming to the lan-pc:

a) just for completeness of checks, can you confirm that the dns-servers 1.1.1.1/1.0.0.1 are assigned and configured on the lan-pc?

- use the command "ipconfig /all" and check in the output if the dns-server settings are present

Yes, though the DNS is set to Auto in my Windows PC< but Ipconfig /all reveals that the DNS is inherited as 1.1.1.1/1.0.0.1

3. Now referring to the above network-diagram.....could capture the packets/traffic (from the beginning of sending pings from the lan-pc) at the above points shown?

- this is to see by capturing packets at capture-1 that when we try ping to fqdn (say to www.yahoo.com, google.com, or dns.google, etc), does the PC send the dns-query-request to the configured dns-server of 1.1.1.1 (or 1.0.0.1)...and if yes, does the capture show the reply-packet from the dns-servers?

No it does not. The way I ascertained it, when I give the tracert command to dns.google it simply does not even hop 1 network. It straight away refuses to ping giving me the error that dns could not resolve the hostname. But when an IP address is pinged it hops through my ISP'r router and eventually to IP address

- also at the same time...the capture at capture2-point will show us whether the dns-requests to 1.1.1.1 are coming out of the RV345-wan interface and getting routed to 1.1.1.1 after getting SNATed/Masqueraded to the public-ipaddress of wan1 interface?....and if yes, the capture should also show whether the dns reply packets are also coming  from the internet side.....

No , as I said, the tracert with fqdn does not even move a line. See the screenshot

- and if replies to the dns-queries from PC is arriving back...whats happening to the reply-traffic at the RV345 and/or at the PC?

--------------------------------------------------------------------

----------------------------------------------------------------

Some additional info is that:

- i tried the various combinations of configuring the dns-servers and also enabled IPS/AntiVirus on a RV345 in my network....

- and i connected a linux-VM-machine...(i dont have any windows machine accessible to me at this point of time...so i used a linux-host as dhcp-client PC behind the RV345)

- I used the same primary dns-server ipaddress 1.1.1.1 (and also tested with 8.8.8.8 and 8.8.4.4 too

Is the router firmware at 1.0.03.22 ? I remember it used to work like charm even in Mar 2021 but after the latest firmware update, the IPS has started to behave erratically.

- In all cases of my checks it was working correctly. I did not have to disable IPS or any other services.

- In only 1 config-scenario, the dns-requests to 1.1.1.1 was not working, was when i configured HW-DMZ using ip-range.... this was just to test. I later deleted/disabled the Hw-DMZ (using the ip-range). Here too the issues with dns-ipaddress 1.1.1.1 was an issue due to HW-dmz being enabled with ip-range....and at this time too, i did NOT disable IPS at any time...

In summary iam not able to say what is the cause in your network deployment....the same configurations are working in my network without any issues....

thanks

---

[nagrajk1969]

Hi

Yes i have the v1.0.03.22 firmware on the RV34X routers in my network, and checked on it.

>>>No it does not. The way I ascertained it, when I give the tracert command to dns.google it simply does not even hop 1 network. It >>>straight away refuses to ping giving me the error that dns could not resolve the hostname. 

1. In that case it makes sense to capture at capture-point-1 (between the lan-pc and the RV34X router), and check

- whether the windows-pc is first sending a DNS-query-request to 1.1.1.1 (to resolve "dns.google")...there should be a udp-53 dns-packet generated by the windows-PC...and this packet should be going to the RV34X router (becos its the default-gw for the PC)...

- If this dns-query packet to 1.1.1.1 is NOT being generated by the windows-PC, it means there is a problem on the windowsPC...for some reason its not generating a dns-udp-53 packet...

- It does not matter which application you use for traffic-generation: "tracert <fqdn>, "ping <fqdn>", ssh/telnet <fqdn>, in all cases the first thing done would be to send a dns-query to the configured dns-server to resolve the fqdn to the ipaddress...right?...

2. so we need to know as to whats happening to the dns-packet/resolution flow between the windows-pc upto 1.1.1.1...

  - from the captures (at point-1 & point-2), if the dns-query packet has been generated from windows-pc....has it been forwarded by the RV345 (after NAT on its wan interface) to 1.1.1.1?

- if yes, then where is the dns-reply packet from 1.1.1.1?...

- if the reply-packet has been generated from 1.1.1.1, then has it reached the windows-pc? (via the RV34X router in between)

- basically we need to ascertain, if the dns-resolution packets are sent from window-PC, where is it getting dropped?...if dropped, is it the reply-packet?

- also it may so happen that 1.1.1.1 maynot be replying to the dns-query sent from window-pc (and forwarded to it by the RV34X)...and we need to find out why?....is the dns-query packet generated from windows-pc OR forwarded from RV345 corrupted?

so capture the packets at point1 and point-2 is important to identify where the problem-area is

3. One additional thing you could do (helps in concluding whether its a generic problem in this network or is it specific to windows-PC).....

- connect a Linux-PC to the lan-network...and enable/configure dhcp-client on the interface...

- and then check whether it has got the ipaddress/default-gw/dns-ipaddresses from the RV34X-dhcp-server, using the below commands/etc:

#in case you are trying from cli of linux-host (in root)...try with "dhclient <ethX>"

---------------------------------------

ifconfig

ip route

route -n

cat /etc/resolv.conf (the dns-ipaddresses 1.1.1.1 and 1.0.0.1 should be present as nameservers)

#below only if its present (some linux hosts maintain as such, so....)

cat /tmp/resolv.conf

or

cat /tmp/resolv.conf.d/resolv.conf.auto

- something like that...the relevant file should contain the dns-ipaddresses

----------------------------------------------------------------

- then here too, run a check with "ping fqdn", traceroute/tracepath, etc..

[ANISHMOHAN77358]

Hi @nagrajk1969 

Your clues gave a lot of help for me. I connected a RaspberryPi with Debian Linux installed to check the problem instead of a Windows PC. And it seems I have got the issue. I had configured the WAN 1 DNS as 1.1.1.1/1.0.0.1. The name resolution from this DNS was being blocked by the ISP router for WAN 1. Now I changed the DNS as "Use DHCP Provided DNS Server" in the WAN definition as well as LAN definition. And voila !!! It works... The Internet is working. a tracert on fqdn is working and all going fine. 

EXCEPT for a small niggling problem.

I use Amazon Workspaces for my work. In this configuration, AWS seems to have stopped working.  A quick diagnostic reveals that it is unable to connect to UDP ports. (See screenshot AWS_Issue.jpg). After searching on AWS documentation, it states

Port 4172 and 4195 (UDP and TCP)

These ports are used for streaming the WorkSpace desktop and health checks. The desktop client applications do not support the use of a proxy server for port 4172 and 4195 traffic; they require a direct connection to ports 4172 and 4195

The IPS being ON is blocking the traffic on Port 4195 (it seems). If I switch off IPS and Antivirus, it works fine. How do I solve this issue ? Is there any way I can make the 4172 and 4195 allow to pass through the RV340 router ?

Any by the way, Many Thanks for the help that you have rendered. It has really been a lot of learning experience for me.

[ANISHMOHAN77358]

Hi @nagrajk1969 

Your clues gave a lot of help for me. I connected a RaspberryPi with Debian Linux installed to check the problem instead of a Windows PC. And it seems I have got the issue. I had configured the WAN 1 DNS as 1.1.1.1/1.0.0.1. The name resolution from this DNS was being blocked by the ISP router for WAN 1. Now I changed the DNS as "Use DHCP Provided DNS Server" in the WAN definition as well as LAN definition. And voila !!! It works... The Internet is working. a tracert on fqdn is working and all going fine. 

EXCEPT for a small niggling problem.

I use Amazon Workspaces for my work. In this configuration, AWS seems to have stopped working.  A quick diagnostic reveals that it is unable to connect to UDP ports. (See screenshot AWS_Issue.jpg). After searching on AWS documentation, it states

Port 4172 and 4195 (UDP and TCP)

These ports are used for streaming the WorkSpace desktop and health checks. The desktop client applications do not support the use of a proxy server for port 4172 and 4195 traffic; they require a direct connection to ports 4172 and 4195

The IPS being ON is blocking the traffic on Port 4195 (it seems). If I switch off IPS and Antivirus, it works fine. How do I solve this issue ? Is there any way I can make the 4172 and 4195 allow to pass through the RV340 router ?

Any by the way, Many Thanks for the help that you have rendered. It has really been a lot of learning experience for me.

[nagrajk1969]

Hi

>>>The IPS being ON is blocking the traffic on Port 4195 (it seems). If I switch off IPS and Antivirus, it works fine.

>>>How do I solve this issue? Is there any way I can make the 4172 and 4195 allow to pass through the RV340 router ?

and

>>>The desktop client applications do not support the use of a proxy server for port 4172 and 4195 traffic; they require a direct >>>connection to ports 4172 and 4195

1. In this case here the "Proxy-Server"  between the lan-hosts(running the AWS-WS clients) and the AWS-servers is nothing but the NAT-Firewall-Router "RV34X"...which is ofcourse obvious, but mentioning it anyways to list out the existing facts

2. This is strange about IPS/Antivirus preventing connections on the RV34X..????.

- Ofcourse i dont yet know how exactly the Aws-Workspace connections work (have not been exposed to this kind of network traffic in my network...yet..), But looking at the details in the various KB-articles on AWS site, i believe that:

a) at some point of time when you start the desktop-AWS-WS client on your lan-hosts, and connect to the AWS-WS servers, the remote-WS-streaming-servers (including something called PCoIP gateways, etc) would be "initiating" back-connections to the WS-desktop-clients using udp/tcp ports 4172/4195 (now i believe its mostly 4195 that is used)

b) so i am thinking that this streaming connection "initiated" from the WS-servers/gateways will be to the same  source-ip/destination-ip peers (reversed when initiated from AWS to the desktop via the same RV34X) connection that was originally opened/existing between the WS-desktop-client and AWS-WS?

but then again i dont know...

3. This reminds me of the TFTP-Get connection process, wherein if we have something like below with a firewall/nat in between:

tftp-client-pc-------lan[nat-fw-router]wan------tftp-server

- as per the tftp-get protocol, first the tftp-client will initiate a udp-connection request (with the filename to download/get) to server on udp-port-69...and say that in this outbound connection, the udp-port for the tftp-client is a ephemeral port udp-34001 for example.

- so this initial connection request is a connection-state that is created on the nat-firewall in-between the tftp-client and tftfp-server

- next, the tftp-server will NOW "initiate" a new udp connection to  the same tftp-client ipaddress (which actually the nated wan-interface ipaddress of the router in-between)...and the destination udp port will be choosen as a random ephemeral port by the server itself.....(which in the normal circumstance, without any router/firewall in between, the client would accept the connection on the udp-port )....

- so on the firewall, it becomes imperative that we open up the required destination udp port on which the tftp-server is "initiating" to the tftp-client-ipaddress....

- this is called Port-Triggering....and when the port-trigger rules are added, the file download thru the tftp-get is successfull

4. So presently my though process is on the same lines as point3 above....and iam really not sure whether this would work or not (with ofcourse IPS enabled...i dont think AV would be blocking anything of such becos it scans only selected protocol-ports, not all...)..

Note: you could experiment it anyways and see whether it works...and if it works, whether it is truly safe and secure. Ultimately i suggest and recommend that you should/must raise a ticket on this issue with AWS-WS with Cisco...and request for a solution/fix

- please try by adding some of the rules in firewall-ACL and/or Port-Triggering rules....

- for the above add first the require service records as shown...

- In the port-trigger, the trigger service (outboud) is presently mentioned as same 4172/4195....if this doesnt work...try the port that triggers the inbound streaming from the remote servers to the desktop-ws

In summary, the above is just my rambling dynamic thoughts that are going thru my mind in trying to understand the issue with AWS-WS...it maybe totally wrong....

best wishes