Troubleshooting IP Access

The most effective way to troubleshoot IP Access is to view the logs.

View the Docker logs

run the following command on Lighthouse, either as root or with sudo (for non-root admins):

sudo docker logs -t central-sdi

The logs for the central-sdi Docker container, which controls client IP Access display.

2022-10-03T10:03:19.051579136Z INFO:root:[NetOps-SDI node="nodes-36" username="maverick"] VPN client authenticated
2022-10-03T10:03:19.094313762Z 2.29.37.12:65437 TLS: Username/Password authentication succeeded for username 'maverick123:OM1208-UK2'
2022-10-03T10:03:19.422971278Z 2.29.37.12:65437 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-10-03T10:03:19.422999989Z 2.29.37.12:65437 [LH5-UK3-22] Peer Connection Initiated with [AF_INET]2.29.37.12:65437
2022-10-03T10:03:22.000300953Z INFO:root:[NetOps-SDI node="nodes-36" username="maverick123"] VPN client connected with IP 172.31.0.8 netmask 255.255.0.0
2022-10-03T10:03:22.084275387Z LH5-UK3-22/2.29.37.12:65437 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_3aa5d19c3ea09b3bbac56f6bacf7b6e.tmp
2022-10-03T10:03:22.084324213Z LH5-UK3-22/2.29.37.12:65437 Data Channel: using negotiated cipher 'AES-256-GCM'
2022-10-03T10:03:22.084332293Z LH5-UK3-22/2.29.37.12:65437 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-10-03T10:03:22.084337215Z LH5-UK3-22/2.29.37.12:65437 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-10-03T10:03:22.084342034Z LH5-UK3-22/2.29.37.12:65437 SENT CONTROL [LH5-UK3-22]: 'PUSH_REPLY,ping 10,ping-restart 120,route 192.168.2.0 255.255.255.0 172.31.0.1 1,ifconfig 172.31.0.8 255.255.0.0,peer-id 0,cipher AES-256-GCM' (status=1)
2022-10-03T10:03:22.084950386Z LH5-UK3-22/2.29.37.12:65437 PUSH: Received control message: 'PUSH_REQUEST'
2022-10-03T10:03:22.085204467Z LH5-UK3-22/2.29.37.12:65437 PUSH: Received control message: 'PUSH_REQUEST'
2022-10-03T10:03:22.085220316Z LH5-UK3-22/2.29.37.12:65437 PUSH: Received control message: 'PUSH_REQUEST'
2022-10-03T10:03:22.432350278Z LH5-UK3-22/2.29.37.12:65437 PUSH: Received control message: 'PUSH_REQUEST'
2022-10-03T10:03:23.120616769Z INFO:root:[NetOps-SDI node="nodes-36" username="maverick"] VPN client identified by MAC c6:87:ca:4a:3b:2c

Note the PUSH_REPLY line above shows that the IP Access client has been pushed the route to the network 192.168.2.0/24 which in this case is the interface on this Node in the firewall zone that the user was mapped into. (Unfortunately, the firewall zones are not listed in this log output). If there are errors with authentication, then they will show up here.

Using the Routing Table

When troubleshooting IP Access it is useful to look at the routing table on the target Node to make sure that routes to the target networks are installed. If the interface is down, for example, then the route is not present and will not be pushed to the client.

The following commands can be used to display the routing table on the target OM Series Node:

route

ip route

The Routing table displays:

root@OM1208-UK2:~# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

default _gateway 0.0.0.0 UG 110000001 0 0 net1

5.5.5.0 0.0.0.0 255.255.255.0 U 0 0 0 sw0p8

172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0

172.31.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ipa-br0

192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 net2

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 net1

192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 sw0p2

192.168.128.0 0.0.0.0 255.255.224.0 U 0 0 0 tun0

root@OM1208-UK2:~#

root@OM1208-UK2:~# ip route

default via 192.168.1.1 dev net1 proto static metric 110000001

5.5.5.0/24 dev sw0p8 proto kernel scope link src 5.5.5.5

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

172.31.0.0/16 dev ipa-br0 proto kernel scope link src 172.31.0.1

192.168.0.0/24 dev net2 proto kernel scope link src 192.168.0.48

192.168.1.0/24 dev net1 proto kernel scope link src 192.168.1.48

192.168.2.0/24 dev sw0p2 proto kernel scope link src 192.168.2.8

192.168.128.0/19 dev tun0 proto kernel scope link src 192.168.128.6

root@OM1208-UK2:~#

The ip route command output is useful as it shows the interface IP address of the OM, which should be reachable via IP Access as long as that interface is up.

Other standard network troubleshooting techniques can be used from the Node, for example testing the ability to ping a target device, or using curl if it has an http or https interface.

Examples

ping 192.168.2.4

curl -k https://192.168.2.4/