VPN Logs
-
I'm really new to pfSense and trying to learn…......
I was looking through the logs and need some help deciphering this. I am the only "authorized user" on the VPN to my home network and I was not using it at the time this took place. Looks like someone hit the front door to my VPN. Is there anything in here that I should be concerned about?
Jan 18 14:21:43 openvpn 59111 Initialization Sequence Completed
Jan 18 14:21:43 openvpn 59111 UDPv6 link remote: [AF_UNSPEC]
Jan 18 14:21:43 openvpn 59111 UDPv6 link local (bound): [AF_INET6][undef]:60134
Jan 18 14:21:43 openvpn 59111 setsockopt(IPV6_V6ONLY=0)
Jan 18 14:21:43 openvpn 59111 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 18 14:21:43 openvpn 59111 /usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:43 openvpn 59111 /sbin/ifconfig ovpns1 192.168.255.1 192.168.255.2 mtu 1500 netmask 255.255.255.0 up
Jan 18 14:21:43 openvpn 59111 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jan 18 14:21:43 openvpn 59111 TUN/TAP device /dev/tun1 opened
Jan 18 14:21:43 openvpn 59111 TUN/TAP device ovpns1 exists previously, keep at program end
Jan 18 14:21:43 openvpn 59111 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Jan 18 14:21:43 openvpn 58851 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10
Jan 18 14:21:43 openvpn 58851 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 8 2017
Jan 18 14:21:42 openvpn 32411 SIGTERM[hard,] received, process exiting
Jan 18 14:21:42 openvpn 32411 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:42 openvpn 32411 event_wait : Interrupted system call (code=4)
Jan 18 14:21:42 openvpn 32411 Initialization Sequence Completed
Jan 18 14:21:42 openvpn 32411 UDPv6 link remote: [AF_UNSPEC]
Jan 18 14:21:42 openvpn 32411 UDPv6 link local (bound): [AF_INET6][undef]:60134
Jan 18 14:21:42 openvpn 32411 setsockopt(IPV6_V6ONLY=0)
Jan 18 14:21:42 openvpn 32411 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 18 14:21:42 openvpn 32411 /usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:41 openvpn 32411 /sbin/ifconfig ovpns1 192.168.255.1 192.168.255.2 mtu 1500 netmask 255.255.255.0 up
Jan 18 14:21:41 openvpn 32411 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jan 18 14:21:41 openvpn 32411 TUN/TAP device /dev/tun1 opened
Jan 18 14:21:41 openvpn 32411 TUN/TAP device ovpns1 exists previously, keep at program end
Jan 18 14:21:41 openvpn 32411 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Jan 18 14:21:41 openvpn 32163 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10
Jan 18 14:21:41 openvpn 32163 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 8 2017
Jan 18 14:21:41 openvpn 55027 SIGTERM[hard,] received, process exiting
Jan 18 14:21:41 openvpn 55027 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:41 openvpn 55027 event_wait : Interrupted system call (code=4)
Jan 18 14:21:36 openvpn 55027 Initialization Sequence Completed
Jan 18 14:21:36 openvpn 55027 UDPv6 link remote: [AF_UNSPEC]
Jan 18 14:21:36 openvpn 55027 UDPv6 link local (bound): [AF_INET6][undef]:60134
Jan 18 14:21:36 openvpn 55027 setsockopt(IPV6_V6ONLY=0)
Jan 18 14:21:36 openvpn 55027 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 18 14:21:36 openvpn 55027 /usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:36 openvpn 55027 /sbin/ifconfig ovpns1 192.168.255.1 192.168.255.2 mtu 1500 netmask 255.255.255.0 up
Jan 18 14:21:36 openvpn 55027 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jan 18 14:21:36 openvpn 55027 TUN/TAP device /dev/tun1 opened
Jan 18 14:21:36 openvpn 55027 TUN/TAP device ovpns1 exists previously, keep at program end
Jan 18 14:21:36 openvpn 55027 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Jan 18 14:21:36 openvpn 54917 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10
Jan 18 14:21:36 openvpn 54917 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 8 2017
Jan 18 14:21:36 openvpn 97840 SIGTERM[hard,] received, process exiting
Jan 18 14:21:36 openvpn 97840 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:21:36 openvpn 97840 event_wait : Interrupted system call (code=4)
Jan 18 14:03:04 openvpn 97840 Initialization Sequence Completed
Jan 18 14:03:04 openvpn 97840 UDPv6 link remote: [AF_UNSPEC]
Jan 18 14:03:04 openvpn 97840 UDPv6 link local (bound): [AF_INET6][undef]:60134
Jan 18 14:03:04 openvpn 97840 setsockopt(IPV6_V6ONLY=0)
Jan 18 14:03:04 openvpn 97840 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 18 14:03:04 openvpn 97840 /usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:03:04 openvpn 97840 /sbin/ifconfig ovpns1 192.168.255.1 192.168.255.2 mtu 1500 netmask 255.255.255.0 up
Jan 18 14:03:04 openvpn 97840 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jan 18 14:03:04 openvpn 97840 TUN/TAP device /dev/tun1 opened
Jan 18 14:03:04 openvpn 97840 TUN/TAP device ovpns1 exists previously, keep at program end
Jan 18 14:03:04 openvpn 97840 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Jan 18 14:03:04 openvpn 97840 GDG: problem writing to routing socket
Jan 18 14:03:04 openvpn 97762 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10
Jan 18 14:03:04 openvpn 97762 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 8 2017
Jan 18 14:03:04 openvpn 19297 SIGTERM[hard,] received, process exiting
Jan 18 14:03:04 openvpn 19297 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1621 192.168.255.1 255.255.255.0 init
Jan 18 14:03:04 openvpn 19297 event_wait : Interrupted system call (code=4) -
I posted this 24 hours ago and haven't received any responses…...
Am I:
1. Not asking the right question / in the wrong forum?
2. So simple, the community thinks I should already know the answer?
3. TL,DR?
4. No one legitimately knows if the log shows something of concern?In case it is related to #1 above, specifically I am concerned that an unauthorized person was able to successfully connect to my OpenVPN server on my pfSense box. I'm using certificate based (4096 bit key) authentication so if they were able to connect then I must have made a fatal mistake somewhere in my configuration. Any thoughts or ideas?
Regards.
-
Not every topic gets a response, best to be patient about it. Help on our forums is on volunteer basis. You did ask at the right place.
That log doesn't show any connections, just VPN restarting a few times. If you're concerned about security I suggest the following:
- use higher, non-standard ports for VPN
- set up IDS on public facing interfaces
- have pfBlockerNG block access to opened port from countries you don't live it (or just allow your country).
-
Yeah I don't see any connections or attempts even..
I saw this thread and moved on because of 5..
- Poster doesn't seem to even know what connection attempt is.
<grin>Something hitting your port would look something like this.
Jan 19 11:39:18 openvpn 17272 196.52.43.117:6666 Connection reset, restarting
Jan 19 11:39:18 openvpn 17272 196.52.43.117:6666 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 – please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart…]
Jan 19 11:39:16 openvpn 17272 TCP connection established with [AF_INET]196.52.43.117:6666I would post up something hitting my UDP instance - but don't see anything going back to Jan 10th.. Would have to look through the syslog for something. But see hits to my 443 all the time… I run an instance on tcp 443 because almost guaranteed if there is internet at the place that 443 will be open tcp. But it does generate some noise in your logs. While tcp not the preferred connection method - nice because makes it easy to bounce off a http proxy when your behind one like I am at work ;)</grin>