Sstp,ppp,debug entries in the log, but, I don't see any connection to which it would be related?

RouterOS
1

I have a pair of pegged-up SSTP VPNs. (Three MikroTik devices, one in each of three places, two of them always initiating an SSTP VPN connection to the third). They work fine. That is, they stay connected, data flows reliably, with rare exceptions of temporary network failures as one would expect on the Internet which are promptly followed-up by a re-connect and the connections then again remaining reliably up for days/weeks at a time.

/ppp/active shows, for example, at the moment, that both connections have been up since I restarted the SSTP server MikroTik device 20 minutes ago.

Yet, in the system log, between (the time of the system restart and the successful (and still connected) SSTP VPN session initiations by the other two MikroTik routers) and now, I also see this:

2026-02-27 09:11:45 sstp,ppp,debug : CCP close
2026-02-27 09:11:45 sstp,ppp,debug : BCP close
2026-02-27 09:11:45 sstp,ppp,debug : IPCP close
2026-02-27 09:11:45 sstp,ppp,debug : IPV6CP close
2026-02-27 09:11:45 sstp,ppp,debug : MPLSCP close
2026-02-27 09:11:45 sstp,ppp,debug : LCP lowerdown
2026-02-27 09:11:45 sstp,ppp,debug : LCP down event in initial state

And, over time, I see that set of log entries occasionally.

I assumed that this might be port scanning hitting my MikroTik’s SSTP VPN server and failing to login, but I ran a packet capture (anything at all hitting the SSTP VPN server MikroTik on the SSTP VPN service port 8443) during a time when a set of those log entries appeared, and no SSTP port packets had arrived at the MikroTik other than for the two stably-up connections from my other two MikroTik routers.

The MikroTik acting as the SSTP VPN server is a new hEX refresh running RouterOS 7.20.8 (recently having replaced an RB951ui-2HnD running ROSv6), and the two SSTP VPN client MikroTiks are RB951ui-2HnD. I do not recall whether I had seen these entries in the recently-replaced ROSv6 MikroTik’s logs; I think so, but I’m not sure.

This is the SSTP VPN server configuration:

[admin@MikroTik4.felines.org] /interface/sstp-server/server> print
enabled: yes
port: 8443
max-mtu: 1500
max-mru: 1500
mrru: disabled
keepalive-timeout: 60
default-profile: default
authentication: mschap2
certificate: mikrotik4_felines_org-iss-2026-02-18.crt_0
verify-client-certificate: no
pfs: yes
tls-version: only-1.2
ciphers: aes256-sha
aes256-gcm-sha384

Am I correct to assume that, on stably-up SSTP VPN connections, I should not see sstp,ppp,debug (various negotiation) close entries? (That is, I should see those entries only if the SSTP VPN connections failed).

I searched for a way to log only SSTP entries related to !my_SSTP_clients’_IP_addresses but didn’t find that, nor did I find a way to log the IP address related to an SSTP entry that ends up in the system log. Is there a way to get the system log to include the remote IP address of anything that causes an SSTP entry to appear in the log?

What could explain these seemingly-isolated SSTP (failed) negotiation (or connecting closing) log entries?

thank you,

2

Ah. My /system/logging entry for sstp or ppp was sstp,ppp (which I just learned means sstp AND ppp), so I disabled that entry and added two separated entries, one each for sstp and for ppp.

Log entries since then now also include sstp,packet which tells me a little more about what’s going on in the stably-open connections, and a bit of detail when I cause the connection to drop and re-establish, but does not shed any more light on these occasional batches of apparently-unrelated close/down packets which caused me to post the question.

A bit more detail:

On MikroTik3 (one of my two SSTP VPN clients), the SSTP client interface detail:

/interface print detail
...
8 R ;;; Pegged-up VPN route to Barcelona network
name="sstp-out1" type="sstp-out" mtu=1500 actual-mtu=1500 last-link-down-time=mar/01/2026 05:40:20 last-link-up-time=mar/01/2026 05:40:21 link-downs=2

n.b. The last-link times are from After a test I just did to generate detailed log entries from dropping and re-establishing the connection. When I began the testing this morning, that client link had been up for over a day.

Before I dropped and re-established the connection, after I had fixed the /system logging configuration, here are the log entries for sstp OR ppp, on MikroTik4 (the SSTP VPN server):

2026-03-01 11:10:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:10:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:10:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:10:21 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:11:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:11:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:11:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:11:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:12:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:12:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:12:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:12:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:13:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:13:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:13:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:13:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:14:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:14:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:14:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:14:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:15:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:15:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:15:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:15:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:16:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:16:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:16:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:16:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:17:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:17:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:17:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:17:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:18:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:18:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:18:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:18:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:19:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:19:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:19:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:19:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:20:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:20:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:20:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:20:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:21:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:21:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:21:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:21:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:22:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:22:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:22:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:22:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:23:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:23:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:23:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:23:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response
2026-03-01 11:23:50 sstp,ppp,debug : CCP close
2026-03-01 11:23:50 sstp,ppp,debug : BCP close
2026-03-01 11:23:50 sstp,ppp,debug : IPCP close
2026-03-01 11:23:50 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:50 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:50 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:50 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:50 sstp,ppp,debug : CCP close
2026-03-01 11:23:50 sstp,ppp,debug : BCP close
2026-03-01 11:23:50 sstp,ppp,debug : IPCP close
2026-03-01 11:23:50 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:50 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:50 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:50 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:51 sstp,ppp,debug : CCP close
2026-03-01 11:23:51 sstp,ppp,debug : BCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:51 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:51 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:51 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:51 sstp,ppp,debug : CCP close
2026-03-01 11:23:51 sstp,ppp,debug : BCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:51 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:51 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:51 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:51 sstp,ppp,debug : CCP close
2026-03-01 11:23:51 sstp,ppp,debug : BCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:51 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:51 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:51 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:51 sstp,ppp,debug : CCP close
2026-03-01 11:23:51 sstp,ppp,debug : BCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:51 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:51 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:51 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:51 sstp,ppp,debug : CCP close
2026-03-01 11:23:51 sstp,ppp,debug : BCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPCP close
2026-03-01 11:23:51 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:51 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:51 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:51 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:52 sstp,ppp,debug : CCP close
2026-03-01 11:23:52 sstp,ppp,debug : BCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:52 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:52 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:52 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:52 sstp,ppp,debug : CCP close
2026-03-01 11:23:52 sstp,ppp,debug : BCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:52 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:52 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:52 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:52 sstp,ppp,debug : CCP close
2026-03-01 11:23:52 sstp,ppp,debug : BCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:52 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:52 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:52 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:23:52 sstp,ppp,debug : CCP close
2026-03-01 11:23:52 sstp,ppp,debug : BCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPCP close
2026-03-01 11:23:52 sstp,ppp,debug : IPV6CP close
2026-03-01 11:23:52 sstp,ppp,debug : MPLSCP close
2026-03-01 11:23:52 sstp,ppp,debug : LCP lowerdown
2026-03-01 11:23:52 sstp,ppp,debug : LCP down event in initial state
2026-03-01 11:24:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:24:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:24:20 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:24:20 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response

We see the expected keep-alive packets every 60 seconds. (I’ve cleaned the logs before posting here; the keep-alive packets for the other SSTP VPN client, MikroTik2, also appear, identically).

And, eventually, the curious set of down/close packets do appear, right near the end of the log excerpt above; (I stopped the /log print follow as soon as those packets had appeared, and, thereafter, a next set of keep-alive packets had appeared, to make sure that the close/down packets were NOT indicative of this SSTP connection failing. During that whole time, I also had an SSH session open, through this SSTP VPN, to the MikroTik3 SSTP client, and the connection did in fact stay up the whole time).

I then restarted the MikroTik3 router (SSTP client), to generate system logs on MikroTik4 (SSTP server) which happen if the connection actually goes down and comes back up:

2026-03-01 11:45:43 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd LCP TermReq id=0x5
2026-03-01 11:45:43 sstp,ppp,debug,packet system is going to shutdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: LCP closed
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: CCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: BCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: BCP down event in starting state
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP closed
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPV6CP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPV6CP down event in starting state
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP closed
2026-03-01 11:45:43 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent LCP TermAck id=0x5
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: LCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: CCP close
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: BCP close
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP close
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: IPV6CP close
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP close
2026-03-01 11:45:43 sstp,ppp,info <sstp-mikrotik3.local>: terminating...
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: LCP lowerdown
2026-03-01 11:45:43 sstp,ppp,debug <sstp-mikrotik3.local>: LCP down event in starting state
2026-03-01 11:45:43 sstp,ppp,info,account mikrotik3.local logged out, 322 77208 49040 819 924 from 73.80.148.50
2026-03-01 11:45:43 sstp,ppp,info <sstp-mikrotik3.local>: disconnected

And, a minute and a half or so later, after MikroTik3 had rebooted, and its SSTP VPN client automatically began re-connecting to the SSTP VPN server on MikroTik4:

2026-03-01 11:46:23 sstp,packet recv
2026-03-01 11:46:23 sstp,packet SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1\r
2026-03-01 11:46:23 sstp,packet Content-Length: 18446744073709551615\r
2026-03-01 11:46:23 sstp,packet Host: 0.0.0.0\r
2026-03-01 11:46:23 sstp,packet \r
2026-03-01 11:46:23 sstp,packet
2026-03-01 11:46:23 sstp,packet sending
2026-03-01 11:46:23 sstp,packet HTTP/1.1 200\r
2026-03-01 11:46:23 sstp,packet Content-Length: 18446744073709551615\r
2026-03-01 11:46:23 sstp,packet Server: MikroTik-SSTP\r
2026-03-01 11:46:23 sstp,packet Date: Sun, 01 Mar 2026 10:46:23 GMT\r
2026-03-01 11:46:23 sstp,packet \r
2026-03-01 11:46:23 sstp,packet
2026-03-01 11:46:23 sstp,packet recv control packet type: connect request
2026-03-01 11:46:23 sstp,packet sent control packet type: connect ack
2026-03-01 11:46:23 sstp,ppp,debug : LCP lowerup
2026-03-01 11:46:23 sstp,ppp,debug : LCP open
2026-03-01 11:46:23 sstp,ppp,debug,packet : sent LCP ConfReq id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet <mru 1500>
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,debug,packet : rcvd LCP ConfReq id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet : sent LCP ConfAck id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet : rcvd LCP ConfAck id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet <mru 1500>
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,debug : LCP opened
2026-03-01 11:46:23 sstp,ppp,debug,packet : sent CHAP Challenge id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,debug,packet : rcvd CHAP Response id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,debug,packet
2026-03-01 11:46:23 sstp,ppp,info,account mikrotik3.local logged in, 192.168.255.55 from 73.80.148.50
2026-03-01 11:46:23 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent CHAP Success id=0x1
2026-03-01 11:46:23 sstp,ppp,info <sstp-mikrotik3.local>: authenticated
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP lowerup
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP open
2026-03-01 11:46:23 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfReq id=0x1
2026-03-01 11:46:23 sstp,ppp,debug,packet <addr 192.168.255.54>
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: IPV6CP open
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP lowerup
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP open
2026-03-01 11:46:23 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent MPLSCP ConfReq id=0x1
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: BCP open
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: CCP lowerup
2026-03-01 11:46:23 sstp,ppp,debug <sstp-mikrotik3.local>: CCP open
2026-03-01 11:46:24 sstp,packet <sstp-mikrotik3.local> recv control packet type: connected
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x1
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfNak id=0x1
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.55>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd MPLSCP ConfReq id=0x1
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent MPLSCP ConfAck id=0x1
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfAck id=0x1
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.54>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd MPLSCP ConfAck id=0x1
2026-03-01 11:46:24 sstp,ppp,debug <sstp-mikrotik3.local>: MPLSCP opened
2026-03-01 11:46:24 sstp,ppp,info <sstp-mikrotik3.local>: connected
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x2
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfNak id=0x2
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.55>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x3
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfNak id=0x3
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.55>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x4
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfNak id=0x4
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.55>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x5
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfNak id=0x5
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.55>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x6
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfRej id=0x6
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.253.3>
2026-03-01 11:46:24 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP timer
2026-03-01 11:46:24 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfReq id=0x2
2026-03-01 11:46:24 sstp,ppp,debug,packet <addr 192.168.255.54>
2026-03-01 11:46:25 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfReq id=0x7
2026-03-01 11:46:25 sstp,ppp,debug,packet <sstp-mikrotik3.local>: sent IPCP ConfAck id=0x7
2026-03-01 11:46:25 sstp,ppp,debug,packet <sstp-mikrotik3.local>: rcvd IPCP ConfAck id=0x2
2026-03-01 11:46:25 sstp,ppp,debug,packet <addr 192.168.255.54>
2026-03-01 11:46:25 sstp,ppp,debug <sstp-mikrotik3.local>: IPCP opened
2026-03-01 11:47:24 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo request
2026-03-01 11:47:24 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo response
2026-03-01 11:47:24 sstp,packet <sstp-mikrotik3.local> sent control packet type: echo request
2026-03-01 11:47:24 sstp,packet <sstp-mikrotik3.local> recv control packet type: echo response

So, the specific packets that appear when the SSTP client connection from MikroTik3 to the SSTP server on MikroTik4, in this last log excerpt, are different from the suspicious packets that I’m trying to debug.

Which seems to confirm my theory that the suspicious packets are NOT related to the legitimate, stably-up connections from MikroTik2 and MikroTik3 to MikroTik4. (Recall, I couldn’t capture anything in /tool sniffer while the suspicious packets were logged).

Hm. When I did the sniff, I had only looked at my SSTP VPN server port (8443).

Are there other ports on which I should monitor, or a different sniffer capture filter that I could apply, that would capture the packets that produce those various close/down sstp,ppp,debug log entries, which AREN’T on the SSTP service port 8443? (The SSTP VPN server on MikroTik4 is behind a basic ISP router/gateway firewall, which only forwards a few ports in to MikroTik4:

  • the SSTP server port 8443 as described above
  • two others ports to allow direct SSH and web admin connections to remotely manage the MikroTik BUT only after a successful two-phase knock with packets on two other ports

Hm, well, obviously, capture also on these four other ports.

Lessee…

/tool/sniffer print

[admin@MikroTik4.felines.org] /tool/sniffer> print
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: no
streaming-server: 0.0.0.0:37008
max-packet-size: 2048
filter-stream: no
filter-interface:
filter-mac-address:
filter-src-mac-address:
filter-dst-mac-address:
filter-mac-protocol:
filter-ip-address: !83.41.117.253/32
!73.80.148.50/32
filter-src-ip-address:
filter-dst-ip-address:
filter-ipv6-address:
filter-src-ipv6-address:
filter-dst-ipv6-address:
filter-ip-protocol:
filter-port: 1111
2222
3333
4444
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: or
quick-rows: 20
quick-show-frame: no
running: no

(So, sniffing for any IP address that is not either of the two currently-connected other SSTP MikroTiks, on any of the four open ports {changed for privacy}).

The suspicious close/down entries did appear again in the system log, but the packet filter caught nothing.

All of which still leaves me scratching my head…
Any ideas?

thanks,

3

Wow. I really don’t know why these system log entries did not appear before. But tonight I caught this:

2026-03-01 22:22:01 sstp,packet recv
2026-03-01 22:22:01 sstp,packet GET / HTTP/1.1\r
2026-03-01 22:22:01 sstp,packet Host: 79.152.67.82:8443\r
2026-03-01 22:22:01 sstp,packet User-Agent: Hello from Palo Alto Networks, find out more about our scans in https://docs-cortex.paloaltonetworks.com/r/1/Cortex-Xpanse/Scanning-activity\\r
2026-03-01 22:22:01 sstp,packet Accept-Encoding: gzip\r
2026-03-01 22:22:01 sstp,packet \r
2026-03-01 22:22:01 sstp,packet
2026-03-01 22:22:01 sstp,ppp,debug : CCP close
2026-03-01 22:22:01 sstp,ppp,debug : BCP close
2026-03-01 22:22:01 sstp,ppp,debug : IPCP close
2026-03-01 22:22:01 sstp,ppp,debug : IPV6CP close
2026-03-01 22:22:01 sstp,ppp,debug : MPLSCP close
2026-03-01 22:22:01 sstp,ppp,debug : LCP lowerdown
2026-03-01 22:22:01 sstp,ppp,debug : LCP down event in initial state

.. which clearly is a packet scan hitting my SSTP VPN server’s service port.

It would be nice to know why this is the first time I ever saw any system log entry prior to the CCP close entry. Any ideas?

And, separately, to armor a MikroTik SSTP VPN service, is there a way to get a MikroTik SSTP client to perform a port knock prior to initiating the SSTP VPN connection?

In /interface sstp-client I do not see any options for a pre-dial script.

In PPP profiles there are on-up and on-down settings, but those operate after the up/down transition, and to perform port knocking the script would have to execute before the SSTP VPN client connection initiates.

(I see that this was broached, but not solved, in a thread from late 2022 - Port knocking from Mikrotik )

Ugh. I suppose I could set up a script to run every minute on the client MikroTiks to just always keep the port knocked. It’s ugly, and in theory it would allow someone surveying my traffic to see how it works, but that’s not the threat model against which I’m trying to defend. I’m just interested in not allowing port scans to detect the presence of my SSTP VPN server (on the off-chance that an exploitable vulnerability is discovered in an exposed MikroTik SSTP VPN service).

Other ideas?

many thanks,