Need to allow access to DVR in the WAN network to LAN computers
-
In the captures where you get the unauthorized errors, I see http. Is that what the DVR uses? Should it be https? The fact that you're getting that error indicates you're reaching the DVR. This is where Wireshark can come in handy, running on the computer you're trying to reach the DVR with. See what's going out and coming back with the Netgear. Then compare with pfSense. Without that, we're just guessing.
I can not test with the Netgear anymore it was converted to a AP mode Wireless router. Maybe what I could do is installing Wireshark in the President computer and capture from that one to the DVR. That is going to take some time.
-
Any chance you could get that Netgear back, at least temporarily? It would help to have a comparison. Also, according to your diagram, the president's computer doesn't connect through the pfSense computer. If the problem is on the LAN, then you have to test from there.
-
So are you natting between your 192.168.0/24 network and your lan network 192.168.1/24 – I Have to assume so since your sniff which had to have been done on pfsense wan only showed the 192.168.0.3 address of pfsense..
So what does a good sniff look like from D2 with wireshark when talking to the dvr doing what they want.
And what does a sniff look like on both the wan and lan of pfsense when it doesn't work.All I can tell you is there were RST sent and a 401 error. There was no video in that conversation at all.. So have no idea how video actually gets passed. Is quite possible the client says hey send me data to 192.168.1.x which your dvr would send to your cable router since that would be its gateway.
How did you have your previous router setup.. My guess it you were just using it as AP and dvr and client were on the same layer 2 network via either wifi or plugged into the switch ports on your wifi router. Or you were all behind the netgear and not split like this.
Why do you not do this??
cablemodem -- pfsense -- switches... All your other devices!! dvr and clients and even any AP.
So they are all on the same layer 2 network.
How your setup now your devices are not on the same layer 2, so multicast is not going to work. Broadcasting for names or such not going to work. Your natting between devices, and if not natting you would have a asymmetrical routing problem between devices on wan of pfsense and lan of pfsense.
What exactly is this split setup getting you?
-
Any chance you could get that Netgear back, at least temporarily? It would help to have a comparison.
Unlikely. This is a live system. Taking the pfsense out to put the Netgear will require for my team to be at the client site a Sunday when they are not working.
-
Following on what johnpoz says, did this work on the LAN through the Netgear? While multicasts can pass through a router, it may be necessary for configuration to allow for it. Broadcasts are generally not passed through a router at all. This means that things that work on a flat network might not when passing through a router.
While many of us here are quite familiar with IP and firewalls, we're not likely to be familiar with that DVR, so we need accurate info.
-
How did you have your previous router setup.. My guess it you were just using it as AP and dvr and client were on the same layer 2 network via either wifi or plugged into the switch ports on your wifi router. Or you were all behind the netgear and not split like this.
The Netgear was not AP mode before. Now we change it to AP mode after implementing pfsense.
Why do you not do this??
cablemodem – pfsense -- switches... All your other devices!! dvr and clients and even any AP.
So they are all on the same layer 2 network.
How your setup now your devices are not on the same layer 2, so multicast is not going to work. Broadcasting for names or such not going to work. Your natting between devices, and if not natting you would have a asymmetrical routing problem between devices on wan of pfsense and lan of pfsense.
What exactly is this split setup getting you?
I think they has the network that way because is easier to setup only the Cable Modem for port forwarding the DVR to the Internet than do double port forwarding the DVR to the Internet. Maybe the Netgear did not have the capability to do it or they did not have the knowledge to do it.
Now I could suggest that route to the owner to move the DVR to the LAN and then configure the double port forwarding.
-
Following on what johnpoz says, did this work on the LAN through the Netgear? While multicasts can pass through a router, it may be necessary for configuration to allow for it. Broadcasts are generally not passed through a router at all. This means that things that work on a flat network might not when passing through a router.
While many of us here are quite familiar with IP and firewalls, we're not likely to be familiar with that DVR, so we need accurate info.
I have the possibility to do the capture in other computer that I can add to the 192.168.0.0/24 network later this day, but doing the capture with the Netgear really is unlikely.
-
That's on the WAN side of pfSense. After trying there and capturing the results, try on the WAN side too.
-
Multicast is doesn't really work over a layer 3 route or nat - its designed to be on the same layer 2 network.
There was some mention of multicast earlier. Is it used by the DVR? If so, a router, including pfSense has to be configured to pass it. While I suppose that could be done manually, it's generally done with IGMP (The Internet Group Management Protocol). https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol
Also, you can't NAT multicast. It has to be forwarded with the multicast address intact.
However, without knowing what's actually on the wire, it's impossible to say what the issue is.
-
"I have the possibility to do the capture in other computer that I can add to the 192.168.0.0/24 network later this day"
Well that was 2 days ago.. Maybe he gave up, maybe he put everything on the same layer 2??
-
^^^^
I'm still curious as to whether it actually worked on the LAN with the Netgear box. I don't know if multicast is used and what the authorization problem was about. -
I tried with the second comouter but It happen that could not do the test because It was a Linux machine while the DVR app is not compatible.
I hace to do It in the Owner's computer. I am planning to do the test today. If can't do it today I will have to wait for next week.
-
When you try with Wireshark on that computer, you probably want to use a capture filter to limit what you have to sort through. When you start Wireshark, double click on the interface. Then in the capture filter box enter host <ip address="" of="" the="" dvr="">, click on OK and then on Start. You'll then see packets to or from the PVR. Multicast addresses are within the range of 224.0.0.0 to 239.255.255.255. Any multicast packets, from the PVR will have a destination address within that range and whatever it's IP address is for the source.</ip>
-
When I filter in Wireshark it will capture the multicast lines also?
I was planning to capture all without filter so it will capture the broadcast and multicast along with the DVR lines.
But if you say that Wireshark is intelligent enough to know which multicast to capture when filtered I will try it that way.
-
It will capture everything to or from the specified IP address, including multicast, as multicast packets will have the IP address of the PVR as the source address. You should see broadcast IP traffic, but not ARP or IPv6, You will see only unicast traffic to/from the computer you're running Wireshark. on. Another way is to use the MAC address of the PVR. In that case, the capture filter would be ether host <mac address="">. This will then include all protocols, including ARP, IPv6 etc.
You may want to practice a bit with Wireshark first. It's available for Linux too and is often very easy to install.</mac>
-
I did the the capture from PC directly connected to the DVR (In same subnet) but is to big for the attachments.
Do you know how can I cut the important segments and how to identify the important segments?
Or I can split the file in zip files of 5000kb and make two post because compressed is close to 15 MB.
I did an Export packet disecctions to plain text. Maybe is good enough.
-
No that is going to suck.. Just pull the data out and leave all the headers..
Or post it elsewhere.. Or yeah split up the zip file, any zip software can split up a zip to whatever size you want.
What I can tell you is I see 5 conversations starting in that sniff vs your other one, I do see a 401 error in it. Bu the last conversation goes on and on with lots of data being passed.
-
I upload it to my Google Drive and share it:
https://drive.google.com/file/d/0B5nlqqyTt-VtNGFuVnBDVnVwcjg/view?usp=sharing
I dont expect to close the account or delete the file in many years, so it will be here available in the forum for others to see.
-
I think I might need to run other capture with "Turn off TCP reassembly in the preferences for TCP."
In the critical step Wireshark went to "tcp segment of a reassembled pdu " Maybe the data behind the header lines can tell you what happen.
I am going to try do it today but probably I will have to wait to next week.
If it is not needed another capture please tell me.
-
Well the only thing I see in this capture other than the other capture is there is an extra conversation started by the client to the same port 99 that gets lots of data back
DVRPOST /dvr/cmd HTTP/1.1 Host: 192.168.0.99:99 Authorization: Basic YWRtaW46MTIzNDU2AA== Content-Length: 242 Content-Type: multipart/form-data; boundary=----DVRBoundary ------DVRBoundary Content-Disposition: form-data; name="datafile"; filename="command.xml" Content-Type: text/xml <dvr platform="Hi3520"><getconfiguration file="profile.xml"></getconfiguration></dvr>HTTP/1.1 200 Ok Content-Type: text/xml Set-Cookie: sessionid=30ea7a1c-3a96-72cc-7da6-593a3928ba54 Content-Length: 4622 <dvr platform="Hi3520"><getconfigurationresponse return="0"> <dvr platform="Hi3520"><profile> <platform hardware="Hi3521-16CH-J" model="16CH" software="2.0b49" mcuconfigurable="True"></platform> <processors> <processor id="0" encodehq="1267200" encodelq="316800" decode="633600"> <snipped>[/code] In your other first sniff that conversation never happened.. Are you doing any sort of filtering on this sniff? The start of this conversation that never happens in your first sniff is like .0001 second later, etc. This is where all that data gets sent back to the client. What happens on the client when it doesn't work?</snipped></processor></processors></profile></dvr></getconfigurationresponse></dvr>
