Otdfbt

Jesus' words on the Jews

Rounding a number extracted by jq to limit the decimal points

What are the components of a legend (in the sense of a tale, not a figure legend)?

CPLD based Pierce oscillator

Tikz draw contour without some edges, and fill

What are the holes in files created with fallocate?

Unexpected Netflix account registered to my Gmail address - any way it could be a hack attempt?

If current results hold, Man City would win PL title

How can a layman easily get the consensus view of what academia *thinks* about a subject?

How can dragons propel their breath attacks to a long distance

Entering the UK as a British citizen who is a Canadian permanent resident

correct spelling of "carruffel" (fuzz, hustle, all that jazz)

How exactly does artificial gravity work?

What is the largest number of identical satellites launched together?

Why did the metro bus stop at each railway crossing, despite no warning indicating a train was coming?

When a land becomes a creature, is it untapped?

What information do scammers need to withdraw money from an account?

Is there ever any indication in the MCU as to how Spider-Man got his powers?

Area under the curve - Integrals (Antiderivatives)

Anabelian geometry ~ higher category theory

Jumping frame contents with beamer and pgfplots

How can I answer high-school writing prompts without sounding weird and fake?

Is the expression "To think you would stoop so low" often misused?

Is there anything special about -1 (0xFFFFFFFF) regarding ADC?

Time Clock IPsec and Layer3 Routing

Unable to set up a static host route - “SIOCADDRT: No such process”How can I prevent OpenVPN from clobbering local route?RV082 Gateway-Gateway VPN Won't ConnectTraffic routing with unreliable connectionsOpenVPN not routing on DD-WRTExpose a machine on the far side of a VPNRouting between pfSense Subnets and IPSec VPNCan I set up a VoIP phone to connect to it's gateway over VPN with different subnets?OpenVPN setup help - routing or bridging?Routing between OpenVPN subnets in tunnel modes

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;

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:

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.

routing ipsec ip-routing

share|improve this question

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

• 
  
  
  

  
  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 2 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 3 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 3 at 15:12
  

  
  
  
  

add a comment | 

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:

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.

routing ipsec ip-routing

share|improve this question

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

• 
  
  
  

  
  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 2 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 3 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 3 at 15:12
  

  
  
  
  

add a comment | 

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:

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.

routing ipsec ip-routing

share|improve this question

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

share|improve this question

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

share|improve this question

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

edited May 3 at 3:21

Appleoddity

2,2041317

edited May 3 at 3:21

Appleoddity

2,2041317

asked May 2 at 18:49

BigMikeLBigMikeL

185

asked May 2 at 18:49

BigMikeLBigMikeL

185

1 Answer
1

active

oldest

votes

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.

share|improve this answer

answered May 3 at 15:40

BigMikeLBigMikeL

185

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 3 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 3 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 3 at 15:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  It's certainly convenient that I could crack the password but sad at the same time.
  
  – BigMikeL
  May 3 at 15:53
  

  
  
  
  

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f965630%2ftime-clock-ipsec-and-layer3-routing%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

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.

share|improve this answer

answered May 3 at 15:40

BigMikeLBigMikeL

185

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 3 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 3 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 3 at 15:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  It's certainly convenient that I could crack the password but sad at the same time.
  
  – BigMikeL
  May 3 at 15:53
  

  
  
  
  

add a comment | 

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.

share|improve this answer

answered May 3 at 15:40

BigMikeLBigMikeL

185

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 3 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 3 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 3 at 15:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  It's certainly convenient that I could crack the password but sad at the same time.
  
  – BigMikeL
  May 3 at 15:53
  

  
  
  
  

add a comment | 

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.

share|improve this answer

answered May 3 at 15:40

BigMikeLBigMikeL

185

share|improve this answer

answered May 3 at 15:40

BigMikeLBigMikeL

185

answered May 3 at 15:40

BigMikeLBigMikeL

185

answered May 3 at 15:40

BigMikeLBigMikeL

185