Need to allow access to DVR in the WAN network to LAN computers

jetberrocal

"with far more info than the pfSense packet capture provides. "

How is that exactly.. Why would the packet capture in pfsense not see what that the switch would, when pfsense is 1/2 of that conversation anyway??

Clearly your getting a 401 error saying your NOT Authorized…

As to seeing if limiting to IP, I meant if he was limiting his sniff to a specific IP he would not see multicast traffic since it would be to the multicast address not his specific IP like 192.168.0.3 etc..

In the first part of the sniff your client ask for a manifest of something - and you get that just fine.

But then after that you just get 401.. Why have no idea, not sure what exactly your trying to do, other than dvr is giving you 401, and then your client gets something from the dvr. So there are 3 different conversations here all started by your client 192.168.0.3. First one he gets a manifest of something and that conversation is closed with your normal fin,ack , then he starts another conversation gets told 401, and he closes the conversation with RST, then he gets some other info profile.xml and then again he closes the conversation with RST

So that is a bad conversation, or is that a good conversation that works? Where is a good conversation where you start viewing video, since maybe that is sent in a different protocol?? Either way I wouldn't think you would want to see 401 errors.. Do you have to log in or something?? Do devices have to be authed before hand??

Thank you for your interest.

I will have to ask the DVR provider if its need to pre authorized the client, but I suspect that it does not.

I know that have to enter a user/pass combination to connect to the DVR. But that is entered in the client program and I know that its get accepted because if I enter a wrong one the application returns a credentials error. In the case of the packet capture I posted I used the correct user/pass. Also when I connect to the DVR using Internet Explorer I also have to enter the credentials and get accepted.

In IE there is an option to see the stream per channel in jpeg mode. When I select that option I can see each channel in a set of jpegs stream really nice.

The application is to show all channels at the same time probably in full streaming instead of jpegs. Once the credentials are accepted the application starts a loading phase which fails.

JKnott

How so? Just don't capture the traffic your using to make the remote connection if capturing the interface your hitting pfsense on, etc.

If you're running into congestion/timing issues etc. Not common, but possible. As for your traffic, that's one more thing to filter. On my systems, I actually have a button on the display filter bar for a display filter, to not show traffic containing the MAC of the computer I'm running Wireshark on.

How does it answer his 401 error problem?

Problem? What problem??? ;)

Actually, this thread shows how traffic monitoring can be used to help identify a problem. However, that not authorized error indicates the problem is likely not in pfSense.

jetberrocal

@JKnott:

How so? Just don't capture the traffic your using to make the remote connection if capturing the interface your hitting pfsense on, etc.

If you're running into congestion/timing issues etc. Not common, but possible. As for your traffic, that's one more thing to filter. On my systems, I actually have a button on the display filter bar for a display filter, to not show traffic containing the MAC of the computer I'm running Wireshark on.

How does it answer his 401 error problem?

Problem? What problem??? ;)

Actually, this thread shows how traffic monitoring can be used to help identify a problem. However, that not authorized error indicates the problem is likely not in pfSense.

There is a problem related to the pfsense.

The network and the computers were able to connect to the DVR via the iWatch application before pfsense was implemented.

The previous Router/Firewall was a Netgear Wirelless device with 4/8 ports. I took out the Netgear and replace it by the pfsense. Now computers can not connect to the DVR via iWatch. Clearly there is something that pfsense does that Netgear dont or viceversa.

johnpoz

Dude how exactly is pfsense even involved in conversation between 192.168.0.3 and 192.168.0.99

I would assume these IPs on on the same network 192.168.0/24

Your computers can not connect from WHERE?? They are on the wan side of pfsense.. Is pfsense NATTING? The sniff you gave was 2 devices on the same network it would seem to me.

If your iwatch is running on device A on network ?? Sniff on that interface of pfsense. If dvr is on network B, also sniff on that interface of pfsense.. Your sniff shows 2 devices which unless you have some odd mask set are on the same network. Are your bridging in pfsense? Pfsense should not have even seen that traffic.

Please draw up your network and what networks are where and where are the devices and are you natting between these networks and or doing any port forwarding, etc.

Is 192.168.0.99 pfsense WAN ip?? And your port forwarding into your dvr behind pfsense on some other network? If so do the sniff on the LAN interface of pfsense. If your dvr is trying to send something to the client on your wan via multicast then no your client would never see that traffic nor would pfsense show it on a sniff on the wan interface.

jetberrocal

This has become a long thread. I am going to refresh the network structure.

D1 = DVR - 192.168.0.99 - Static IP
D2 = President Computer
F1 = Router/Firewall - 192.168.0.3 DHCP Assign by Cable Modem

F1 now is the pfsense, before was a Netgear Wireless Router

LAN - 192.168.1.0/24

Computers in LAN want to connect to DVR. With Netgear was successful, with pfsense is not

jetberrocal

Recalling the problem.
LAN computers connect to the DVR via IE successfully and can see one channel at a time in jpeg mode.
LAN computers fail to connect to IE to see the full stream with all channels at the same time.
LAN computers fail to connect to the DVR via iWatch which provide all the channels streams at same time.

JKnott

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.

jetberrocal

@JKnott:

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.

JKnott

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.

johnpoz

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?

jetberrocal

@JKnott:

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.

JKnott

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.

jetberrocal

@johnpoz:

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.

@johnpoz:

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.

jetberrocal

@JKnott:

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.

JKnott

That's on the WAN side of pfSense. After trying there and capturing the results, try on the WAN side too.

JKnott

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.

johnpoz

"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??

JKnott

^^^^
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.

jetberrocal

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.

JKnott

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>