RV345P Is Blocking TLS Traffic

[db77]

Hi all,

I've just installed a Cisco RV345P router in a home office. WAN connection is via PPPoE using a sub-interface on WAN1. MTU is auto. I can ping external hosts (1.1.1.1, 8.8.8.8 etc) and perform DNS lookups via Google DNS ok. Firewall settings are default. Running FW 1.0.03.21.

The issue I'm having is that TLS handshakes fail waiting for SERVER HELLO. Selected output of curl show below.

curl -v -I https://github.com

...
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[times out]

So I am unable to  connect to any site using HTTPS from an internal VLAN.

The interesting thing (to me, at least) is that when I use debug mode to do a packet capture in order to look at the TLS handshake in more detail, the handshake always succeeds - but only in debug mode.

Has anyone seen this or can suggest where to look?

many thanks!

[balaji.bandi]

Do you have any webfiltering enabled ? disable and test it ?

[db77]

Hi - no web filtering is enabled. None of the features in the security section are enabled.

[balaji.bandi]

what device you testing from :

curl -v -I https://github.com

[db77]

I'm testing from a laptop running macOS 10.14.5 patched into a LAN port on the RV345 and the port is assigned to VLAN20. The IP address for the laptop NIC is assigned by the RV345 configured to be a DHCP server for that VLAN.

I use the same testing strategy when connected to another network in which the RV345 is excluded and I get the expected server response (as in the handshake succeeds).

[Martin Aleksandrov]

Hi db77,

Did you manage to connect to any non-secure (HTTP) sites? I can't seem to find any reason for preventing HTTPS access with the RV340. You would proceed with WAN packet capture so we can analyze where the connection drops. Here is the guide: https://www.cisco.com/c/en/us/support/docs/smb/routers/cisco-rv-series-small-business-routers/enable-wan-packet-capture-rv34x-devices.html 

Thanks,

Martin

[db77]

Hi Martin - yes, I have no trouble with standard HTTP connections. As I mentioned in my original post, I have tried the WAN packet capture and that's when I noticed that whenever I am in packet capture 'mode' the HTTPS issue goes away - but only while in that mode. As soon as I stop the packet capture, I can no longer connect to HTTPS sites. Odd?

[Martin Aleksandrov]

Odd indeed,

Did you proceed with that WAN packet capture process I posted the link to?  Can you pls share the PCAP on PM?

Thanks,

Martin

[db77]

Yes - sent via PM.

[db77]

I couldn't get the RV345 working as originally intended - with PPPoE on a sub-interface of one of the WAN ports (needed to use a sub-interface in order to add a VLAN tag as required by the ISP). In the end I used an ASA 5506 to handle the NATing and firewall duties, set a static IP on WAN1 of the RV345 and turned off NAT on that interface. Now everything works as expected. The RV345 was meant to act as a VPN endpoint too but now that will also be handled by the ASA.

I'm basically just using the switching capabilities of the RV345 - making it a rather expensive home office switch! This is clearly not a great outcome cost-wise, but I definitely prefer having the ASA performing those duties when there is very little you can do in the RV345 to configure them and investigate issues such as this.

I'm posting this outcome in case someone else has a similar issue. Hopefully someone knows what the asnwer is here - buggy firmware? Faulty hardware?

[Martin Aleksandrov]

Hello db77,

I can't see anything suspicious in the pcap and would advise contacting STAC to further investigate. Contact details are as follows: 

https://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

Thanks,

Martin

[nagrajk1969]

Hi

I have a RV345 configured with wan1-subinterface..but its a static-wan-ipaddress (and not pppoe)

Just FYI...

- iam able to browse and connect to various https:// websites on the internet...including accessing my gmail-account which is using https. This i have done from hosts connected to lan-side of RV345...Ofcourse you have to take my word for it

- From a linux-box (ubuntu-14.x) connected in the lan-network of RV345,  i tried the curl commands (and also tried using wget for https)...and this is what i observe:

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

curl -v -I https://github.com

[root@tst ~]# ping github.com
PING github.com (13.250.177.223) 56(84) bytes of data.
64 bytes from ec2-13-250-177-223.ap-southeast-1.compute.amazonaws.com (13.250.177.223): icmp_req=1 ttl=43 time=47.4 ms
64 bytes from ec2-13-250-177-223.ap-southeast-1.compute.amazonaws.com (13.250.177.223): icmp_req=2 ttl=43 time=47.5 ms
^C
--- github.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 47.435/47.513/47.591/0.078 ms
[root@tst ~]#

root@host:~/dump3#
root@mainhost:~/dump3#
root@mainhost:~/dump3# wget https://inmon.com/products/sFlow-RT/sflow-rt_$LATEST.deb
--2021-05-15 09:37:57-- https://inmon.com/products/sFlow-RT/sflow-rt_.deb
Resolving inmon.com (inmon.com)... 54.190.130.38
Connecting to inmon.com (inmon.com)|54.190.130.38|:443... connected.
ERROR: cannot verify inmon.com's certificate, issued by \u2018/C=US/O=Let's Encrypt/CN=R3\u2019:
Unable to locally verify the issuer's authority.
To connect to inmon.com insecurely, use `--no-check-certificate'.
root@mainhost:~/dump3#
root@mainhost:~/dump3#
root@mainhost:~/dump3# curl -v -I https://github.com
* Rebuilt URL to: https://github.com/
* Hostname was NOT found in DNS cache
* Trying 13.229.188.59...
* Connected to github.com (13.229.188.59) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
root@mainhost:~/dump3#

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

1. Ofcourse what i understand from the output above is that the TLS connections (read https connections) are going thru fine, but my local-linux machine does not have the RootCA-certs (that signed the server-certs of github and others) to verify the server certificate that is offered by the TLS-server (read the github webserver on https:443 port...so that why the connection did not go thru further.....does this mean that the TLS-handshake has failed due to RV345????

thats all i can submit from my side...in summary iam able to work just fine and connect to https/tls websites and other sites on the internet from hosts via the RV345-router

Hope this helps in some way..