Weird log entries

ghostp

Today I switched to a new ISP. Everything seem to look great, I can connect to air, there are no dns leaks etc. BUT there are hundrets of weird entries in the logs like below:

. 2015.04.22 16:07:51 - OpenVPN > Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2843 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
. 2015.04.22 16:07:51 - OpenVPN > Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2844 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
. 2015.04.22 16:07:51 - OpenVPN > Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2845 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

.

Any idea what's going on???

AirVPN_20150422_161049.txt

go558a83nk

hmmm...nothing else changed in your AirVPN setup?

I'm thinking a packet fragmentation problem with the new ISP

ghostp

hmmm...nothing else changed in your AirVPN setup?

I'm thinking a packet fragmentation problem with the new ISP

Nope, I did not change anything, even my modem/router is the same. What do you think, might it be something I should concern about?

Staff

hmmm...nothing else changed in your AirVPN setup?

I'm thinking a packet fragmentation problem with the new ISP

Nope, I did not change anything, even my modem/router is the same. What do you think, might it be something I should concern about?

@ghostp

Hello,

at the moment it's difficult to say something. It could be just a momentary line problem, go on checking in the next hours or even days. As a generic suggestion, if your system is connected via WiFi, try to get the strongest signal. If it is connected via Ethernet, try to replace the cable.

The following post talks about the log lines you get and replay attacks:

https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784

Kind regards

ghostp

hmmm...nothing else changed in your AirVPN setup?

I'm thinking a packet fragmentation problem with the new ISP

Nope, I did not change anything, even my modem/router is the same. What do you think, might it be something I should concern about?

@ghostp

Hello,

at the moment it's difficult to say something. It could be just a momentary line problem, go on checking in the next hours or even days. As a generic suggestion, if your system is connected via WiFi, try to get the strongest signal. If it is connected via Ethernet, try to replace the cable.

The following post talks about the log lines you get and replay attacks:
https://www_de.airvpn.org/topic/3773-pls-help-strange-logs/#entry3784

Kind regards

Hello,

I already have a very strong WiFi Connection (5GHz). I think It is not neccessary to change it because without VPN I get 100% of my bandwith. The problem seem occur if I'm connecting with Protocol in Automatic mode. I actually don't know which protocoll air is picking. The only way it seem to work at its best is connecting via SSL 443 protocol. If do so there is no packet lost at all. But anyway I don't know why I don't get full speed.

1) I've connected to several servers via the protocol "Automatic Mode". The result was very slow connection, lots of packet losts, etc. Automatic_mode.zip

2) I've connected to several servers via the protocol "SSL 443". Best results, no packet lost, better download speed

Viriginis_SSL443.zip

Menkib_SSL443.zip

Botein_SSL443.zip

3) I've connected to several servers via the protocol "SSH 22". Speed test on airvpn.org was not possible (I don't know why), pingtest bad and high jitter. Speedtest better but no packet lost.

SSH22.zip

As you can also see the upload is always full speed. The download very bad.

Do you have a better Idea now what's going on?

Staff

Hello @ghostp !

1) The Automatic mode in Eddie at the moment always picks protocol UDP, port 443

2) You can't get the mentioned logs entries when OpenVPN works in TCP because a first error correction is performed at TCP transport layer. See the already linked messages for more insights about that. Note that when over SSL or SSH, OpenVPN must work in TCP (stunnel and ssh do not and can not support UDP)

3) The fact that you don't experience packet loss without VPN is interesting. Two possible explanations: either you are not detecting correctly packet loss (how did you verify that?) or you are really subjected to replay attacks - in which case OpenVPN is doing its job correctly, in UDP. In the latter case, the fact that you get packet authentication failures with every and each VPN server in several different datacenters would seem to imply that the replay attack is performed in some point inside your ISP network (it's possible: injecting forged packets is not rocket science once someone is in your same network). It would be an attack specifically aimed against you. In this case, when you don't use VPN and you don't use end-to-end encryption and authentication, the attack would succeed, but it could be hard (if not impossible) for you to recognize forged injected packets.

Kind regards

ghostp

(how did you verify that?)

I did a test on pingtest.net and it shows me the packet losses.

seem to imply that the replay attack is performed in some point inside your ISP network (it's possible: injecting forged packets is not rocket science once someone is in your same network). It would be an attack specifically aimed against you. In this case, when you don't use VPN and you don't use end-to-end encryption and authentication, the attack would succeed, but it could be hard (if not impossible) for you to recognize forged injected packets.

That is scary me. Does it mean my ISP is attacking me??

I ran couple of tests again and I've noticed something strange. Here is what I've noticed:

1) I'm connecting to airvpn with the "Automatic mode" and everything ist normal. I've waited couple of minutes and the connection seem to be stable. BUT as soon I open any browser (Firefox, chrome, IE etc.) and start to browse somewhere, the log entries appear in the logfile. For example, I open youtube, everything is ok, than I start playing any video, the entries appear. Than I do nothing couple of minutes and everything is ok. Than I browse to another website and the entries appear again and again. Than I close the browser and no additional entries appear. Than after another 15 minutes I open the browser and go to perform a speedtest on speedtest.net, then additional entries come back again. In consequense the speedtest is very bad (70% speed down).

Another weird thing is, that I also can't connect for instanse to skype. Hmm, weird! BUT as soon I connect with SSL 443, every problem above dissapear. I also contacted my ISP again and told them that I'm thinking that there might be some reply attacks from my ISP. The men than start to lough and asked me why they would do this? So, I don't think that they are attacking me.

I'm very confused now! Do you think there is a logic explanation or any idea how to get rid of it?

I tried to read about the reply attacks but honestly my technican knowhow is way to bad to understand what is really happening.

Staff

Hello!

A replay attack can come from someone inside the ISP network, not necessarily by the ISP personnel or network configuration.

There's nothing to laugh about, if they do it again tell them that even giant ISPs like Comcast inject packets for marketing purposes or any other reason:

https://www.techdirt.com/articles/20140908/07191228453/comcast-using-packet-injection-to-push-its-own-ads-via-wifi-apparently-oblivious-to-security-concerns.shtml

The problem with many ISPs attacking their own customers with packet injection began at least EIGHT years ago:

https://www.eff.org/wp/detecting-packet-injection

so the person who laughed when you reported your case has provided a strong proof of his/her utter incompetence.

Description you provide in point 1 is interesting. If it was packet injection attempt you would exactly experience that. What is your ISP (don't tell if you don't wish so)?

Kind regards

ghostp

Hello!

A replay attack can come from someone inside the ISP network, not necessarily by the ISP personnel or network configuration.

There's nothing to laugh about, if they do it again tell them that even giant ISPs like Comcast inject packets for marketing purposes or any other reason:

https://www.techdirt.com/articles/20140908/07191228453/comcast-using-packet-injection-to-push-its-own-ads-via-wifi-apparently-oblivious-to-security-concerns.shtml

The problem with many ISPs attacking their own customers with packet injection began at least EIGHT years ago:
https://www.eff.org/wp/detecting-packet-injection

so the person who laughed when you reported your case has provided a strong proof of his/her utter incompetence.

Description you provide in point 1 is interesting. If it was packet injection attempt you would exactly experience that. What is your ISP (don't tell if you don't wish so)?

Kind regards

I cumulated all information together and wrote to my ISP. I'm curious what answer will I get

1) Nevertheless could you tell me if these "replay attacks" are harmless or could they serious damage my Computer or could there someone get access to my personal information like bank account?

2) The links you've provided are very interesting on the one side but on the other the way to detect/proof replay attacks from ISP are VERY complicated :-(((( Is there any easier way to detect/monitor/proof these kind of attacks????

3) How about Anti-Virus, Anti-Spy, Anti-Malware programs, are they able to detect something like this???

4) In generally what can I do to get rid of these attacks?

Staff

Hello!

1) Packets injection by ISPs normally have the only purpose to force advertisements to you. More sinister purposes could be sought by different entities. https://en.wikipedia.org/wiki/Packet_injection

2) Unfortunately not. It is not trivial to prove packet injection.

3) We leave answers to this questions to software developers.

4) OpenVPN is extremely resistant to replay attacks and it can be used whenever end-to-end validation and encryption is not available. Otherwise, end-to-end encryption and validation normally makes replay attacks impossible to succeed. With OpenVPN, you can add (as already written both by you and us) an additional security layer, i.e. using OpenVPN with TCP as transport layer (see also the manual piece quoted here: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 ).

Kind regards

ghostp

Hello!

1) Packets injection by ISPs normally have the only purpose to force advertisements to you. More sinister purposes could be sought by different entities. https://en.wikipedia.org/wiki/Packet_injection

2) Unfortunately not. It is not trivial to prove packet injection.

3) We leave answers to this questions to software developers.

4) OpenVPN is extremely resistant to replay attacks and it can be used whenever end-to-end validation and encryption is not available. Otherwise, end-to-end encryption and validation normally makes replay attacks impossible to succeed. With OpenVPN, you can add (as already written both by you and us) an additional security layer, i.e. using OpenVPN with TCP as transport layer (see also the manual piece quoted here: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 ).

Kind regards

I have an update in this case. I've confronted my ISP with this problem and had a chat with a high positioned technican. He immediately knew what I was talking about and he assured that my ISP does not do things like that. He also assured that the don't block any ports, services ect. But he said I could try to "Increase the MTU to 1.000 in openvpn". The hell I don't know what he was talking about! Anyway I wanted to share it with you air-team and wanted to know what are you thinking about it? At least if you also think it is a good idea to increase the MTU, how can I do it????

Staff

Hello!

1) Packets injection by ISPs normally have the only purpose to force advertisements to you. More sinister purposes could be sought by different entities. https://en.wikipedia.org/wiki/Packet_injection

2) Unfortunately not. It is not trivial to prove packet injection.

3) We leave answers to this questions to software developers.

4) OpenVPN is extremely resistant to replay attacks and it can be used whenever end-to-end validation and encryption is not available. Otherwise, end-to-end encryption and validation normally makes replay attacks impossible to succeed. With OpenVPN, you can add (as already written both by you and us) an additional security layer, i.e. using OpenVPN with TCP as transport layer (see also the manual piece quoted here: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 ).

Kind regards

I have an update in this case. I've confronted my ISP with this problem and had a chat with a high positioned technican. He immediately knew what I was talking about and he assured that my ISP does not do things like that. He also assured that the don't block any ports, services ect. But he said I could try to "Increase the MTU to 1.000 in openvpn". The hell I don't know what he was talking about! Anyway I wanted to share it with you air-team and wanted to know what are you thinking about it? At least if you also think it is a good idea to increase the MTU, how can I do it????

Hello!

MTU: https://en.wikipedia.org/wiki/Maximum_transmission_unit

Our OpenVPN servers have a default setting of 1500 so the technician meant to decrease it, not increase it. You can't change MTU size on the client size only (this size must match on both parties), so that's not an option. You can however operate with "mssfix" (for TCP wrapped in the tunnel) and/or "fragment" (for UDP) directives to handle MTU size problems.

You can add custom directives in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives". For example:

fragment 1400

Then click "Save" and restart a VPN connection. See below an extract from the OpenVPN manual.

This thread can help:

https://airvpn.org/topic/9773-receiving-packets-larger-than-1500-bytes/?do=findComment&comment=11446

Kind regards

From OpenVPN manual:

--fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

--fragment adds 4 bytes of overhead per datagram.

See the --mssfix option below for an important related option to --fragment.

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

--mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

--tun-mtu 1500 --fragment 1300 --mssfix

ghostp

I've tried with several settings but with all settings the connection was not established :-( See the abstract below:

...
. 2015.05.06 13:18:47 - Starting Management Interface
. 2015.05.06 13:18:47 - OpenVPN > Initialization Sequence Completed
I 2015.05.06 13:18:47 - Flushing DNS
I 2015.05.06 13:18:47 - Checking route
W 2015.05.06 13:18:57 - Checking route, 1° try failed
W 2015.05.06 13:19:07 - Checking route, 2° try failed
W 2015.05.06 13:19:17 - Checking route, 3° try failed
W 2015.05.06 13:19:27 - Checking route, 4° try failed
W 2015.05.06 13:19:37 - Checking route, 5° try failed
W 2015.05.06 13:19:37 - Timeout

Staff

Hello,

try to test again with routes check disabled: untick "Check if the tunnel effectively works" in client menu "AirVPN" -> "Preferences" -> "Advanced" and click "Save". Try a new connection and if it is established browse to airvpn.org. Verify whether the central bottom box is green or red.

Do the above both with no custom directives and with the following directives:

fragment 1400

mssfix

to see whether there's any difference.

Kind regards

ghostp

I did exactly this above and it didn't work. I can see that a connection is established but I there is no internet anymore, I mean in the browser I can't browse to anywhere. There appear some lines like "OpenVPN > FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented" in openvpn. See the logfile below:

I 2015.05.06 19:47:25 - Session starting.
I 2015.05.06 19:47:25 - Installing tunnel driver
I 2015.05.06 19:47:25 - DNS of a network adapter forced (Qualcomm Atheros AR946x Wireless Network Adapter)
I 2015.05.06 19:47:26 - Checking authorization ...
! 2015.05.06 19:47:26 - Connecting to Botein (Netherlands, Amsterdam)
. 2015.05.06 19:47:26 - OpenVPN > OpenVPN 2.3.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Jan 12 2015
. 2015.05.06 19:47:26 - OpenVPN > library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
. 2015.05.06 19:47:26 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2015.05.06 19:47:26 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2015.05.06 19:47:26 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2015.05.06 19:47:26 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2015.05.06 19:47:26 - OpenVPN > Socket Buffers: R=[65536->65536] S=[65536->65536]
. 2015.05.06 19:47:26 - OpenVPN > UDPv4 link local: [undef]
. 2015.05.06 19:47:26 - OpenVPN > UDPv4 link remote: [AF_INET]37.48.74.15:443
. 2015.05.06 19:47:26 - OpenVPN > TLS: Initial packet from [AF_INET]37.48.74.15:443, sid=281066a2 0f693110
. 2015.05.06 19:47:27 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2015.05.06 19:47:27 - OpenVPN > Validating certificate key usage
. 2015.05.06 19:47:27 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0
. 2015.05.06 19:47:27 - OpenVPN > VERIFY KU OK
. 2015.05.06 19:47:27 - OpenVPN > Validating certificate extended key usage
. 2015.05.06 19:47:27 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2015.05.06 19:47:27 - OpenVPN > VERIFY EKU OK
. 2015.05.06 19:47:27 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2015.05.06 19:47:30 - OpenVPN > WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1562', remote='link-mtu 1558'
. 2015.05.06 19:47:30 - OpenVPN > WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'
. 2015.05.06 19:47:30 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2015.05.06 19:47:30 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2015.05.06 19:47:30 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2015.05.06 19:47:30 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2015.05.06 19:47:30 - OpenVPN > Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
. 2015.05.06 19:47:30 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]37.48.74.15:443
. 2015.05.06 19:47:33 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2015.05.06 19:47:33 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.1.245 255.255.0.0'
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: route options modified
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2015.05.06 19:47:33 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2015.05.06 19:47:33 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2015.05.06 19:47:33 - OpenVPN > open_tun, tt->ipv6=0
. 2015.05.06 19:47:33 - OpenVPN > TAP-WIN32 device [LAN-Verbindung] opened: \\.\Global\{9177F3DF-D2F7-432D-90C0-9E13F6A18897}.tap
. 2015.05.06 19:47:33 - OpenVPN > TAP-Windows Driver Version 9.21
. 2015.05.06 19:47:33 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.4.0.0/10.4.1.245/255.255.0.0 [sUCCEEDED]
. 2015.05.06 19:47:33 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.4.1.245/255.255.0.0 on interface {9177F3DF-D2F7-432D-90C0-9E13F6A18897} [DHCP-serv: 10.4.255.254, lease-time: 31536000]
. 2015.05.06 19:47:33 - OpenVPN > Successful ARP Flush on interface [13] {9177F3DF-D2F7-432D-90C0-9E13F6A18897}
. 2015.05.06 19:47:38 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2015.05.06 19:47:38 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 37.48.74.15 MASK 255.255.255.255 192.168.178.1
. 2015.05.06 19:47:38 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: Das Objekt ist bereits vorhanden. [status=5010 if_index=2]
. 2015.05.06 19:47:38 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2015.05.06 19:47:38 - OpenVPN > Route addition fallback to route.exe
. 2015.05.06 19:47:38 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2015.05.06 19:47:38 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 192.168.178.1 MASK 255.255.255.255 192.168.178.1 IF 2
. 2015.05.06 19:47:38 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
. 2015.05.06 19:47:38 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2015.05.06 19:47:38 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.4.0.1
. 2015.05.06 19:47:38 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
. 2015.05.06 19:47:38 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2015.05.06 19:47:38 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.4.0.1
. 2015.05.06 19:47:38 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
. 2015.05.06 19:47:38 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2015.05.06 19:47:38 - Starting Management Interface
. 2015.05.06 19:47:38 - OpenVPN > Initialization Sequence Completed
I 2015.05.06 19:47:38 - Flushing DNS
! 2015.05.06 19:47:38 - Connected.
. 2015.05.06 19:47:38 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2015.05.06 19:47:38 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
. 2015.05.06 19:47:43 - OpenVPN > FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
. 2015.05.06 19:47:53 - OpenVPN > FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
. 2015.05.06 19:48:03 - OpenVPN > FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
! 2015.05.06 19:48:06 - Disconnecting
. 2015.05.06 19:48:06 - Management - Send 'signal SIGTERM'
. 2015.05.06 19:48:06 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2015.05.06 19:48:06 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2015.05.06 19:48:11 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 37.48.74.15 MASK 255.255.255.255 192.168.178.1
. 2015.05.06 19:48:11 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2015.05.06 19:48:11 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 192.168.178.1 MASK 255.255.255.255 192.168.178.1
. 2015.05.06 19:48:11 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2015.05.06 19:48:11 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.4.0.1
. 2015.05.06 19:48:11 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2015.05.06 19:48:11 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.4.0.1
. 2015.05.06 19:48:11 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2015.05.06 19:48:11 - OpenVPN > Closing TUN/TAP interface
. 2015.05.06 19:48:11 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2015.05.06 19:48:11 - Connection terminated.
I 2015.05.06 19:48:12 - DNS of a network adapter restored to original settings (Qualcomm Atheros AR946x Wireless Network Adapter)
! 2015.05.06 19:48:12 - Session terminated.

Staff

Hello,

sorry for the mistake, "fragment" needs to be implemented on server side too, therefore it is not a viable option. Operate only with mssfix (start for example with "mssfix 1400" then lower the value progressively at steps of 50 if necessary).

Kind regards

go558a83nk

You could also try forcing the kernel (not openvpn) to adjust the packet size by disabling mssfix with "mssfix 0" in case the other options don't work.

what operating system does the OP use?

ghostp

Hello,

sorry for the mistake, "fragment" needs to be implemented on server side too, therefore it is not a viable option. Operate only with mssfix (start for example with "mssfix 1400" then lower the value progressively at steps of 50 if necessary).

Kind regards

You won't believe it but IT FINALLY WORKED :-D I just tried with "mssfix 1400" and it worked! I also tried anothother values (1500, 1450, etc.) but it works only with 1400. I'm so happy now! Finally I also compared the connection via SSL and there seem not to be any performance hit at all, neither over SSL nor Automatic mode. I run some speed test here and on speedtest.net, pingtest.net. So, if there is no noticable performance hit between UDP and SSL, is it better then to go with SSL connection? I've read this is something like an additional security layer, right?

But anyway THANK YOU GUYS!!! :-)

Staff

Hello,

sorry for the mistake, "fragment" needs to be implemented on server side too, therefore it is not a viable option. Operate only with mssfix (start for example with "mssfix 1400" then lower the value progressively at steps of 50 if necessary).

Kind regards

You won't believe it but IT FINALLY WORKED :-D I just tried with "mssfix 1400" and it worked! I also tried anothother values (1500, 1450, etc.) but it works only with 1400. I'm so happy now! Finally I also compared the connection via SSL and there seem not to be any performance hit at all, neither over SSL nor Automatic mode. I run some speed test here and on speedtest.net, pingtest.net. So, if there is no noticable performance hit between UDP and SSL, is it better then to go with SSL connection? I've read this is something like an additional security layer, right?

But anyway THANK YOU GUYS!!! :-)

Hello!

Very well!

About OpenVPN over SSL, use it only if you wish (or need) to hide to your ISP the OpenVPN fingerprint, for example when detection of OpenVPN causes traffic shaping. Otherwise you don't need it, because it hits performance and does not add a significant security layer.

If you need to strengthen effectively the anonymity layer for specific purposes, you should evaluate to use Tor after you have connected to the VPN (Tor over OpenVPN).

Kind regards

Weird log entries

Recommended Posts

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Join the conversation