WAN NAT port forward retransmission on Reolink camera
Hello all,
I have been working on an issue with some security cameras I have that I can not figure out. I have worked with the vendor to their FTP server with no issues observed. I have traffic coming in from my remote cameras to my firewall that has a NAT port forward setup to an FTP server on my LAN. LAN traffic to the FTP server works fine, but the WAN never seems to get past syn. The camera sends a SYN, and instead of a SYN/ACK I get a TCP retransmission. I am not extremely well versed in Wireshark so I am hoping someone can assist. I have only exported the traffic to the FTP port, and I have already sanitized it. Any ideas? I tried to attach the file, but It would not let me. I have shared it from my Google Drive link text
"my firewall" - is this consumer or enterprise level? Does it have logging?
Verify that you see the camera hit the firewall then see if a drop or reject rule was hit.
(The capture file shows the client send a syn, wait 1 second, send a syn, wait 2 seconds, send a syn.)
I assume the capture was made on the WAN side of the firewall? Can you make a capture on the FTP server as well?
Hello @Chuckc, and @SYN-bit, my apologizes for not clarifying. In regards to the firewall it is PFSense. I do have logging enabled and a rule set to allow all ports/protocols from my source IP. When I attempt to test, I see the logs come back with Passed traffic, and the capture is happening on the FTP server that is sitting behind this Firewall.
A little more info, I have the same cameras locally setup using the NAT port forward with reflection setup to test, and these cameras hit the Firewall and fully build a connection working with no issues observed. As I was able to connect to the WAN IP using this method, I expected that I could with my remote cameras as I have an allow all rule from that IP address. However that has not been the case. I have added another capture that has the remote ...(more)
The NAT setup is not changing the outside camera address to one on the local subnet?
So then the FTP server has a route back to the outside address?
(back through the PFSense with either a static or default gateway route)
Can you make a
tracerouteon the FTP server to the WAN camera IP address?Is there a firewall (iptables?) running on the FTP server that is dropping the camera
SYN?This seems to be a routing/nat/firewall rule issue. With the (changing) IP translations in the capture files, this can not be solved. Solving it would need insight in the routing table and the host firewall rules (if any) of the FTP server.
As the TCP checksum errors indicate that the capture was made on the FTP server, the fact that there are no SYN/ACK packets in the packet capture seem to point to one of the following:
Is this simply a case of a host based firewall running on the FTP server (192.168.16.128) silently dropping the TCP connection requests (the SYNs ) from the remote (WAN connected) camera?
Hello @Chuckc, sorry for the delayed response, I have been working with the Firewall forums, and with Serverfault also trying to figure this issue out. Yes, I can successfully make a tracert back to the WAN IP of the remote camera. The server the FTP is running on is a Windows Server 2016. I had originally made explicit rules to allow the traffic, and that did not work. I disabled the Windows firewall, with no change. I also saw mention of people trying to disable the firewall but it still running, so I killed the process, no change. Beyond the Windows firewall there is nothing else on the server that i have installed. I disabled all other network ports on this server to test and ensure it was not trying to use one of them, I have ensured that IpV6 is disabled also.
Hello @SYN-bit, I can ping the WAN IP of the remote camera, and get a tracert. Would that indicate that I have a route back? If not, how could I verify this? I have fully disabled the server FW for testing with no change.
Hi @SidELyti,
Assuming all of the above is correct, I would really need unfiltered and unsanitzed traces, arp table, routing tables etc to find the problem. Otherwise it is just shooting with hail hoping to hit something. A few more ideas:
- Does the FTP server have a filtering mechanism that might only allow certain IP rnages?
- Is there any ARP traffic visible after receiving the SYN packets?
- Are there any SYN/ACK packets on other ports?
- Is it possible to capture with a SPAN port ...
(more)Hello @Jim Young, @Chuckc, @SYN-bit, I believe that you may have all been right about the Windows firewall, however this still does not make sense to me. I started the FW service again, then enabled the Windows FW logging and observed that there is a drop if I am reading this correct. However I also have an open all rule for inbound to port 21. I changed it back to 21 for testing purposes. Please see images. Any idea why It would still be blocking? FW RuleDrop