- #Lorex dvr client not working how to#
- #Lorex dvr client not working update#
- #Lorex dvr client not working full#
- #Lorex dvr client not working mac#
I'm combining a few posts to present your next couple of possible solutions to take a look at. If that is the case I would exactly expect to see that "only the lan router is accessible and none of the rest" It can still be explained with asym routing (of lack thereof, in this instance): remote host -> vpn server -> lan router -> vpn server -> remote hostĪccessing the "lan router" directly doesn't need to route through said router so the SYN and SYN ACKS are both seen by all the relevant devices. The way I read it was he could ssh the Pi and get to the LAN routers web interface. Would need to see traffic traces on both sides of the VPN server to see what's going and then what the DVR received and is sending out to make sure it's not going in circles. It's very possible the DVR in this did receive the connection request, DVR replied back to its gateway (a different router than Raspberry) which may have dropped it due to the assym routing issue (seeing the SYN ACK but not the SYN that started it all). He can reach the Raspberry Pi VPN end point but nothing behind the Raspberry. It's a router, but the main router so to speak. I believe SSH referred to the Raspberry Pi itself - the device acting as the VPN server. I wonder can the OP ping other things on the LAN? My thing is ssh and contacting the router work though, which is odd.
The router above would see a SYN ACK without having seen the original SYN packet and might just drop it. Assymetric routing can come in play that needs to be enabled in some products. It is technically fine if the routers don't mind. Remote host -> vpn -> dvr -> router -> back to same lan -> vpn server -> remote host You essentially end up with two routers on the same network. I've unfortunately found out that some simpler type of routers don't like routing a subnet back out on to the same LAN it just came from (ie hair pinning).
#Lorex dvr client not working full#
Setting up full NAT on your Raspberry VPN traffic will be easier in most cases.Īgreed in principle on the NAT not being great. The latter is more complicated to setup and doesn't always work well if there are less-than-capable routers involved that don't like this kind of thing. If your VPN subnet is 10.8.0.0/24 for example you would configure your main router with a static route for 10.8.0.0/24 next-hop/via raspberry-192.168.1.x IP address
#Lorex dvr client not working how to#
The default gateway aka your router (NOT the Raspberry Pi I imagine) won't know how to reach 10.8.0.2 and traffic will just get discarded (or forwarded to the router's own default gateway which is like your ISP who then will discard it). When you connect to the DVR, is there NAT involved? The question to answer ultimately is this: when you connect to the DVR, which IP address does the DVR see the attempt come from? If the DVR sees your IP as 10.8.0.2 then the DVR will send return traffic to its default gateway as the IP isn't on its own subnet. The issue is now DVR itself from what I can tell. So we're at least past Raspberry and OpenVPN now. I can't say if that would block ARP requests as well. If the DVR is accidentally configured for a smaller subnet then it can explain the problem.Īn earlier post by Alex did suggest something about trusted devices and such. 107 are still in the same /24 network even if one is configured for a larger /8 (DVR doesn't actually know that Raspberry is configured for /8). Please double-check the DVR because even if DVR is in /24 and Raspberry is in /8, it should have worked because. It may have something to do with subnet issues. It doesn't (shouldn't) get blocked by firewalls. Your DVR isn't even responding to an ARP request which is not normal behaviour for a network device even if a firewall is involved to block TCP and UDP traffic. That causes the host unreachable message. It does this by sending an ARP request you can see in the output:ĪRP, request who-has 10.20.40.135 tell 10.20.40.107īut there is no response from the DVR.
#Lorex dvr client not working mac#
When your Raspberry tries to contact the DVR it first has to find out what its MAC address is. You're getting somewhere with those tests, though.
#Lorex dvr client not working update#
Update your Raspberry network config accordingly. If router and DVR have a subnet of 255.255.255.0 that is /24 in CIDR equivalent.