cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
2026
Views
0
Helpful
8
Replies

Big security issue in RV320's VPN implementation

aforster.home
Level 1
Level 1

I've been struggling for quite some time to make my RV320 work with VPN  (client to gateway), but never made it work.  Sometime ago I wrote this post ( https://supportforums.cisco.com/discussion/12556986/rv320-vpn-traffic-being-blocked-eth1-internet-interface ), but as usual, no one from Cisco responded. And, it seems to me, they didn't care looking. 

 

I started debugging that today again and erased all the configs in my rv320 and started from zero to make some tests. 

RV320 firmware:  1.2.1.13 (2015-05-04 18:40:51)

WAN config: dynamic IP from broadband provider;

LAN config: 172.16.0.0/24

One static IP on a web server: 172.16.0.2 (no port/forward configuration to internet).

Firewall rules: default

Routing features: default

VPN config: Easy VPN

- full tunnel;

- range: 172.16.100.100 - 172.16.100.129

VPN client: my cell phone (iphone 6 IOS 8.4)

 

Then I connected the VPN with my cellphone. Everything works beautiful. I can ping the web server and access its webpage. My IP is 172.16.100.100.

These are the logs:

(cellphone IP replaced by x.x.x.x; WAN1 IP replaced by y.y.y.y; Default Gateway (in broadband) replaced by t.t.t.t)

2015-08-01, 17:20:50ALLOWUDP x.x.x.x:500 -> y.y.y.y:500 on eth1
2015-08-01, 17:20:50VPN Log[grpips0][3] 0.0.0.0/0=== ...x.x.x.x===? #5: [Tunnel Authorize Fail] received Hash Payload does not match computed value 
2015-08-01, 17:20:50VPN Log[grpips0][3] 0.0.0.0/0=== ...x.x.x.x===? #5: [Tunnel Established] ISAKMP SA established 
2015-08-01, 17:20:59VPN Log[grpips0][3] 0.0.0.0/0=== ...x.x.x.x===? #5: [Tunnel Established] received XAUTH ack, established 
2015-08-01, 17:21:00VPN Log[grpips0][3] 0.0.0.0/0=== ...x.x.x.x===172.16.100.100/32 #5: [Tunnel Established] sent ModeCfg reply, established 
2015-08-01, 17:21:04VPN Log[grpips0]: cmd=up-client peer=x.x.x.x peer_client=172.16.100.100/32 peer_client_net=172.16.100.100 peer_client_mask=255.255.255.255 
2015-08-01, 17:21:04VPN Logip route add 172.16.100.100/32 via t.t.t.t dev eth1 metric 35 
2015-08-01, 17:21:04VPN Logiptables -t nat -I vpn -d 172.16.100.100/32 -j ACCEPT 
2015-08-01, 17:21:04VPN Logiptables -t nat -I vpn -s 172.16.100.100/32 -j ACCEPT 
2015-08-01, 17:21:04VPN Logiptables -t nat -I vpn_postrouting -d 172.16.100.100/32 -j ACCEPT 
2015-08-01, 17:21:04VPN Logiptables -t nat -I vpn_postrouting -o eth0 -s 172.16.100.100/32 -j ACCEPT 
2015-08-01, 17:21:05VPN Log[grpips0][3] 0.0.0.0/0=== ...x.x.x.x===172.16.100.100/32 #6: [Tunnel Established] IPsec SA established {ESP=>0x00b08b5b < 0xcd208bc5}

 

Cool.. VPN works. I run tcpdump on the web server and I can see pings coming from my smartphone, and replies going back to it:

21:08:15.946050 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 16160, seq 0, length 64

21:08:15.946176 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 16160, seq 0, length 64

21:08:16.941080 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 16160, seq 256, length 64

21:08:16.941185 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 16160, seq 256, length 64

21:08:17.795313 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 16160, seq 512, length 64

21:08:17.795418 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 16160, seq 512, length 64

21:08:18.750378 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 16160, seq 768, length 64

21:08:18.750481 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 16160, seq 768, length 64

 

 

So far, so good.

Now, I place my laptop outside the RV320, on one of the LAN ports of my broadband router, that is running as a bridge.  Then, I create a static ARP entry in it.. MAC address of the RV320, binding to 172.16.100.1. 

 

arp -s 172.16.100.1 ee:ee:ee:ee:ee:ee 

(being the ee:ee:ee....  the MAC address of my WAN1 port on the RV320)

 

Then, I simply configure 172.16.100.100 on my laptop.

 

Well.... if the RV320 is filtering the traffic right, my playground won't work, as any traffic from 172.16.100.100 should come ONLY through the IPsec tunnel. No traffic being routed to WAN1 with source IP 172.16.100.100 should be permited. 

Then I simply "ping -f 172.16.0.2". What happens? Below you can see what popped on my web server's tcpdump:

21:10:28.951570 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 0, length 64

21:10:28.951709 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 0, length 64

21:10:28.961758 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 1, length 64

21:10:28.961859 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 1, length 64

21:10:28.972013 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 2, length 64

21:10:28.972109 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 2, length 64

21:10:28.982921 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 3, length 64

21:10:28.983022 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 3, length 64

21:10:28.993730 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 4, length 64

21:10:28.993830 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 4, length 64

21:10:29.004768 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 5, length 64

21:10:29.004873 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 5, length 64

21:10:29.026701 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 7, length 64

21:10:29.026802 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 7, length 64

21:10:29.059009 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 10, length 64

21:10:29.059110 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 10, length 64

21:10:29.091599 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 13, length 64

21:10:29.091699 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 13, length 64

21:10:29.124175 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 16, length 64

21:10:29.124280 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 16, length 64

21:10:29.156216 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 19, length 64

21:10:29.156317 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 19, length 64

21:10:29.199306 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 23, length 64

21:10:29.199363 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 23, length 64

21:10:29.221259 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 25, length 64

21:10:29.221353 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 25, length 64

21:10:29.253807 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 28, length 64

21:10:29.253905 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 28, length 64

21:10:29.296508 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 32, length 64

21:10:29.296606 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 32, length 64

21:10:29.318713 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 34, length 64

21:10:29.318814 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 34, length 64

21:10:29.350855 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 37, length 64

21:10:29.350949 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 37, length 64

21:10:29.393310 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 41, length 64

21:10:29.393410 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 41, length 64

21:10:29.425004 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 44, length 64

21:10:29.425103 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 44, length 64

21:10:29.457200 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 47, length 64

21:10:29.457305 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 47, length 64

21:10:29.488946 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 50, length 64

21:10:29.489076 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 50, length 64

21:10:29.520720 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 53, length 64

21:10:29.520819 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 53, length 64

21:10:29.553566 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 56, length 64

21:10:29.553666 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 56, length 64

21:10:29.596479 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 60, length 64

21:10:29.596538 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 60, length 64

21:10:29.628458 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 63, length 64

21:10:29.628553 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 63, length 64

21:10:29.650428 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 65, length 64

21:10:29.650468 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 65, length 64

21:10:29.693366 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 69, length 64

21:10:29.693465 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 69, length 64

21:10:29.725338 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 72, length 64

21:10:29.725452 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 72, length 64

21:10:29.757547 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 75, length 64

21:10:29.757644 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 75, length 64

21:10:29.789898 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 78, length 64

21:10:29.790008 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 78, length 64

21:10:29.821554 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 81, length 64

21:10:29.821652 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 81, length 64

21:10:29.854321 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 84, length 64

21:10:29.854423 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 84, length 64

21:10:29.896542 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 88, length 64

21:10:29.896601 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 88, length 64

21:10:29.927671 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 91, length 64

21:10:29.927771 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 91, length 64

21:10:29.949184 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 93, length 64

21:10:29.949281 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 93, length 64

21:10:29.991947 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 97, length 64

21:10:29.992054 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 97, length 64

21:10:30.024130 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 100, length 64

21:10:30.024227 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 100, length 64

21:10:30.056326 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 103, length 64

21:10:30.056424 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 103, length 64

21:10:30.099432 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 107, length 64

21:10:30.099543 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 107, length 64

21:10:30.120446 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 109, length 64

21:10:30.120545 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 109, length 64

21:10:30.151988 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 112, length 64

21:10:30.152027 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 112, length 64

21:10:30.193983 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 116, length 64

21:10:30.194083 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 116, length 64

21:10:30.226926 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 119, length 64

21:10:30.227025 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 119, length 64

21:10:30.258387 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 122, length 64

21:10:30.258426 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 122, length 64

21:10:30.291359 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 125, length 64

21:10:30.291454 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 125, length 64

21:10:30.323801 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 128, length 64

21:10:30.323848 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 128, length 64

21:10:30.356123 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 131, length 64

21:10:30.356184 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 131, length 64

21:10:30.388940 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 134, length 64

21:10:30.389048 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 134, length 64

21:10:30.421361 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 137, length 64

21:10:30.421459 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 137, length 64

21:10:30.452204 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 140, length 64

21:10:30.452307 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 140, length 64

21:10:30.496219 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 144, length 64

21:10:30.496324 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 144, length 64

21:10:30.528830 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 147, length 64

21:10:30.528930 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 147, length 64

21:10:30.550019 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 149, length 64

21:10:30.550117 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 149, length 64

21:10:30.593232 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 153, length 64

21:10:30.593332 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 153, length 64

21:10:30.625727 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 156, length 64

21:10:30.625829 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 156, length 64

21:10:30.657979 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 159, length 64

21:10:30.658080 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 159, length 64

21:10:30.690574 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 162, length 64

21:10:30.690681 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 162, length 64

21:10:30.723347 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 165, length 64

21:10:30.723453 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 165, length 64

21:10:30.756336 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 168, length 64

21:10:30.756442 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 168, length 64

21:10:30.799671 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 172, length 64

21:10:30.799776 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 172, length 64

21:10:30.821444 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 174, length 64

21:10:30.821539 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 174, length 64

21:10:30.854381 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 177, length 64

21:10:30.854479 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 177, length 64

21:10:30.897559 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 181, length 64

21:10:30.897667 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 181, length 64

21:10:30.919707 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 183, length 64

21:10:30.919808 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 183, length 64

21:10:30.951253 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 186, length 64

21:10:30.951351 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 186, length 64

21:10:30.994165 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 190, length 64

21:10:30.994265 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 190, length 64

21:10:31.027105 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 193, length 64

21:10:31.027205 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 193, length 64

21:10:31.049194 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 195, length 64

21:10:31.049294 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 195, length 64

21:10:31.081616 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 198, length 64

21:10:31.081725 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 198, length 64

21:10:31.123314 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 202, length 64

21:10:31.123413 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 202, length 64

21:10:31.155815 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 205, length 64

21:10:31.155854 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 205, length 64

21:10:31.188496 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 208, length 64

21:10:31.188595 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 208, length 64

21:10:31.220918 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 211, length 64

21:10:31.221019 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 211, length 64

21:10:31.252904 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 214, length 64

21:10:31.253003 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 214, length 64

21:10:31.284921 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 217, length 64

21:10:31.285020 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 217, length 64

21:10:31.328765 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 221, length 64

21:10:31.328804 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 221, length 64

21:10:31.349406 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 223, length 64

21:10:31.349445 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 223, length 64

21:10:31.381530 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 226, length 64

21:10:31.381629 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 226, length 64

21:10:31.423701 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 230, length 64

21:10:31.423808 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 230, length 64

21:10:31.455777 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 233, length 64

21:10:31.455878 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 233, length 64

21:10:31.488702 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 236, length 64

21:10:31.488807 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 236, length 64

21:10:31.520783 IP 172.16.100.100 > 172.16.0.2: ICMP echo request, id 153, seq 239, length 64

21:10:31.520883 IP 172.16.0.2 > 172.16.100.100: ICMP echo reply, id 153, seq 239, length 64

 

I won't paste the entire ping -f here.... 

 

Well... this is a great explanation on the traffic was being blocked on eth1 on the post I made  18 days ago. The VPN traffic was being blocked on eth1 because I had created a default deny all rule blocking all traffic coming from WAN1 (eth1) and created my own permit filters, instead of using the ones that comes by default.

 

Im also attaching a diagram that shows exactly the topology used for the testing. 

I didn't test what happens if the VPN is configured but not in use.

 

Now, please:

1) Cisco team: fix this ASAP. Terrible bug... 

2) RV320 Users: stop using VPN until Cisco fix this bug. Otherwise, anyone that can route traffic into your RV320 using a source address in your VPN range can inject traffic in your network. 

 

8 Replies 8

aforster.home
Level 1
Level 1

Up.

 

Anyone to comment this security issue?

RV320, fw 1.2.1.13 (2015-05-04 18:40:51)

Followed the procedure, same results...

BUG CONFIRMED

Gimbus

Gimbus, thank you for the validation.

 

I really would like to see any comment also from Cisco support as this exposes everyone using VPN setup on these routers.  Also, besides that, there are also many critical bugs such as freezing and Connected/Inactive on WAN1, but I don't see any activity on the threads about that also. 

 

Even with a minor update to version 1.2.1.14 (from 1.2.1.13 mentioned in this thread), the issue discussed does not appear to be addressed as per the release notes.

I am researching the issue as I am looking to downgrade firmware to version 1.2.1.14 from v1.3.1.10, which was mysteriously removed by Cisco and from other forum posts, it has issues with VPN connectivity, which is what I attempting to fix.

I'm concerned that downgrading to v1.2.1.14 will bring back the random lockup and reboot issues (not to mention security issues) that this version is known for.

Any comments to this?

I am using the RV325, which uses the same firmware.

At least on the posts about 1.3.1.10, Cisco team didnt mention anything about this Easy VPN issue being fixed or not, even after I pointed this post and asked for a response. Are you watching this one?

https://supportforums.cisco.com/discussion/12941951/rv320-firmware-13110-no-release-notes

If I was running my rv320 yet, I would recreate this lab scenario and reproduce the testing if I were willing to run VPNs on it.  The security issue I described in the initial post is clearly about the iptables rules that are being created on the wrong interface whenever you create the tunnel. It should be be easy to fix if the support wants to..

I moved away to a Mikrotik router and I'm running my VPNs on OpenVPN, so I cant help with further testing this time.

Good luck!

Thanks for the quick response. I'd seen the thread you mentioned, but was not following it. I added it to my watch list. I appreciate the help.

Have you tested for the bug on 1.3.1.12?

Yes, I installed it 5 days ago. It appears to be working, though having some issues still with VPN where sometimes PPTP won't work, but P2TP does and then the opposite is true, very odd. It could be an issue with the server, but not seeing any difference vs. 1.3.1.10 firmware as of yet. 

Any other testing results posted here would be helpful.

Unfortunately, I don't have the time or resources to test for the security issue mentioned originally in this post.