Help Center Logpoint Docs Idea Portal Logpoint.com
  • EN
Solved

Logpoint collector behind NAT

  • 25 November 2022
  • 7 replies
  • 99 views
S
Userlevel 2

Hi Community,

 

We have a distributed collector in a remote location. We have established a Site-to-site VPN between locations. The scenario is that the IP Address of the collector is in NAT and mapped to a different IP than that of the actual host IP.

 

For E.g the system IP of collector is 172.29.20.80 and the IP of the collector as seen by the Remote Logpoint is 172.22.2.2. 

 

We have made the necessary configuration and ensured the Collector is visible in the logpoint. However, the IP as recorded by Logpoint is the actual system IP (Not the IP Logpoint should recognize it as). The issue is the status is Inactive stage. 

 

Is this due to the difference in host IP and NAT address?

 

 

icon

Best answer by Srijan Kafle 28 November 2022, 18:09

View original

7 replies

P
Rank

Hi Srijan,

There should be no problem in using the LPC across NAT or a site-to-site VPN - however, in some cases we have seen that the path MTU discovery inside VPN’s can fail (fx if ICMP communication is not allowed) - which can be critical as the MTU is often smaller inside the site-to-site VPN. Therefore we have added the option to specify the MTU in the opendoor dialog (on the LP which the LPC connects to). Depending on the MTU on your site-to-site VPN this will need to be reduced.
You can determine the MTU using ping through the tunnel - from the LPC towards the LP or the other way:
# ping -M do -s <MTU-28>  <IP-of-other-end>

here’s what it would look like if you are above MTU:

# ping -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1438

this reveals the MTU to be 1438 in this case - we can test this by subtracting the size of the IP header (28 chars) from the 1438 and trying again:

# ping -M do -s 1410 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1410(1438) bytes of data.
1418 bytes from 10.20.30.40: icmp_seq=1 ttl=61 time=8.06 ms

which appears to be going fine without truncation.

So in this case the correct MTU to specify inside the opendoor VPN will be 1410 bytes.

If this doesn’t help - we may need to take a closer look at the system, and - in that case - recommend that you raise a support ticket.

Best regards
Peter Melsen

S
Userlevel 2

Sure Peter, I will try this and let you know.

S
Userlevel 2

Hi Peter,

 

I have tried the provided solution, the MTU to be 1371 and applied it to the Open door configuration in the SIEM. When checked in the Collector, the status is connected as shown in the screenshot 

 

However, when checked in the SIEM under the distributed logpoint section, we see that the status is inactive:

 

Brian Hansen
Rank
Userlevel 3
Badge +3

Hi Srijan.

Sounds like help from Support is the best way forward on this specific challenge.

Will you open a ticket - and then please insert the link from this Community post.

 

Thanks,

Brian Hansen, Logpoint

S
Userlevel 2

Hi Brian,

 

I have raised a ticket. Posted here so that if someone has already explored similar scenario before. Will post here once I get resolutions 

S
Userlevel 2

To any one who stumbles upon this issue, we missed to activate the collector. The button is at the left most side of the action tab.

 

The documentation in the site didn’t mention it , and we too failed to identify the silly mistake. The collector is now working as expected.

 

Thank you Brian for the effort.

Brian Hansen
Rank
Userlevel 3
Badge +3

Thanks for your feedback. I will get this to our Team working on documentation.

Brian Hansen, Logpoint 

Reply


Terms & ConditionsCookie settings