RV120W blocks DSL modem configuration

lagrangerx · ‎11-10-2011

I work for a small pharmacy that uses a Cisco RV120W router to separate hospital VPN traffic from general internet traffic. The VPN traffic is redirected to a dedicated T1 line (Or T-something, I wasn't involved in the actual setup of the VPN) connecting our store directly to the local hospital, and general internet traffic gets redirected to a ZyXel PK5000Z DSL modem (We have Qwest/CenturyLink 7m/768k). The DSL modem is running the latest version of our ISP's custom firmware.

Prior to installing the VPN and RV120W, LAN traffic was handled with a basic D-Link DI-604 wired router. The router itself was configured with an IP of 10.100.100.254 (With all LAN clients assigned DHCP IPs in the 10.100.100.XXX range) and "WAN" IP of 192.168.0.4, and the modem configured with a LAN IP of 192.168.0.1. The router was connected from it's WAN port to one of the LAN ports on the modem.

The modem has it's own built-in router, but the store owner wished to have an "extra layer of protection", so to speak, and had the D-Link router installed to serve that purpose. Prior to connecting the VPN, a second router was admittedly redundant and unnecessary. However, now that we have the hospital VPN, a second router is REQUIRED to properly separate the VPN traffic from other internet traffic, since the router built into the DSL modem doesn't have the capabilities to perform this task (We had already attempted to operate the VPN over DSL...it failed miserably and spectacularly. A dedicated T1 was the only reliable option).

Anyway, when installing the RV120W, we duplicated every possible setting from the old router, including configuring it with a LAN IP of 10.100.100.254 and a "WAN" IP of 192.168.0.4 and connecting it in exactly the same fashion as the old router (Modem LAN to Router WAN). Essentially, the RV120W was set up exactly the same as the old D-Link router, just with the added VPN functionality.

The problem is this: ever since installing the RV120W, we are no longer able to access the DSL modem's administration page (http://192.168.0.1). We were able to do this without any trouble whatsoever with the old D-Link router, but the RV120W seems to be blocking it somehow. Any attempt to load the modem administration page just forever sits at "Waiting for 192.168.0.1...". It never times out, it never shows any error messages. It just sits there, forever trying to load the page, showing nothing but "Waiting for 192.168.0.1..." at the bottom of the screen.

Now, we know for a fact that it is NOT a problem with the modem, because if we connect a computer directly to it via ethernet (Completely bypassing the RV120W), the administration page loads perfectly fine. And, admittedly, we could configure the modem in this manner whenever required. HOWEVER, the modem is located in a rather inconvenient location (In the ceiling, sitting on top of a ceiling tile), and having the ability to remotely manage it like we could before would definitely be something we want to be able to do again...especially since there are plans in motion to install new pharmacy equipment that will require us to do a ton of "trial and error" configuration to the modem.

The RV120W has been updated with the latest firmware, yet the problem still persists.

Any assistance with this problem would be appreciated.

lagrangerx · ‎11-16-2011

Apologies if this distresses anyone. I am just wishing to find resolution to this problem prior to installation of our new equipment next month.

If it helps, I was able to record an "attempt" to connect to the Modem administration page by enabling packet capturing on the router. Here is what Wireshark says about it (The LAN IP of the workstation trying to load the modem admin page is 10.100.100.202):

No. Time Source Destination Protocol Length Info

133 5.813203 10.100.100.202 192.168.0.1 TCP 62 4706 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

Frame 133: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)

Ethernet II, Src: AsustekC_36:17:c0 (00:17:31:36:17:c0), Dst: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a)

Internet Protocol Version 4, Src: 10.100.100.202 (10.100.100.202), Dst: 192.168.0.1 (192.168.0.1)

Transmission Control Protocol, Src Port: 4706 (4706), Dst Port: http (80), Seq: 0, Len: 0

Source port: 4706 (4706)

Destination port: http (80)

[Stream index: 12]

Sequence number: 0 (relative sequence number)

Header length: 28 bytes

Flags: 0x02 (SYN)

Window size value: 65535

[Calculated window size: 65535]

Checksum: 0x41e7 [validation disabled]

Options: (8 bytes)

No. Time Source Destination Protocol Length Info

134 5.815267 192.168.0.1 10.100.100.202 TCP 58 http > 4706 [SYN, ACK] Seq=0 Ack=1 Win=21760 Len=0 MSS=1360

Frame 134: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)

Ethernet II, Src: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a), Dst: AsustekC_36:17:c0 (00:17:31:36:17:c0)

Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 10.100.100.202 (10.100.100.202)

Transmission Control Protocol, Src Port: http (80), Dst Port: 4706 (4706), Seq: 0, Ack: 1, Len: 0

Source port: http (80)

Destination port: 4706 (4706)

[Stream index: 12]

Sequence number: 0 (relative sequence number)

Acknowledgement number: 1 (relative ack number)

Header length: 24 bytes

Flags: 0x12 (SYN, ACK)

Window size value: 21760

[Calculated window size: 21760]

Checksum: 0x41ee [validation disabled]

Options: (4 bytes)

[SEQ/ACK analysis]

[This is an ACK to the segment in frame: 133]

[The RTT to ACK the segment was: 0.002064000 seconds]

No. Time Source Destination Protocol Length Info

135 5.815638 10.100.100.202 192.168.0.1 TCP 60 4706 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 135: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)

Ethernet II, Src: AsustekC_36:17:c0 (00:17:31:36:17:c0), Dst: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a)

Internet Protocol Version 4, Src: 10.100.100.202 (10.100.100.202), Dst: 192.168.0.1 (192.168.0.1)

Transmission Control Protocol, Src Port: 4706 (4706), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

Source port: 4706 (4706)

Destination port: http (80)

[Stream index: 12]

Sequence number: 1 (relative sequence number)

Acknowledgement number: 1 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

Window size value: 65535

[Calculated window size: 65535]

[Window size scaling factor: -2 (no window scaling used)]

Checksum: 0xae47 [validation disabled]

[SEQ/ACK analysis]

[This is an ACK to the segment in frame: 134]

[The RTT to ACK the segment was: 0.000371000 seconds]

No. Time Source Destination Protocol Length Info

136 5.816219 10.100.100.202 192.168.0.1 HTTP 378 GET / HTTP/1.1

Frame 136: 378 bytes on wire (3024 bits), 378 bytes captured (3024 bits)

Ethernet II, Src: AsustekC_36:17:c0 (00:17:31:36:17:c0), Dst: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a)

Internet Protocol Version 4, Src: 10.100.100.202 (10.100.100.202), Dst: 192.168.0.1 (192.168.0.1)

Transmission Control Protocol, Src Port: 4706 (4706), Dst Port: http (80), Seq: 1, Ack: 1, Len: 324

Source port: 4706 (4706)

Destination port: http (80)

[Stream index: 12]

Sequence number: 1 (relative sequence number)

[Next sequence number: 325 (relative sequence number)]

Acknowledgement number: 1 (relative ack number)

Header length: 20 bytes

Flags: 0x18 (PSH, ACK)

Window size value: 65535

[Calculated window size: 65535]

[Window size scaling factor: -2 (no window scaling used)]

Checksum: 0x215d [validation disabled]

[SEQ/ACK analysis]

[Bytes in flight: 324]

Hypertext Transfer Protocol

No. Time Source Destination Protocol Length Info

137 5.817384 192.168.0.1 10.100.100.202 TCP 54 http > 4706 [ACK] Seq=1 Ack=325 Win=21436 Len=0

Frame 137: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)

Ethernet II, Src: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a), Dst: AsustekC_36:17:c0 (00:17:31:36:17:c0)

Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 10.100.100.202 (10.100.100.202)

Transmission Control Protocol, Src Port: http (80), Dst Port: 4706 (4706), Seq: 1, Ack: 325, Len: 0

Source port: http (80)

Destination port: 4706 (4706)

[Stream index: 12]

Sequence number: 1 (relative sequence number)

Acknowledgement number: 325 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

Window size value: 21436

[Calculated window size: 21436]

[Window size scaling factor: -2 (no window scaling used)]

Checksum: 0x5947 [validation disabled]

[SEQ/ACK analysis]

[This is an ACK to the segment in frame: 136]

[The RTT to ACK the segment was: 0.001165000 seconds]

No. Time Source Destination Protocol Length Info

138 6.006870 10.100.100.202 192.168.0.1 TCP 60 [TCP ACKed lost segment] 4706 > http [ACK] Seq=325 Ack=206 Win=65330 Len=0

Frame 138: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)

Ethernet II, Src: AsustekC_36:17:c0 (00:17:31:36:17:c0), Dst: Cisco_88:9c:8a (c4:7d:4f:88:9c:8a)

Internet Protocol Version 4, Src: 10.100.100.202 (10.100.100.202), Dst: 192.168.0.1 (192.168.0.1)

Transmission Control Protocol, Src Port: 4706 (4706), Dst Port: http (80), Seq: 325, Ack: 206, Len: 0

Source port: 4706 (4706)

Destination port: http (80)

[Stream index: 12]

Sequence number: 325 (relative sequence number)

Acknowledgement number: 206 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

Window size value: 65330

[Calculated window size: 65330]

[Window size scaling factor: -2 (no window scaling used)]

Checksum: 0xad03 [validation disabled]

[SEQ/ACK analysis]

[TCP Analysis Flags]

[This frame ACKs a segment we have not seen (lost?)]

Admittedly, my knowledge on the raw contents of ethernet packets is rather limited, so this is getting way beyond my expertise. However, having actually done the packet capture test a few times now, I can say for a fact that every attempt to access the modem administration page through the RV120W halts at a "TCP ACKed Lost Segment" error. As mentioned before, connecting DIRECTLY to the modem through ethernet allows the page to load perfectly fine. It's when trying to load it THROUGH the RV120W that it cannot load, like it is being blocked somehow.

Here's the other odd thing...if I try to load a "random" page on the modem administration that I know for a fact does not exist, such as http://192.168.0.1/chocolatecake.html, it properly returns a 404 exactly as it should, which proves that the RV120W isn't outright blocking admin traffic to 192.168.0.1 (And neither is the modem, which should have already been evident in that it works perfectly fine if I bypass the RV120W entirely). It's only when the modem starts transferring the actual data (HTML, images, etc) to display the administration page that it gets blocked and stalls, resulting in the never-ending "Waiting for 192.168.0.1".

Thank you again for any assistance.

lagrangerx · ‎11-30-2011

Apologies if this is inappropriate, this shall be my final attempt to seek resolution to this issue, as we are still in need of a solution to this problem. Any help whatsoever that can be provided will be greatly appreciated.