Verbose / debug log

Product Discussion Feature Requests
1

Hi,

Sometimes it is difficult to find out what is causing a issue with a IPsec VPN or when a 4G connection fails.
Would be nice if there was an option to enable verbose/debug logs for the “advanced” users and show this in a different view so the event log doesn’t get flooded.

Kind regards,

Dylan van Elst

2 Likes
2

Hi,

I’m with Dylan. An Advanced Logfile (even when it’s only for Partners) could help a lot.

Questions like “why is my SIM not logging into the network” could be answered with that.

so +1 for advanced logging

Dennis

3 Likes
3

Yes please. It is important in a handful of scenarios for troubleshooting ‘why is it not connecting’ type problems. Both times I’ve had to bother PepLink support, it’s been to debug VPNs not forming.

In Aug 2018, it was because I had got muddled with SIMs and put a ‘consumer grade’ SIM in one of the field MAX BRI1’s. The telco was intercepting some HTTPS calls made by the PepVPN ‘spoke’ router and putting an HTML error message in the response, causing the VPN not to form. In that case, PepLink support were able to access the system-level logs on the spoke/initiating peer (so they’re there!) after I enabled ‘Remote Assistance’.

At the moment, I am also bothering PepLink support because a Balance is the responder in an IPsec VPN. It has been a frustrating time. The ‘IPsec VPN Event Log’ suppresses a lot of duplicate messages, so it is very hard to even determine that a packet from the peer was even received! The ‘connection refused’ message is brief, and doesn’t say on what basis the router refused: did Phase 1 fail? Phase 2? Because no agreement could be found on proposed ciphers and groups? Or because the passphrase was wrong? If I didn’t see the packet in the log, should I double-check the firewall?

It would be nice to assert to the router: “I am expecting a peer to initiate a tunnel with IPsec profile X from any of these networks, but if you process such a packet and the outcome is that the Security Association is torn down or stays down, please give me a log saying what you found objectionable. If the proposal was the same as the previous one, and there has not been a configuration change to the way you would evaluate it, then don’t repeat everything … just add to a list saying ‘ditto Y secs later (hh:mm:ss)’. But if the proposal from the peer changes, or the way it is interpreted changes, and it STILL doesn’t work, then log the info again.” This targets very particular logs, and keeps the rate down, showing what has changed without any duplication, while still providing confidence the router isn’t just sitting on packets without telling anyone…

All of this could happen in an Event Log tab for that ‘Expectation’.

Messages would be like:

  • “received an IKE proposal from peer x.x.x.x”,
  • “could not agree on proposed phaseX ciphers/pfs-group: [list offered ciphers/groups]”,
  • “localID/remoteID of ‘X’ not recognised”
  • “psk didnt match!”
  • “could not parse packet from peer as expected packet X in the IKEvX mode Y exchange”,
  • “hey, packets from expected networks to router IPsec ports are getting stuck in firewall rule Y”
  • “hey, nothing from your guy, but I saw a string of bytes which could be an IPv4 address in one of the network you’re expecting packets from … just not in the ‘src’ field - have you considered what NAT is doing on the other end?”

For any log, we could download a pcap file containing the packets identified as belonging to the conversation/expectation.

That would sort of more be the ‘PepLink way’ - to offer a troubleshooting tool for particular scenarios, rather than raw logs.

regards,
David.

4

Hi,

in the moment I wished we had an Advanced Logfile…
I’ve installed a new SIM Card and it wont connect - so it is a BlackBox in the moment…

Any news to that?

Thanks
Dennis

5

+1

staying in front of connecting… is very frustating