Mikrotik last disconnect reason port error

Last disconnect reason port error

Tue Apr 01, 2014 1:40 pm

Hello.
I have Mikrotik 1100AHx2 as sstp-server and 951Ui-2HnD as client.
and — i don’t understand, why. but, every 2 minutes sstp connection is terminating.

14:35:38 sstp,ppp,info sstp-out1: terminating. — conn timeout
14:35:38 sstp,ppp,info sstp-out1: disconnected
14:35:38 sstp,ppp,info sstp-out1: initializing.
14:35:38 sstp,ppp,info sstp-out1: connecting.
14:35:38 route,ospf,info OSPFv2 neighbor 10.200.0.1: state change from Full to Down
14:35:39 sstp,ppp,info sstp-out1: authenticated
14:35:39 sstp,ppp,info sstp-out1: connected

14:37:39 sstp,ppp,info sstp-out1: terminating. — conn timeout
14:37:39 sstp,ppp,info sstp-out1: disconnected
14:37:39 sstp,ppp,info sstp-out1: initializing.
14:37:39 sstp,ppp,info sstp-out1: connecting.
14:37:39 route,ospf,info OSPFv2 neighbor 10.200.0.1: state change from Full to Down
14:37:40 sstp,ppp,info sstp-out1: authenticated
14:37:40 sstp,ppp,info sstp-out1: connected

14:35:38 sstp,ppp,info : terminating. — terminated by remote peer
14:35:38 sstp,ppp,info,account ap0214 logged out, 121 9325 4459 77 75
14:35:38 sstp,ppp,info : disconnected
14:35:38 route,ospf,info OSPFv2 neighbor 172.20.18.30: state change from Full to Down
14:35:39 sstp,ppp,info,account ap0214 logged in, 10.200.18.247
14:35:39 sstp,ppp,info : authenticated
14:35:39 sstp,ppp,info : connected

14:37:39 sstp,ppp,info : terminating. — terminated by remote peer
14:37:39 sstp,ppp,info,account ap0214 logged out, 120 12554 7377 105 114
14:37:39 sstp,ppp,info : disconnected
14:37:39 route,ospf,info OSPFv2 neighbor 172.20.18.30: state change from Full to Down
14:37:40 sstp,ppp,info,account ap0214 logged in, 10.200.18.247
14:37:40 sstp,ppp,info : authenticated
14:37:40 sstp,ppp,info : connected

also, i have other 951Ui-2HnD with same config — and connection uptime is already 2 days.
Have any ideas about reasons ?

Источник

Last disconnect reason port error

Sat Aug 04, 2012 1:52 am

Have went back and forth with support a few times, sent multiple supouts and debug logs. Issue still persists.

200ish SSTP tunnels to an RB1000, 5.18 and now 5.19, all 5.18 clients. RB450gs, 433ahs, 2011s. I run Amanda backup over the VPN links. So at peak load, its running about 40ish mbit download at about 30-40% cpu load.

The problem I keep having is.. randomly throughout the day, the RB1000 SSTP server will just stop working. There will be 200 active connections, then, poof, they all get dropped and 200 clients attempt to reconnect and «pending» interfaces are created, but they never get connected. All authentication is handled through FreeRADIUS. Authentication works fine. Redundant RADIUS servers on a local network to the router. All I have to do to get it to start working again is disable the SSTP server and re-enable it. All clients almost immediately reconnect with no issues.

This may happen 1-2 times a week, or 2-3 times a day. Seems to happen most often when there is heavy load on the router, but happens quite a bit when there is almost no load (

All I can say is.. I have had 3 years worth of VPN related problems with MT. OpenVPN being a problem, advised to use SSTP. SSTP going through many ups and downs, getting better, getting worse. Problems arising due to the # of connections I have increasing as customer base grows, new releases that fix problems and introduce new ones. I dont think I have had a completely STABLE version yet.

EDIT: To add. Ive stripped the router config down to bare essentials. I disabled ipv6, hotspot, wireless packages, manually disabled all dynamic routing protocols except BGP (Using it). Bare essentials of firewall rules. Like 6 rules, one nat rule and a mangle rule acting on the VPN IPs to clamp MSS. The SSTP server has a certificate w/ the IP of the router in the name, it verifies client certs. All clients have a cert and the CA installed. 2x RADIUS servers with mysql backend. Some routes set from RADIUS, nothing fancy. Maybe one /30 or /29 per client. 1 interface on the internet, 1 interface with 4 vlans attached to a managed switch. All other firewalling is done on the other side of the switch. It really is the barest possible config. I am running the NTP server package. I ended up doing this because I had more problems when I ran the SSTP server on the same router that I had IPSEC connections, queues, and hundreds of firewall rules. So I segmented it off. It helped, but didnt solve the problem. I have gone as long as 10-12 days without an issue, but more recently, it is happening at least every day, sometimes more often.

Is anyone else running upwards of 200 SSTP tunnels on a PowerPC routerboard? Successfully?

At this point, Im not even getting responses from support as I send them new supouts and logs. Really getting irritated. Has been 10 days since the last response from them saying other problems have been fixed.. Telling me pretty much nothing

Re: RB1000 SSTP, major disconnect issues

Sun Aug 05, 2012 10:54 am

Have went back and forth with support a few times, sent multiple supouts and debug logs. Issue still persists.

200ish SSTP tunnels to an RB1000, 5.18 and now 5.19, all 5.18 clients. RB450gs, 433ahs, 2011s. I run Amanda backup over the VPN links. So at peak load, its running about 40ish mbit download at about 30-40% cpu load.

The problem I keep having is.. randomly throughout the day, the RB1000 SSTP server will just stop working. There will be 200 active connections, then, poof, they all get dropped and 200 clients attempt to reconnect and «pending» interfaces are created, but they never get connected. All authentication is handled through FreeRADIUS. Authentication works fine. Redundant RADIUS servers on a local network to the router. All I have to do to get it to start working again is disable the SSTP server and re-enable it. All clients almost immediately reconnect with no issues.

This may happen 1-2 times a week, or 2-3 times a day. Seems to happen most often when there is heavy load on the router, but happens quite a bit when there is almost no load (

All I can say is.. I have had 3 years worth of VPN related problems with MT. OpenVPN being a problem, advised to use SSTP. SSTP going through many ups and downs, getting better, getting worse. Problems arising due to the # of connections I have increasing as customer base grows, new releases that fix problems and introduce new ones. I dont think I have had a completely STABLE version yet.

EDIT: To add. Ive stripped the router config down to bare essentials. I disabled ipv6, hotspot, wireless packages, manually disabled all dynamic routing protocols except BGP (Using it). Bare essentials of firewall rules. Like 6 rules, one nat rule and a mangle rule acting on the VPN IPs to clamp MSS. The SSTP server has a certificate w/ the IP of the router in the name, it verifies client certs. All clients have a cert and the CA installed. 2x RADIUS servers with mysql backend. Some routes set from RADIUS, nothing fancy. Maybe one /30 or /29 per client. 1 interface on the internet, 1 interface with 4 vlans attached to a managed switch. All other firewalling is done on the other side of the switch. It really is the barest possible config. I am running the NTP server package. I ended up doing this because I had more problems when I ran the SSTP server on the same router that I had IPSEC connections, queues, and hundreds of firewall rules. So I segmented it off. It helped, but didnt solve the problem. I have gone as long as 10-12 days without an issue, but more recently, it is happening at least every day, sometimes more often.

Is anyone else running upwards of 200 SSTP tunnels on a PowerPC routerboard? Successfully?

At this point, Im not even getting responses from support as I send them new supouts and logs. Really getting irritated. Has been 10 days since the last response from them saying other problems have been fixed.. Telling me pretty much nothing

Wow, that sounds rough.

I would put down an X86 box with ROS 5 and start moving clients over one at a time until I hit problems. (PPC on multiple RB800s gave me big problems, in short PPC is shit for big jobs)

Try and isolate the problem.

One thing to remember about SSTP is that it looks like SSL traffic to your providing ISP. Is there any traffic shaping on your ISP supplied line? If there is, this will almost certainly cause problems.

If MT is not giving you more info, then you are most likely the only one with this problem and they have no more info. This is good because it means that something in your setup can be replaced to fix the issue since it seems to be something only effecting you.

More info about how the setup is behaving might help me help you.

Источник

Interpreting NextPort Disconnect Reason Codes

Available Languages

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how to interpret the call disconnect reason codes reported by Cisco NextPort universal digital signal processor (DSP) modules. NextPort is the next generation DSP used by Cisco to implement either voice, data, or fax on a given port. AS5350, AS5400, AS5850 platforms and new models of modem cards for AS5800 all employ digital modems with NextPort DSPs. For digital modems in C3600, AS5200, AS5300 and older models of cards for AS5800, check Mica Modem States and Disconnect Reasons : no modem firmware upgrade can make NextPort DSP out of Mica DSP or vice versa.

Prerequisites

Requirements

This document has no specific requirements.

Background Information

Whenever a call using the NextPort DSPs is cleared or disconnected, the NextPort module records the reason for the disconnect. This disconnect reason code can be used to determine whether the disconnect was normal or an error occurred. This reason code can be used to track down possible sources of failure. Modems can be disconnected due to a variety of factors such as client disconnects, telco errors, and call drops at the network access server (NAS). A «good» disconnect reason is that the DTE (client modem or NAS) at one end or the other wanted to terminate the call. Such «normal» disconnects indicate that the disconnect was not a result of modem or transmission level errors. For more information on determining whether the disconnect reason is «normal», refer to Overview of General Modem and NAS Line Quality

Note: The disconnect reason is managed in a first-come-first-serve fashion. This means that the first disconnect reason generated is the only disconnect reason recorded. If the modem and the NAS attempt to terminate the session simultaneously and the modem happens to save the disconnect reason before the LINK_TERMINATE message from the NAS is processed, then the NAS disconnect reason is ignored.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Determining the Disconnect Reason

When evaluating whether you are experiencing good or bad disconnects, it is important to obtain the history of disconnects that a particular port has experienced. In most environments, the disconnect reason is obtained using modem call records or call tracker syslog messages. This disconnect code can then be interpreted using the table provided in this document (or check the for modem analysis tools). Use the following commands to determine the disconnect reason:

The show spe modem disconnect-reason command does not display the disconnect reason code as a hexadecimal value. However, it does indicate the disconnect reason as a name. The name and class of the disconnect reason can be found in and respectively.

The show port modem log command displays the Disconnect Reason Code as a hexadecimal value. Refer to the :

The next section looks at some examples.

Using the show port modem log Command

Use the show port modem log slot/port command to obtain the disconnect cause code (in Hex) for a particular call on a specific port. This disconnect code is identical to the cause code obtained from modem call-record and call-tracker syslog outputs. An example is shown:

From the example above, note that the disconnect code is 0x220.

Using the show spe modem disconnect-reason Command

Use the show spe modem disconnect-reason

command to determine the distribution of disconnect reasons that the particular port has experienced. A sample summary output of all the ports is shown below:

From the example above, let us say that we are interested in the disconnect category «Disc» within CLASS EC LCL. To determine what the disconnect reason Disc means, go to the entry corresponding to the class (CLASS EC LCL ) and the disconnect reason name (Disc) which shows a hex code of 0x220 and is a normal disconnect.

Источник

Mikrotik last disconnect reason port error

Sun Jan 17, 2016 9:58 am

da89ni says it works as desired with the Ethernet plugged into his laptop. From the phrasing, I believe that means the same cable was used in both setups. That would tend to rule out the modem and the cable.

Given that interpretation of the original post, I suspect configuration, software bug, or bad port on the RB951-2n, in that order.

A quick test to rule out hardware would be to change the parent interface of the pppoe-client interface.

Re: PPPoE failed on RB951-2n (constantly connect and disconnect)

Mon Jan 18, 2016 12:14 pm

I called my iSP provider and they told me that there are no restriction in using a router but they can’t offer me support for router configuration, I must connect the external cable (provided by iSP) directly to a PC and if there is no internet access then a ticket will be opened considering that there is a problem from their side.

When i connect the external cable (provided by iSP) directly to a PC and use DialUp PPPoE (in windows 10) the PC connects and internet works fine. So. the conclusion is that cable and service are ok.

I wold like to say once more that this situation occurred Friday evening without any intervention to the setup. I just noticed that internet access is not working and checked the LOG. The router is using this setup for more than a year. Normally my first suspicion was for the iSP but because Win10 DialUP PPPoE is able to connect the problem i think is back to router side (or somewhere in between ?!).

Источник

Mikrotik last disconnect reason port error

Mon Dec 06, 2010 8:06 pm

I am trying to find a way to disconnect unauthorized hotspot users. We use the Mikrotik hotspot as centralized controller for a number of wifi hotspots. However if a user is not authorized they tend to get a hung session that must be manually removed from the hotspot host list and I’d like to automate this in some fashion.

I tried using this script and various other versions of something similar:
/ip hotspot host remove [/ip hotspot host find where !authorized]

This has no effect. In fact just attempting to get a list of unauthorized hosts using something like /ip hotspot host find where !authorized does not print any results on the CLI (should it?). I can get a list of unauthorized hosts if I use something like /ip hotspot host print where !authorized, but I don’t know how to extract the ID out of this to remove the host.

[admin@Mainstreet Office — Ross Test] /ip hotspot host> print where !authorized
Flags: S — static, H — DHCP, D — dynamic, A — authorized, P — bypassed
# MAC-ADDRESS ADDRESS TO-ADDRESS SERVER
0 H 00:26:B9:AD:57:C8 192.168.5.238 192.168.5.238 hotspot1

I also attempted to remove the user using a radius disconnect message (since we have centralized radius authentication/authorization anyway).
However a radius disconnect fails:
# echo -e «NAS-IP-Address=172.17.0.5nFramed-IP-Address=192.168.5.238» | radclient -r 1 172.17.0.5 disconnect secret
Error message: «Radius disconnect request for unknown ip 192.168.5.238»
(Note that sending the same disconnect message for the host when it is authorized results in the host being properly disconnected)

Attempting to send a DM using the User-Name or Calling-Station-Id instead results in an error message on the Mikrotik that states «Radius disconnect with no ip provided»

I attempted to add additional information such as the hotspot nas port and username along with the Framed IP but this also fails stating that the IP can not be found.

How can I clear out those unauthorized hotspot hosts without having to do it manually?

Источник

Mikrotik last disconnect reason port error

Mon Aug 01, 2016 10:38 am

Hello.
There mikrotik 750GR2. Connecting to an Internet configured so. 2 ports are combined in the bridge. One port is plugged with a white asterisk ip. The second interface, set the other white ip LAN through which comes to internet. The 3-5 of the ports in the switch group and look to the local area network. Users go to the Internet through nat. On mikrotike set l2tp. Users connect windows (7 and xp) l2tp client and use the LAN resources. But every 8 hours connection unexpected disconnect. In this case, the log records mikrotik

failed to begin ipsec sa negotiation
print detail
Flags: X — disabled, D — dynamic
0 address=0.0.0.0/0 local-address=:: passive=no port=500 auth-method=pre-shared-key secret=»111111111″
generate-policy=port-override policy-template-group=*FFFFFFFF exchange-mode=main-l2tp send-initial-contact=yes
nat-traversal=yes hash-algorithm=sha1 enc-algorithm=aes-256,aes-192,aes-128,3des dh-group=modp1024 lifetime=1h
dpd-interval=disable-dpd dpd-maximum-failures=5

[admin@Mikrotik750GR2] /ip ipsec proposal>> print detail
Flags: X — disabled, * — default
0 * name=»default» auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-128-cbc,3des lifetime=30m pfs-group=modp1024

Re: L2TP is disconnect after every 8 hours

Wed May 24, 2017 4:58 pm

Re: L2TP is disconnect after every 8 hours

Wed May 24, 2017 5:49 pm

You can try to change the profile from default-encryption to default and test if that solves the issue.

Sometimes the encryption gets out of sync and resulting that the tunnel gets terminated and the reconnects

Re: L2TP is disconnect after every 8 hours

Thu Jun 01, 2017 10:54 am

Re: L2TP is disconnect after every 8 hours

Mon Jun 05, 2017 9:53 am

Re: L2TP is disconnect after every 8 hours

Mon Jul 17, 2017 9:36 am

Hi
I have exactly the same problem. all my L2TP/IPSEC session get disconnected after exactly 8 hours

Did someone manage to find a solution to this ?

Re: L2TP is disconnect after every 8 hours

Tue Jul 18, 2017 8:12 am

Re: L2TP is disconnect after every 8 hours

Thu Mar 08, 2018 3:41 pm

Re: L2TP is disconnect after every 8 hours

Sun Apr 15, 2018 8:29 am

Hello, I have exactly the same problem. My IPsec/L2TP connection drops every 8 hours. It takes it up to 50 minutes to recover. I’ve looks through the logs, but was not able to find anything wrong. I’ve checked on server side — timeout there 23 hours, on Mikrotik I did not found where timeout can be setup.

What else I could check/look at to fix this?

Re: L2TP is disconnect after every 8 hours

Fri Apr 27, 2018 6:35 pm

8h on L2TP/IPSec

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 12:41 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 1:00 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 2:00 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 2:09 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 2:42 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 3:50 pm

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 4:23 pm

In my house now: (receiving)

Flags: R — radius
0 name=»casavzla» service=l2tp caller-id=»186.xx.xx.xx» address=192.168.16.11 uptime=3d14h33m3s encoding=»cbc(aes) + hmac(sha256)»
session-id=0x81002F85 limit-bytes-in=0 limit-bytes-out=0

1 name=»mayjo» service=l2tp caller-id=»95.xx.xx.xx» address=192.168.16.10 uptime=9h31m1s encoding=»cbc(aes) + hmac(sha256)» session-id=0x8100301C
limit-bytes-in=0 limit-bytes-out=0

I don’t know how to print the outgoing ppp/pptp.

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 9:53 pm

hgonzale, what are the clients in your case?
The thing is that as this topic made me curious, I’ve started an L2TP/IPsec connection using the embedded VPN client of Windows 10 and used it so that there would be real traffic through the L2TP session, and it broke down as well. In my case, it didn’t take exactly 8 hours but something like 7:36 until the Windows client has decided to renew the IPsec phase 1, but it took it so long between tearing down the old one and starting to establish the new one that Mikrotik has managed to tear down the L2TP layer on inactivity in the meantime. See the commented tour below.

The DHCP lease time on the laptop side is 10 minutes so it is unlikely that this would be related, as there were tens of DHCP renewals which didn’t break the IPsec. So I’ll try another round during the night, this time with an Android device.

On top of that, there is no ISP involved — the laptop is connected using WiFi to one ‘Tik (uptime much longer than between now and the L2TP breakdown), and the L2TP/IPsec connection passes through NATting OpenWRT device and gets to the other ‘Tik which is the L2TP/IPsec server.

When the IPsec connection is initially established, the client declares sincerely the Phase 1 lifetime limitation to 8 hours:

After this, the connection establishes and just works, only Phase 2 is renegotiated from time to time without impact.
Nothing indicates a problem just before the breakdown:

KA means KeepAlive and it is an IPsec keepalive here. These are sent three times a minute.

This is an L2TP keepalive — the server sends HELLO and the client responds with ack. These are sent once a minute and they’re asynchronous to the IPsec KeepAlives

Here below the trouble begins:

So the client has sent us a request to delete the IPsec Phase 1 (ISAKMP), which consequently takes down Phase 2 (ESP in this case) as well.

The line above is important — as we’ve removed the policy, the L2TP packets won’t be matched and sent via the SA although it still exists by now.

Demolition of the IPsec connection completed. The L2TP transport packets cannot get anywhere until the IPsec connection gets established again. But it’s almost the time to send an l2tp HELLO.

and initiates the disconnection process.

Three seconds later, which is 32 seconds after it has shot down the previous Phase 1, the client initiates establishment of a new session:

It then took another 2 seconds until new SAs were negotiated and installed:

And it took another 8 seconds until the client started sending its own HELLO keepalives still within the old session (see the

As Android client also limits the Phase 1 lifetime to 8 hours, I’ll first check how the renegotiation looks like in Android case, and then I’ll try whether configuring a shorter lifetime limit at RouterOS side won’t make the client(s) behave differently.

Re: L2TP is disconnect after every 8 hours

Sat Apr 28, 2018 10:18 pm

All mines are other mikrotiks..

I have a dialup pptp to my server without encryption but is not in the list.
They are only dial in, I need to extract the dial out, but I don’t know to do

Re: L2TP is disconnect after every 8 hours

Sun Apr 29, 2018 8:10 pm

The results with my version of the embedded Android client are even more cryworthy than with Windows 10.

The Android client, like the Windows 10 one, declares a 28800 seconds Phase 1 lifetime in its Phase 1 proposal, and when this time expires, RouterOS drops the connection, without any attempt from Android side to re-establish it before or after the drop. But the Andriod still shows the VPN connection as active and stubbornly attempts to use it, so you can see «packets/bytes sent» on it to grow but «packets/bytes received» stay unchanged, several hours after the connection went down.

I’ve limited the Phase 1 lifetime at Mikrotik side, assuming that it might actively terminate the Phase 1 security association and thus provoke the client for a renewal, or that the client might proactively renew the session from its side once the end of the lifetime announced by Mikrotik approaches; well, none of this happens. Mikrotik keeps the session alive (presumably because it is configured to server mode and is thus unable to renew it), and Android doesn’t bother to renew it either, so the session continues to run. And the Windows client behaves the same way. I expect both sessions to end the same way like when 24 h lifetime is set on Mikrotik side, after 8 hours.

So I assume that gents in Redmond became aware of the issue and have added the auto-renewal into the WIndows10 client (which explains that these sessions do not last exactly 8 hours as reported before), but the auto-renewal takes it too much time (so far?) for the l2tp server not to give up.

If someone here happens to own some iThing, it might be interesting for the audience here to check how the iOS clients behave in this regard.

Источник

Mikrotik last disconnect reason port error

Fri Nov 17, 2017 4:01 pm

Issue:
PBX cannot re-register with the SIP trunk, after connection loss

Description:
I am using an Asterisk based PBX behind a Microtik RB3011UiAS. The PBX connects to a SIP trunk. Every 24 hours we have a forced disconnection of the internet connection. After the forced disconnection, the PBX tries to log on to the SIP trunk again. The PBX sends packets to the SIP trunk, but there are no response packets in the RouterBoard. A new connection can only be established after restarting the RouterBoard, disconnecting the PBX connection or changing the SIP port.

Versions affected:
6.39.3, 6.40.4, 6.40.5 tested

How to reproduce:
1) Establish Internet connection via PPPoE
2) Register Asterisk based PBX (e.g. FreePBX) to SIP trunk
3) Disable PPPoE interface and wait a few seconds
4) Enable PPPoE interface

Network setup:

Notes:
There seems to be a problem with NAT, because after restarting the RouterBoard or changing the port, the connection is immediately reestablished. Deleting the connection from the connection tracking does not solve the problem.

Support TicketID:
Ticket#2017112222000777

Best regards,
Stefan

Re: NAT table not cleared correctly

Fri Nov 17, 2017 9:20 pm

Re: NAT table not cleared correctly

Fri Nov 17, 2017 9:48 pm

Re: NAT table not cleared correctly

Fri Nov 17, 2017 10:26 pm

Re: NAT table not cleared correctly

Fri Nov 17, 2017 11:38 pm

Re: NAT table not cleared correctly

Sat Nov 18, 2017 10:25 am

Re: NAT table not cleared correctly

Sat Nov 18, 2017 1:03 pm

Re: NAT table not cleared correctly

Mon Nov 20, 2017 3:28 pm

Re: NAT table not cleared correctly

Mon Nov 20, 2017 11:20 pm

Do you receive new IP on wan interface thought DHCP or there’s static one? Sip providers often firewalling clients connection and make a static entry user-ip. Sip use udp, udp-timeout (time; Default: 10s)

Re: NAT table not cleared correctly

Tue Nov 21, 2017 12:18 am

Re: NAT table not cleared correctly

Tue Nov 21, 2017 8:24 am

You may try In firewall services disable sip helper

Re: NAT table not cleared correctly

Tue Nov 21, 2017 10:07 am

thank you for the advice. It’s already disabled. I just forgot to mention it.

Best regards
Stefan

Re: NAT table not cleared correctly

Tue Nov 21, 2017 3:44 pm

Ok. Can you past /ip firewall nat export compact?

Re: NAT table not cleared correctly

Tue Nov 21, 2017 3:44 pm

Ok. Can you past /ip firewall nat export compact?

Re: NAT table not cleared correctly

Tue Nov 21, 2017 5:19 pm

You can find my settings in the start post. I will change that from «codebox» to «code». It should be better visible

For NAT it’s just that:

NAT table not cleared correctly

Wed Nov 22, 2017 7:24 am

Ok. There are all good in ip firewall. Try turn on packet sniffer on all interface and udp and port 5060. How the packers arrive? Look at connection tracker when you make outgoing call. Look at asterisk console, ‘sip show peers’, and calls log. You also can turn on debug on specific sip channel!

Re: NAT table not cleared correctly

Wed Nov 22, 2017 10:34 am

Re: NAT table not cleared correctly

Wed Nov 22, 2017 11:03 am

What usually happens om my network is the reply dst-address is incorrect.

Instead of it being the public ip address it ends up being the private ip address of the router or sip device.

Its almost as if NAT did not work when the link came back up.

Manually removing the connection from connection tracking solves the problem for me at least.

Re: NAT table not cleared correctly

Wed Nov 22, 2017 11:19 am

the Reply Dst. Address is correct. It’s my public IP.
It’s also correct in the SIP message header.

Removing the connection manually or by script from the connection tracking doesn’t solve the problem.

Best regards
Stefan

NAT table not cleared correctly

Wed Nov 22, 2017 11:25 am

Stefan, can you start packet sniffer at mikrotik router? /tool packet sniffer

Re: NAT table not cleared correctly

Wed Nov 22, 2017 11:32 am

Re: NAT table not cleared correctly

Thu Nov 23, 2017 12:01 am

Response packet arrive to Wan interface?

Re: NAT table not cleared correctly

Thu Nov 23, 2017 12:05 am

Re: NAT table not cleared correctly

Thu Nov 23, 2017 9:42 am

Re: NAT table not cleared correctly

Thu Nov 23, 2017 4:55 pm

Re: NAT table not cleared correctly

Thu Nov 23, 2017 6:29 pm

that’s something I hadn’t tried yet. That’s why I just tested it and I have the same problem that the PBX doesn’t register anymore.

Best regards
Stefan

Re: NAT table not cleared correctly

Thu Nov 23, 2017 9:45 pm

Try open a ticket in support system of tour SIP provider. If provider don’t send to you SIP responses it means, that problem not at router point view!

Re: NAT table not cleared correctly

Thu Nov 23, 2017 11:04 pm

NAT table not cleared correctly

Fri Nov 24, 2017 9:29 am

My friend, i’am work with two SIP provider simultaneously without any problem(one asterisk server with different external IP address nated through mikrotik). If your router don’t receive any packets from provider of SIP, where you mean problem occur?

Re: NAT table not cleared correctly

Fri Nov 24, 2017 9:50 am

Re: NAT table not cleared correctly

Fri Nov 24, 2017 12:39 pm

Packet sniffer on mikrotik can view all packets to the wan interface(before nat and after nat! No packets no SIP service))) Try change mikrotik to the . dlink, still problem occur?

NAT table not cleared correctly

Fri Nov 24, 2017 12:44 pm

You can also export compact, without sensitive info, your config and put here.

Re: NAT table not cleared correctly

Fri Nov 24, 2017 2:22 pm

I tried it with our old pfsense router and at the beginning it looked like the problem was the same. I have reset the internet connection and the PBX could no longer log on to the SIP trunk. BUT here it was enough to delete the connection from the connection table and a new connection was established immediately. Exactly this doesn’t seem to work properly with the Mikrotik Router, so that there are still some leftovers.

Here is my complete configuration:

Re: NAT table not cleared correctly

Fri Nov 24, 2017 3:20 pm

Re: NAT table not cleared correctly

Fri Nov 24, 2017 3:58 pm

I just copied the default profile to wan to add an interface up/down script for wan interfaces, so I can clear the connection table if the state changes. But I changed it back to default for testing and it doesn’t help.
Because I don’t want to make our public IP public I changed it to a pseudo IP.

Routing table before internet reset:

Re: NAT table not cleared correctly

Fri Nov 24, 2017 4:04 pm

Re: NAT table not cleared correctly

Fri Nov 24, 2017 4:17 pm

Re: NAT table not cleared correctly

Fri Nov 24, 2017 4:27 pm

Re: NAT table not cleared correctly

Fri Nov 24, 2017 4:53 pm

There’s no difference. The PBX cannot log on to the SIP trunk.

Can you perhaps explain to me what the advantage is if I enter this manually?

Re: NAT table not cleared correctly

Fri Nov 24, 2017 9:35 pm

NAT table not cleared correctly

Sat Nov 25, 2017 1:35 am

I hope that adsl mobem in bridge mobe(Disable dhcp client on ether1-wan interface ) Print sip connection at now, please

Re: NAT table not cleared correctly

Sat Nov 25, 2017 11:50 am

Re: NAT table not cleared correctly

Sat Nov 25, 2017 7:14 pm

Yep, if you need hide your public IP use something like this 1.1.1.1, not private pools! Maybe its asterisk sip.config problem? Do you use provider recommend config? And try install bugfix only image on mikrotik

Re: NAT table not cleared correctly

Sat Nov 25, 2017 10:01 pm

Re: NAT table not cleared correctly

Sun Nov 26, 2017 7:53 am

I saw that you have bridge interface try to check the /bridge setting use-ip-firewall

Please go to /ip setting and choose rp-filter to loose

Sent from my SM-N920T using Tapatalk

Re: NAT table not cleared correctly

Sun Nov 26, 2017 7:53 am

I saw that you have bridge interface try to check the /bridge setting use-ip-firewall

Please go to /ip setting and choose rp-filter to loose

Sent from my SM-N920T using Tapatalk

Re: NAT table not cleared correctly

Mon Nov 27, 2017 10:32 am

Re: NAT table not cleared correctly

Mon Nov 27, 2017 10:44 am

Re: NAT table not cleared correctly

Mon Nov 27, 2017 11:07 am

Re: NAT table not cleared correctly

Mon Nov 27, 2017 11:16 am

NAT and SIP in combination is asking for trouble, and a non-cooperative ISP that is resetting the connection (and maybe even changing the address) only adds to the problem.

I would advise to configure IPv6 on your connection and use that, so you do not need NAT.
When your ISP or SIP provider don’t support IPv6 I guess it is time to shop for some more competent suppliers.

Re: NAT table not cleared correctly

Mon Nov 27, 2017 11:27 am

Re: NAT table not cleared correctly

Mon Nov 27, 2017 11:46 am

In Germany we unfortunately have a forced disconnection of the internet connection with ADSL/VDSL. A change of provider is already planned, but we will also have a forced separation every 180 days. There is also an internet connection without forced separation via SDSL, but we cannot and will not afford it.

The problem here is not NAT and VoIP, but that connections in the router are probably not disconnected properly. And for me it’s still a bug in RouterOS, until someone can show me a configuration issue

Re: NAT table not cleared correctly

Mon Nov 27, 2017 12:17 pm

Re: NAT table not cleared correctly

Mon Nov 27, 2017 12:44 pm

Re: NAT table not cleared correctly

Mon Nov 27, 2017 1:21 pm

From what you wrote I understand that you manually (or with scripting) clear the connections in connection tracking but not disabling the whole thing altogether. Maybe that will get connection tracking ‘unstuck’?

[offtopic]
And here I though that only my country had bad internet policy with a stupid limitation of 10% upload over the download speed. Or naming VDSL as a Fiber service (damn marketing departments. )

But forcing a disconnect on you every 24h is ridiculous. I wonder how Germans accept that stupid policy!
Then again, in countries like Australia or Canada they still have monthly data caps, so. I guess we shouldn’t complain, there are worse situations out there

Out of curiosity, what is the reasoning behind this periodic forced disconnect policy?

Mobile data plans are a completely different beast. There you have to deal with dinosaur telecommunications companies that need to charge everything based on volume/time. It’s like an addiction to them ISPs usually tend to be more openminded. or not.
[/offtopic]

Re: NAT table not cleared correctly

Mon Nov 27, 2017 2:12 pm

But forcing a disconnect on you every 24h is ridiculous. I wonder how Germans accept that stupid policy!
Then again, in countries like Australia or Canada they still have monthly data caps, so. I guess we shouldn’t complain, there are worse situations out there

Out of curiosity, what is the reasoning behind this periodic forced disconnect policy?

Re: NAT table not cleared correctly

Mon Nov 27, 2017 2:19 pm

NAT is only a workaround for the migration period to IPv6. Once IPv6 is fully deployed there is no more reason for many-to-1 NAT and issues like this (trouble with NAT-unfriendly protocols) disappear.
I think you should consider IPv6 the solution.

Also you are not the only one with those issues (Asterisk trunk connections lost when behind German ISP) and there are special Asterisk solutions to re-establish the connection in that case.

Re: NAT table not cleared correctly

Thu Nov 30, 2017 2:40 am

Hi Forum Users, I am delighted to know i am not the only person experiencing this.

* Same issue. When running PPPoE tunnel over VDSL, if VDSL tunnel drops / re-auths, the trunk becomes unreachable until the router has been rebooted.
* The issue is NOT limited to NAT / PBX’s on private networks. This also affects systems on PUBLIC IP’s.
* All other TCP/UDP traffic remains unaffected and continues to pass.

* Country: Australia.
* Provider: We are an ISP, We use our own ranges. We auth our own customers. We run our own LNS.
* Static IP: Yes.
* Internet Type: NBN / VDSL.

* Network Engineer.
* SIP Engineer.
* Changed Routers from HAP to RB2011.
* Run MPLS / Voice Networks up the Eastern Seabord, using over 100 MikroTik’s & Redback SE Series.

Hardware Software In-Use.

(Provider Details)
* LNS, Redback Smartedge 100.
* VMWare ESX 5.5 (Trunk Hypervisor).
-> VMXNet3 NIC.
-> VMware Tools Installed.
-> CentOS 6.5.
-> Asterisk 11.7.0.
-> Public Address: Yes.

(Customer Details)
* Netcomm NF10WV VDSL Modem (Bridged).
* HP Elitedesk 8000 (ESXi -> PBX).
* MikroTik HAP Lite and RB2011UiAS (PPPoE Dialler, Router, Firewall).
* HP OfficeConnect 1920 (PoE Switch).
* ESXi v6.5.
-> VMXNet3 NIC
-> VMware Tools Installed
-> FreePBX Distro v6.
-> FWConsole version 13.0.192.8
-> Asterisk Version 13.14.0
-> Public Address: Yes
-> Private Address: Yes

The following behaviour has been observed when the issue occurs.

* SIP Debug (no apparent SIP responses are recieved by either side, e.g. OPTIONS, INVITE).
* Capture via TCPDump reveals that the packet is being sent by both instances of Asterisk but nothing being recieved on remote end.
* MikroTik Conntrack shows the session but no repl bytes / packets are recorded. This is further reflected by a lack of ‘Seen Reply’ flag.

The following steps have been attempted to detemrmine the cause and workable solution at the customer site WITHOUT REBOOTING. They have NOT worked.

* Reset sessions in MikroTik Conntrack.
* Stop Asterisk for 10 Minutes
* Reboot Asterisk
* Reboot Hypervisor
* SIP ALG on/off (tried both, does not matter).
* Static Default Route (with pref src set).
* PPPoE Dialler profile set to ‘Default’.
* Redirect and retargetted 5080, (translated remotely to 5060), the trunk becomes reachable until a subsequent disconnect/reauth.
* Redirect and retargetted 5060, the trunk remains unreachable.
* Added port forward udp:

The following steps have been attempted to detemrmine the cause and workable solution at the provider site. They have NOT worked.

* Added redirect (IPTABLES POSTROUTING) ports from 5080 -> 5060 on Trunk box.
* Changed customer target port to 5080. The trunk becomes reachable until a subsequent disconnect/reauth.
* Changed customer target port back to 5060. The trunk remains unreachable.

* I had set up the same test conditions at my lab. With RB2011, PPPoE (over true Fibre Optic) with VMWare workstation and a FreeBSD 10.3 / Asterisk 13 Server. I could not reproduce the error.
* Routed a public /30 to the customer.
* Added vlan interface to MikroTik w/ public IP.
* Added vlan inerface / portgroup to PBX.
* Assigned public IP to PBX.
* Changed last resort gw to new public /30.
* Removed NAT rules, specific to SIP / VoIP.
* Reconfigured SIP configs to listen/connect via/on new public IP.
* Established bi-directional trunk.
* Forced disconnect/re-auth of PPPoE.
* Trunk becomes unreachable until Reboot.

* I suspect the MikroTik’s kernel, subsequent to the disconnect/reauth is no longer processing the SIP packets, irrespective of the port used prior to the disconnect.
* It appears session beccomes stuck in the kernel likely due to internal RouterOS interface / session identification no longer existing.

Источник

srv8.vpn.zaborona.help

Оперативки он почти не занимает. Так и сделал. Скрипт создал список подсетей. Потом уже сам добавил правило маркировки трафика который идет к подсетям из етого списка, а затем в маршрутах весь маркированый трафик направил в тунель все заработало. Ну VK OK Yandex mail.ru так точно )))) Спасибо.
Может кому пригодится:
Создаем шедулер для обновления маршрутов раз в 3 дня.

/system scheduler
add interval=3d name=sync_uablacklist on-event="/system/script/run sync_uablacklist" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-date=dec/06/2021 start-time=05:00:00

Создем таблицу маршрутизации

/routing table
add fib name=zaborona

Правило маркировки трафика к IP адресам из списка.

/ip firewall mangle
add action=mark-routing chain=prerouting comment="Mark to zaborona" dst-address-list=uablacklist new-routing-mark=zaborona passthrough=yes

Маршрут маркированного трафика в интерфейс забороны.

/ip route
add comment="Route to zaborona" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=zaborona pref-src="" routing-table=zaborona scope=30 suppress-hw-offload=yes target-scope=10

Ну и сам скрипт добавляем и сразу запускаем.

/system script
add dont-require-permissions=no name=sync_uablacklist owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":local apiPrefix "https://uablacklist.
    net/subnets_mikrotik_"r
    n:local tempFile "uablacklist.txt"r
    n:local listName "uablacklist"r
    nr
    n/log info "removing existing '$listName'..."r
    n:put "removing existing '$listName'..."r
    n/ip firewall address-list remove [/ip firewall address-list find list=$listName]r
    nr
    n:local i 0r
    n:local isEnd falser
    n:do {r
    n    :local apiPath "$apiPrefix$i.txt"r
    n    /log info "fetching UA blacklist registry piece ($apiPath)..."r
    n    :put "fetching UA blacklist registry piece ($apiPath)..."r
    n    :local contentLen 0r
    n    :local content ""r
    n    :do {r
    n        /tool fetch url=$apiPath dst-path=$tempFiler
    n        :set content [/file get [/file find name=$tempFile] contents]r
    n        :set contentLen [:len $content]r
    n    } on-error={r
    n        /log info "no more pieces"; r
    n        :put "no more pieces"r
    n        :set isEnd truer
    n    }r
    n    :local lineEnd 0r
    n    :local line ""r
    n    :local lastEnd 0r
    n    :local company ""r
    n    :while ($lastEnd < $contentLen) do {r
    n        :set lineEnd [:find $content "\n" $lastEnd ]r
    n        :set line [:pick $content $lastEnd $lineEnd]r
    n        :set lastEnd ($lineEnd+1)r
    n        :local entry [:pick $line 0 ($lineEnd-1)]r
    n        :if ([:pick $line 0 1] != "#") do={r
    n            :if ([:len $entry ] > 0) do={r
    n                /log info "add '$entry' subnet of '$company' to list '$listName'...";r
    n                :put "add '$entry' subnet of '$company' to list '$listName'...";r
    n                :do {r
    n                    /ip firewall address-list add list=$listName address=$entry comment=$companyr
    n                } on-error={r
    n                    /log info "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."; r
    n                    :put "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."r
    n                }r
    n            }r
    n        } else={r
    n            :set company [:pick $line 2 ($lineEnd) ]r
    n        }r
    n    }r
    n    :set i (i+1)r
    n} while (!$isEnd)"

/system/script/run sync_uablacklist

P.S. Совсем забыл. У кого в фаерволе есть правило «fasttrac connection» его придется отключить, чтоб ето нормально работало. Так как fasttrac konnection позволяет трафику миновать большую часть фаервола, то маркировка трафика будет работать не корректно, заблокированные сайты будут открываться, но медленнее. Если же «fasttrac connection» все же нужен, тогда выход пока один, прописывать маршруты прямо в /ip routes к каждой подсети из списка забороны.

I have installed latest softether server on linux machine in AWS.

My management tools connect correctly and I can also connect with my client to it correctly (NAT and DHCP are used).
If I connect with softether client it works to the best of my knowledge ok.
If I try to use SSTP client on my Mikrotik router, whenever some significant traffic starts flowing connection drops and reestablishes and drops again and so on.

In my log file I have following:

2015-03-27 15:42:48.425 SSTP PPP Session [9xxxxxxx:33896]: The PPP session is disconnected because the upper-layer protocol «SSTP» has been disconnected.
2015-03-27 15:42:48.425 SSTP PPP Session [9xxxxxxx::33896]: The PPP session is disconnected.
2015-03-27 15:42:48.657 SSTP PPP Session [9xxxxxxx::33897]: A new PPP session (Upper protocol: SSTP) is started. IP Address of PPP Client: 94.xxxx (Hostname: «cpe-9xxxxxxx:»), Port Number of PPP Client: 33897, IP Address of PPP Server: 10.170.90.141, Port Number of PPP Server: 443, Client Software Name: «Microsoft SSTP VPN Client», IPv4 TCP MSS (Max Segment Size): 0 bytes
2015-03-27 15:42:48.748 Connection «CID-102» terminated by the cause «Connection has been disconnected.» (code 3).
2015-03-27 15:42:48.748 Connection «CID-102» has been terminated.
2015-03-27 15:42:48.748 The connection with the client (IP address 94.2xxxxxx, Port number 33896) has been disconnected.
2015-03-27 15:42:48.980 [HUB «DEFAULT»] Session «SID-TEST-[SSTP]-31»: The session has been terminated. The statistical information is as follows: Total outgoing data size: 146688 bytes, Total incoming data size: 4529 bytes.
2015-03-27 15:42:49.000 Connection «CID-103» terminated by the cause «The VPN session has been deleted. It is possible that either the administrator disconnected the session or the connection from the client to the VPN Server has been disconnected.» (code 11).
2015-03-27 15:42:49.000 Connection «CID-103» has been terminated.
2015-03-27 15:42:49.000 The connection with the client (IP address 94.xxxxxxxxxxxxx, Port number 33896) has been disconnected.

This is all I see in my log file as far as disconnection goes, then, a couple if miliseconds later I see that link has been established again.

2015-03-27 15:42:49.132 On the TCP Listener (Port 0), a Client (IP address 94xxxxxxxxxxxxxx, Host name «cpe-9xxxxxxxxxxxxxxxxxxxxxxx», Port number 33897) has connected.

—

Now, my question is where to look for in order to find error or misconfiguration? Mikrotik connect ok with other SSTP (non sofether) servers, and my softether client works ok with the server.

This is a guide illustrating how to troubleshoot communication between your router (Mikrotik example) and the Radius server (Splynx).

Video tutorial for Radius configuration:

Step 1

Firstly make sure that the router is accessible from Splynx and vice versa that the router can «reach» Splynx. In Splynx you can check the reachability with a ping status from Splynx to the router:

This troubleshooting step is only suitable when the «ping» (ICMP traffic) is not restricted between the router and the Splynx server (If ICMP echo responses are not blocked/filtered on the firewall).

Also read these manuals and compare the settings to ensure that setup is correct:

• in case of using PPPOE with Radius follow this: PPPoE with RADIUS

• in case of using DHCP with RADIUS (IPoE) follow this: DHCP with RADIUS

Step 2

Compare RADIUS parameters on the router information tab in Splynx and on the Mikrotik router under the RADIUS menu:

The Secret field on the Mikrotik should be the same as field Radius secret on the router in Splynx.

The IP Address field on the Mikrotik should be filled with Splynx’ IP.

The Src.Address field on Mikrotik should be filled with the router IP or can be 0.0.0.0.

The NAS IP field in Splynx is the real source IP address for RADIUS packets. It is recommended that in the Radius settings of the Mikrotik router Src. address equals NAS IP in Splynx.

Also make sure that you don’t have multiple RADIUS servers configured with same services:

You can have multiple RADIUS servers however each server should be configured with unique services, for example: RADIUS server #1 configured for DHCP service, RADIUS server #2 configured for PPP service.

Step 3

Check the firewall and ports. RADIUS is transported over UDP on ports 1812 (authorization) and 1813 (accounting) so these 2 ports should be open on the router as well as port 3799 (radius incoming) should be open and not blocked by any firewall rules/filters.

Step 4

Inspecting of logs.

By default Splynx writes logs into 2 files: coa.log and short.log that you can find in the folder /var/www/splynx/logs/radius on CLI or via the web interface, navigate to Administration → Logs → Files and search these 2 files.

The short.log file will display all records of login attempts, the reason of disconnection. For example:

28/02 14:54:16:7361 - [Login               ] - [10.2.32.109    ] - Accept
28/02 14:54:23:3637 - [C38F676DB15B        ] - [10.2.36.0      ] - Log in
28/02 14:54:18:6727 - [C38F676DB15B        ] - [10.2.33.190    ] - Log off -  (NAS-Error)
28/02 14:54:19:3702 - [26117AB65E2B        ] - [10.2.36.0      ] - Log off -  (Session-Timeout)
28/02 14:54:22:7030 - [-Unknown-           ] - [10.250.74.24   ] - Reject (ATTR + IP accept) - [26117AB65E2B] -> [service1] Customer not found
28/02 14:54:23:2525 - [26117AB65E2B        ] - [10.2.33.190    ] - Reject (Attribute accept) - [FCACAF943B30] -> [service1] Customer is not active
28/02 14:54:14:2384 - [user                ] - [10.2.36.247    ] - Reject - [B4FBE4ACFCC2] -> [service1] Customer is already online
28/02 14:54:21:2743 - [265798031           ] - [               ] - [card] Accept
28/02 14:54:21:5017 - [265798031           ] - [10.5.28.211    ] - [card] Log in
28/02 15:10:35:6518 - [voucher-login       ] - [10.1.0.202     ] - [card] Log off -  (User-Request)
28/02 15:11:05:2315 - [serieALRClM4sj      ] - [               ] - Reject card - [4FFE0CD555D3] -> [hap-lite] Password is incorrect

This file contains the following information: date and time, login of the service, IP and description of action.

Descriptions of records:

• Accept — The Splynx server received the Radius-Access Request packet from the Router and a Radius Access-Accept packet was sent back. Customer was successfully authenticated. Please note, if MS-CHAP is used for authentication, we can see Accept here even if password is incorrect;
• Log in — The Splynx server received the Radius Accounting-Start packet from Router;
• Log off — The Splynx server received the Radius Accounting-Stop packet from Router;
• Reject — The Splynx server received the Radius Access-Request packet from Router and Radius Access-Reject was sent back. Customer was not authenticated;
• Reject (Attribute accept) — The Splynx server sent the Radius Access-Accept packet to Router with the IP address from the Splynx service. Customer was authenticated on the router with a session time limit = Config → Networking → Radius → Error session time limit. IP address was added into the Address list Reject_x on the router;
• Reject (ATTR + IP accept) — The Splynx server sent the Radius Access-Accept packet to the Router with an IP address from the Splynx Reject pool (Config → Networking → Radius → Reject IP x). Customer was authenticated on the router with session time limit = Config → Networking → Radius → Error session time limit. IP address was added into the Address list Reject_x on the router;
• [card] Accept — The same as Accept but for Prepaid vouchers.
• [card] Log in — The same as Log in but for Prepaid vouchers.
• [card] Log off — The same as Log out but for Prepaid vouchers.
• Reject card — The same as Reject but for Prepaid vouchers.

In the case of authentication errors or logging off, the reasons are shown in the radius logs under Administration → Logs → Files → radius/short as well as in the customer statistics under sessions (enable the «Termination cause» column).

NOTE: Disconnection reasons in the short.log like Admin-reset or Lost-carrier are not related to Splynx and should be investigated on the network.

In the coa.log you can find records that can help you with troubleshooting of issues with disconnection, plan change etc. If Splynx sends a CoA packet, it will be logged here:

2021-10-07 07:15:02 - echo "User-Name = mike, Framed-IP-Address = 192.168.200.218, NAS-IP-Address = 10.250.32.3" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 disconnect "9734c51bb208" > /dev/null &
2021-10-07 07:15:49 - echo "User-Name = mike, Framed-IP-Address = 192.168.200.28, NAS-IP-Address = 10.250.32.3" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 disconnect "9734c51bb208" > /dev/null &
2021-10-07 07:20:10 - echo "User-Name = mike,Framed-IP-Address = 192.168.200.108,  NAS-IP-Address = 10.250.32.3 , Mikrotik-Rate-Limit = "5000000/5000000 0/0 0/0 0/0 5 5000000/5000000"" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 coa "9734c51bb208" > /dev/null &
2021-10-07 07:32:46 - echo "User-Name = mike, Framed-IP-Address = 192.168.200.137, NAS-IP-Address = 10.250.32.3" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 disconnect "9734c51bb208" > /dev/null &
2021-10-07 07:45:37 - echo "User-Name = mike, Framed-IP-Address = 192.168.200.5, NAS-IP-Address = 10.250.32.3" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 disconnect "9734c51bb208" > /dev/null &
2021-10-07 11:45:10 - echo "User-Name = mike,Framed-IP-Address = 192.168.200.5,  NAS-IP-Address = 10.250.32.3 , Mikrotik-Rate-Limit = "10000000/10000000 0/0 0/0 0/0 5 1000000/1000000"" | /usr/bin/sudo /usr/bin/radclient 10.250.32.3:3799 coa "9734c51bb208" > /dev/null &

In this part of the coa.log you can see that Splynx has sent some CoA packets to disconnect a user and change the speed of the connection.

The Splynx Radius server consist of 2 services: splynx_radd and freeradius. Both of them have different debugging procedures and show different information. Let’s start with the splynx_radd debug:

To enable debug mode for splynx_radd, navigate to Config → Networking → Radius advanced and enable debug (change the level of debug to get more or less detail in the log):

Apply new settings immediately by saving and restarting the Radius server.
To restart Radius server use the button at the bottom of the same page (Config → Networking → Radius advanced), or enter command in SSH:

service splynx_radd restart

Now we can check the debug file. It is also accessible from the CLI of Linux Splynx server:
/var/www/splynx/logs/radius/debug.log
The best way to check the file is by using the tail command:

tail -f /var/www/splynx/logs/radius/debug.log

Once the debug is completed, remember to switch the debug off the same way it was switched on, save and restart the radius server again. (To avoid massive radius rebug files forming)

If splynx_radd debug doesn’t show us the desired results, we can also run freeradius daemon in debug mode and see if any packets are received by Radius server.

Run CLI commands to get output into the file:

service freeradius stop && freeradius -Xxxx | tee Debugxxx.log

Wait for 2-5 minutes to collect some data and stop execution of this command by using Ctrl+C and start freeradius in a regular mode:

service freeradius start

If the freeradius daemon returns an error after the last command run this:

killall freeradius; service freeradius restart

If you don’t see any debug messages when a customer tries to connect to the Mikrotik Router, it means that your router’s radius packets are not reaching the Splynx Radius server at all. You need to verify networking, routing and NAT settings of the network.

The use of a VPN in any case where connectivity or NATting is an issue is highly recommended and can be setup natively in Splynx via the GUI:

Our guide on OpenVPN and OpenVPN client / Routes

On the Mikrotik Router there is also the ability to run extended debug to see exactly what the router is sending to the Radius server:

For more information on how RADIUS works, please visit Radius Wikipedia or FreeRADIUS Wiki