I have both a ASUS RT-AC68U primary router and a Zywall USG20W firewall connected to the Internet. The firewall supports an IPSec tunnel to a remote location. The primary router has a static route for the remote network pointed to the LAN firewall connection. All routing appears to be working. When in this configuration I cannot bring up an https session with my remote NAS box. If I add a router to my PC for the remote network pointed directly to the firewall, the https session works fine. So, bouncing the traffic thru the primary router is not working. Running wireshark, I see the following error messages: 171 16.375639000 172.29.35.30 172.29.27.100 TCP 66 [TCP Spurious Retransmission] 443→1682 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1386 SACK_PERM=1 WS=16 172 16.375701000 172.29.27.100 172.29.35.30 TCP 66 [TCP Dup ACK 133#1] 1682→443 [ACK] Seq=210 Ack=1 Win=66304 Len=0 SLE=0 SRE=1 I did try lowering my MTU on the PC Ethernet port to 1386 thinking the primary router may be passing too large of a packet for the IPSec tunnel on the Firewall, but the same problem occurred. Any thoughts on what might be happening? asked 07 Jun '15, 11:04  SedonaRider |
3 Answers:
What I can say is that the SYN and the ICMP Request got an answer. But the ACK of the 3Way Handshake and all other following packets don´t reach the NAS. The cause I can´t tell you at the moment. Can you trace next to the internal FW or the NAS? And as you told you send to the router Asus and the Answers are sent from the FW directly to the client. So it could be interesting what happens between Router and FW. answered 07 Jun '15, 15:31  Christian_R Thank you for looking at the records. It is surprising that bouncing the packet thru the primary router would disrupt the communication. I uploaded a trace of where I have the static route in my PC and the communication works fine. https://www.cloudshark.org/captures/56ac591188f5 I am not experienced with reading traces, but I do see what you are saying when comparing it to the trace where it works. I agree it would be good to see what is happening between the ASUS and firewall, plus probably the firewall and NAS box at the remote location. The ASUS static route is working for packets, so I would suspect the packet is being forwarded to the firewall. There are no error or blocked messages in the log, so it would seem the firewall would pass this forward to the NAS box as it has the other messages. I wonder if there is something in the SSL handshake that does not like the return being one hop shorter. (07 Jun '15, 17:49) SedonaRider It is like I guessed. But why it is so I Can't tell you without further documentation. (08 Jun '15, 00:13) Christian_R |
I'm personally seeing 4 or so (RST,ACK) packets to that IP address of 172.29.35.30. Which tells me that packets are indeed getting there, however, something (possibly a firewall) is blocking traffic to there. Please correct me if I'm wrong guys. answered 07 Jun '15, 21:55  Beldum The RST are send by the client. In this case they are just a follow up. (08 Jun '15, 00:17) Christian_R Ok got it, but what could be causing the client to be sending the RST packets? I do see that the 3-way handshake is successful to 172.29.35.30 and then there is a client Hello at the ssl handshake, then there are a whole bunch of Hello retransmissions from the client to the NAS. (08 Jun '15, 00:23) Beldum The prob is that the 3way handshake is not succesfully for both sides. The NAS is missing the ACK (asuming , because I only have the trace of the client) And the RST is probably application related in this case. (08 Jun '15, 00:33) Christian_R |
Apparently there is asymmetric routing in your setup. Frame #1: Source/Destination MAC both Austek. So, the SYN goes to your ASUS router The ZyWall is a statefull firewall, and those devices don't like to see only parts of a TCP connection. They need to see the whole traffic to be able to handle it correctly. To test my assumption, please add a route to the remote network to the ZyWall on your PC. If that works, there is something wrong with the L2 forward of the router to the Firewall (maybe the firewall does some MAC checks as well). If it does not work, even with the route to the firewall, there is something else broken in your network and/or router/firewall. However, it's impossible to figure out what, by looking at capture files! So, in that case, please double check the configuration of all involved systems and ask your local ZyWall guru for help. Regards answered 08 Jun '15, 12:53  Kurt Knochner ♦ Yes, the route is asymmetrical. I have added the route to the remote network to my PC so it points directly to the Zywall firewall instead of the primary router and everything works fine. I had not thought of the firewall doing mac checks. It is a good point. However, you would think something would turn up in the log of the Zywall if it detects a problem. I wonder if the ReadyNAS box is detecting a different hop count each way and dropping the session. Hence, the reason why no message is returned. I have not found a log to check on that box. (08 Jun '15, 13:36) SedonaRider It's (most certainly) not the NAS, as a different hop count (TTL) is totally normal and should not lead to any network disruption. I think it's the ZyWall, even if it does not log anything. Could be a bug or a simple (missing) config option. (08 Jun '15, 13:41) Kurt Knochner ♦ If the NAS had a problem with TTL counts, it would not allowed to connect the nas to a network where a dynamic routing protocol is active. (08 Jun '15, 22:30) Christian_R |
Could you provide us a trace on cloudshark or dropbox?
It is my first time using Cloudshark, but I think it is now uploaded. The URL is: https://www.cloudshark.org/captures/c8bf551babc8
My PC is 172.29.27.100 and the NAS box is 172.29.35.30
I should add that I have a ping monitor running in the background which works fine, indicating the routing is set up correctly from my PC to the primary router, to the firewall, across the IPSec VPN to the remote location and back.