0

Thank you for your time, I incorrectly asked this in Network Engineering so I'm moving it here.

I have a Remote Office and a Main Office linked via IPSec with the Main Office being 192.168.16.0/24 and the Remote being 192.168.1.0/24. I can ping all devices in the Main Office from the Remote Office and vice versa.

Below is a simplification of what our network looks like:

Simplistic Network Diagram

We are using TP-Link ER-6020 v2 routers with the latest firmware on both networks. Our ISP happens to use wireless connections as we are quite rural, though I don't think that really matters.

The Time Clock Server software is running on Windows Server 2012 (192.168.16.107) along with a few other applications. The Server Software can connect/discover Time Clocks on the 192.168.16.0/24 network with no problem but it cannot connect to the (192.168.1.105) Time Clock on the Remote Network even though it can be pinged. The Time Clocks use UDP 30303 and 30304 for communications. I have changed the Time Clock to eliminate a failing unit being the problem.

The Time Clock vendor has suggested that I set up some "Layer3 Management" rules or create some "Custom Routing Tables" but that seems to beyond my level of knowledge. Researching those has me thinking in circles with no end.

Please offer either a path towards solution or a Primer that might help me understand what the vendor is getting at so I can figure this out.

Appleoddity
  • 3,290
  • 2
  • 10
  • 27
BigMikeL
  • 121
  • 1
  • 6
  • 1
    If you're happy to install Wireshark on the server, you can eliminate the router as a cause by seeing if the UDP traffic is reaching it. Fire it up and use a capture filter of `udp and (port 30303 or port 30304)`. If you see UDP arriving, then the server or the application itself is dropping it; if not then it's something upstream, perhaps firewall rules on one of your routers. – SmallClanger May 02 '19 at 19:10
  • I tried Wireshark and it's interesting to say the least. Now, I'm not smart on this bu here is my best try at describing what I am seeing. It seems the program sends out a 'Who's There' broadcast on UDP 30303 but only the clocks on 192.168.16.0/24 seem to respond. Would an IPsec connection normally pass on such broadcast queries to the 192.168.1.0/24 network? – BigMikeL May 03 '19 at 12:33
  • 1
    Unless you're fully bridging the two networks (highly unlikely from your description) the broadcast discovery will never reach the clocks on the other side of your tunnel. Two ways to resolve this: Find a way to replay the broadcast on the far side of the tunnel (can be tricky) or configure the server application to use unicast or pre-populate it with the clock addresses (much easier but only if the app supports it) – SmallClanger May 03 '19 at 15:12

1 Answers1

1

SmallClanger, you inspired me to look at it from a different angle. I hacked the database password that records discovered clocks (thanks to Microsoft Access poor security) and hand keyed the clock details, bypassing it's discovery process and after driving out to the remote site, it seems to have worked swimmingly. The software on the server still has a red alert dot showing that the clock is not connected but the communication is there. So the only failure was the discovery/detection of the clock via UDP and I can live with a red dot.

BigMikeL
  • 121
  • 1
  • 6
  • Seems to be an unwritten rule that software supporting physical security and time-clock devices is god-awful. Sometimes you can use that to your advantage :) – SmallClanger May 03 '19 at 15:47
  • `I hacked the database password that records discovered clocks (thanks to Microsoft Access poor security)` - So you hacked the time clock vendors database with MS Access? How is this a Microsoft shortcoming? – joeqwerty May 03 '19 at 15:48
  • It took the program about 2 seconds to discover the password of the .mdb file. I know Microsoft has improved it now but it's something that should have been more robust towards the beginning of the life of Access. – BigMikeL May 03 '19 at 15:50
  • It's certainly convenient that I could crack the password but sad at the same time. – BigMikeL May 03 '19 at 15:53