1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Annoying Log Error with Shibby v112

Discussion in 'Tomato Firmware' started by Almaz, Oct 16, 2013.

  1. Almaz

    Almaz Serious Server Member

    I'm getting an error in the log after heavy usage in CPU. A heavy usage means downloading multiple torrents using transmission daemon and moving files from router NAS to another network drive. Even with errors my OpenVPN server works fine. The errors showing up, when I don't even use OpenVPN at that time. I'm using E3000 with Shibby 112 BtVpn. Just a guess, since I'm using a common port 443, is it possible, it picks up a wrong signal and it forcing to reset?

    Here are the errors:
    Code:
    Oct 16 17:14:33 daemon.err openvpn[1033]: 192.168.3.2:49757 Connection reset, restarting [0]
    Oct 16 17:14:33 daemon.notice openvpn[1033]: 192.168.3.2:49757 SIGUSR1[soft,connection-reset] received, client-instance restarting
    Oct 16 17:14:33 daemon.notice openvpn[1033]: TCP connection established with [AF_INET]192.168.3.2:49758
    Oct 16 17:14:33 daemon.warn openvpn[1033]: 192.168.3.2:49758 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1556 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
    Oct 16 17:14:33 daemon.err openvpn[1033]: 192.168.3.2:49758 Connection reset, restarting [0]
    Oct 16 17:14:33 daemon.notice openvpn[1033]: 192.168.3.2:49758 SIGUSR1[soft,connection-reset] received, client-instance restarting
    Oct 16 17:14:33 daemon.notice openvpn[1033]: TCP connection established with [AF_INET]192.168.3.2:49759
    Oct 16 17:14:33 daemon.warn openvpn[1033]: 192.168.3.2:49759 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1556 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
    Oct 16 17:14:33 daemon.err openvpn[1033]: 192.168.3.2:49759 Connection reset, restarting [0]
    Oct 16 17:14:33 daemon.notice openvpn[1033]: 192.168.3.2:49759 SIGUSR1[soft,connection-reset] received, client-instance restarting
    My OpenVPN Server Settings:
    Code:
    cat config.ovpn
    # Automatically generated configuration
    daemon
    server-bridge
    proto tcp-server
    port 443
    dev tap21
    cipher RC2-40-CBC
    comp-lzo adaptive
    keepalive 15 60
    verb 3
    push "route-gateway 192.168.3.1"
    push "redirect-gateway def1"
    ca ca.crt
    dh dh.pem
    cert server.crt
    key server.key
    status-version 2
    status status
    
    # Custom Configuration
    push "dhcp-option DNS 192.168.3.1"
    server-bridge 192.168.3.1 255.255.255.0 192.168.3.15 192.168.3.15
    auth none
    tun-mtu 1500
    
     
    Last edited: Oct 17, 2013
  2. koitsu

    koitsu Network Guru Member

    You need to provide the OpenVPN configuration of both ends of the connection -- meaning on your router running Shibby v112, as well as on the VPN providers' end (ask them for it). You also need to disclose if you are using PPPoE or PPPoA as well (it matters).

    Most likely you will need to work with your VPN provider to troubleshoot and solve this issue.

    I cannot help past this point.
     
  3. Almaz

    Almaz Serious Server Member

    When I received these errors I was not connected thru OpenVPN at all. I only use OpenVPN to connect my cell phone to my router or I connect from work to my router. The router works in Wireless Client Mode. Here is another log and I forgot to mention ports are increasing.

    Code:
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: TCP connection established with [AF_INET]192.168.3.2:56055
    Oct 17 03:21:44 Almaz daemon.warn openvpn[1100]: 192.168.3.2:56055 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1556 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
    Oct 17 03:21:44 Almaz daemon.err openvpn[1100]: 192.168.3.2:56055 Connection reset, restarting [0]
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: 192.168.3.2:56055 SIGUSR1[soft,connection-reset] received, client-instance restarting
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: TCP connection established with [AF_INET]192.168.3.2:56056
    Oct 17 03:21:44 Almaz daemon.warn openvpn[1100]: 192.168.3.2:56056 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1556 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
    Oct 17 03:21:44 Almaz daemon.err openvpn[1100]: 192.168.3.2:56056 Connection reset, restarting [0]
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: 192.168.3.2:56056 SIGUSR1[soft,connection-reset] received, client-instance restarting
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: TCP connection established with [AF_INET]192.168.3.2:56057
    Oct 17 03:21:44 Almaz daemon.warn openvpn[1100]: 192.168.3.2:56057 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1556 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
    Oct 17 03:21:44 Almaz daemon.err openvpn[1100]: 192.168.3.2:56057 Connection reset, restarting [0]
    Oct 17 03:21:44 Almaz daemon.notice openvpn[1100]: 192.168.3.2:56057 SIGUSR1[soft,connection-reset] received, client-instance restarting
     
    Last edited: Oct 17, 2013
  4. Almaz

    Almaz Serious Server Member

    I just checked the log again and it looks Tomato OpenVPN server keeps scanning every single port to every computer in the network. Why is it trying to establish connection with other computers in the subnet when it should act as a server?
     
  5. kthaddock

    kthaddock Network Guru Member

    --tun-mtu or --link-mtu is equal on both peers. "tun-mtu 1500"
    Have you same MTU on both sides ?
     
  6. Almaz

    Almaz Serious Server Member

    I have the same settings tun-mtu 1500 but the error shows up when I don't use OpenVpn at all. OpenVPN server started on the router but no one connected to it. I'm just getting these errors in the log file for no reason and I can't figure it out why.
     
  7. kthaddock

    kthaddock Network Guru Member

    Try to use this and se if that helps, on both sides:
    --tun-mtu 1500
    --fragment 1300
    --mssfix


    Hmm do you use jumbo frames ?
     
    Last edited: Oct 17, 2013
  8. Almaz

    Almaz Serious Server Member

    Guys the problem is not with OpenVPN connection, the problem with an error showing up in the log file even if I don't use OpenVPN at all. I'm guessing it's OpenVPN bug or another bug. Is anyone else having these errors using Shibby 112 with OpenVPN server enabled?
     
  9. koitsu

    koitsu Network Guru Member

    Let me explain something clearly:

    The openvpn daemon (client or server -- doesn't matter) runs no matter if you're shoving packets across it or not.

    The client and server also both keep the connection up and do send little packets across back and forth on occasion (I use the word "little" loosely here, don't take me literally).

    It looks like that on occasion the packets going back/forth between you and your VPN provider (read what I just said) get munged due to what appears to be an MTU mismatch of sorts. Like I said, the only way to find out what's on the server side (their side) is to talk to them. They should be able to help you work out what the issue is.

    This is nonsense and isn't what's indicated in your logs at all. The source port number incrementing that you see (56055, 56056, 56057, etc.) is normal -- it's happening because when SIGUSR1 is received (the daemon experiencing said anomaly we're talking about, re: MTU mismatch), the socket disconnects/closes and a new socket is allocated/connected. That's just how it works. There is no "port scanning" going on.

    If you have other logs that do indicate "port scanning" is going on "to every computer in the network", then show those logs/show that evidence. But it has nothing to do with the log messages you've shown so far.
     
  10. Almaz

    Almaz Serious Server Member

    Thank you Koitsu. I'm using portable OpenVPN client and I don't know if that's a problem or not but when I connect to my router via OpenVPN then I do get an error saying my MTU mismatch even though I have tun-mtu 1500 on both sides, server & client. Just a note my OpenVPN works fine. As you can see from my first post server config.ovpn. I tried to use tun-mtu 1500 and --tun-mtu 1500 but the same problem. Any suggestions?
     
    Last edited: Oct 18, 2013
  11. koitsu

    koitsu Network Guru Member

    As I said earlier:

     
  12. Almaz

    Almaz Serious Server Member

    I do not use PPP connection, it's all DHCP by Comcast

    Client Config.ovpn

    Code:
    client
    dev tap
    proto tcp
    remote x:x:x:x 443
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ns-cert-type server
    comp-lzo adaptive
    verb 5
    tun-mtu 1500
    mssfix
    cipher RC2-40-CBC
    auth none
     
    Last edited: Oct 18, 2013
  13. koitsu

    koitsu Network Guru Member

    Then the issue may be on your VPN providers end, or somewhere in between.

    I would suggest lowering the tun-mtu to 1472 as long as you have full control over both ends of the connection (i.e. VPN client and VPN server). The 1472 value is "magical" in a way (look up "mtu 1472" online and learn about TCP/IP to learn how it's calculated).

    Otherwise there is really nothing you can do about it.
     
  14. RMerlin

    RMerlin Network Guru Member

    I bet you are getting these errors because you use port 443, and there are a lot of spiders who will attempt to connect to that port, resulting in the OpenVPN server getting garbage in.
     
    Kye-U likes this.
  15. bhall7

    bhall7 Addicted to LI Member

    I also have this problem whenever I try to connect to my OpenVPN server (ASUS RT-AC66U, running Asuswrt-Merlin) from behind my company's firewall through a proxy server. I can connect just fine from other locations, but something about the proxy server mangles the packets. It's strange because it didn't used to do this.
     

Share This Page