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

TomatoVPN connection slow / freezes

Discussion in 'Tomato Firmware' started by Jimson, Apr 23, 2010.

  1. Jimson

    Jimson Networkin' Nut Member

    Hey everyone,

    sorry for starting off posting in this forum with a question. But I'm kind of in a horrible situation :eek:

    I've been using TomatoVPN for a few months now and never had a problem connecting to my home network.
    This is the configuration file I use on my Windows OpenVPN client:
    remote ...
    port ...
    dev tap
    secret static.key
    proto udp
    And here's the problem: I've left the country working for my employer. I currently access the Internet using a DSL connection. Now, when I connect to my VPN server at home (which works), the connection is really slow and sometimes freezes. Pings through the VPN are ok, but bandwidth isn't. If I, for example, try to open two web pages at the same time, I have to wait for ages.

    I've spent a few hours googling and to me it seems, it's some kind of MTU problem. But I'm really new to all this (it used to work, so I never had to learn much about it) and I'm scared to just start off and change settings. Because I will have to hang myself if I screw up the possibility to connect at all. :wink: Slow connection is better than no connection, you know :rolleyes:

    So I know I didn't provide enough information for you to be able to help me. So please just ask and I will get anything you need, as I just don't know what that might be :)
    Oh, another hint, don't know if that helps: 'mtu-test' entered as the last line of the above config file doesn't work, even if I tell Tomato to answer ICMP pings.

    Thanks for any help, really. I need my private files...
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Unfortunately, OpenVPN has to be compiled with certain options to include mtu-test. Your version must not have enabled that.

    Fortunately, though, you can emulate the behavior yourself. With your link active, keep issuing the ping command with varying sizes (-l option on Windows) to find out what the maximum usable packet size is on your connection.

    Once you determine a value, try adding the following (with varying values at or below the number you discovered above):
    fragment 1300
    With any luck, this should solve your problem, if it is indeed MTU related.
  3. Jimson

    Jimson Networkin' Nut Member

    Thanks for your reply!

    Let me tell you guys what I tried, because I'm not sure I did what you meant me to do:

    I enabled my VPN connection and then pinged google.com through it using
    ping -l 14xx -f
    The highest number not saying something like "should be fragmented" (or whatever it says in English) was 1424.

    When I tried adding
    fragment 1424
    to my config, I could not reach any of my network's hosts and got the following message in my logfile a few times:
    read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)

    Thanks again! I really appreciate help this time more then ever. Can't imagine working here for months without having access to my precious network :chuckle:
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Actually, I just meant pinging the VPN server router's LAN address. I meant to mention that before, sorry. :redface:

    Try using a number like 1300 (or 1200). If that works, and you care to, you can try increasing it until things don't work.
  5. Jimson

    Jimson Networkin' Nut Member

    Ok, got it.
    Tried it again and found the MTU of 1472 to be the last one that doesn't show that 'I should have been fragmented'-message.

    No matter what I try, 1472 or 1200, I can't reach my local hosts and get the following entries in my log file:
    Fri Apr 23 21:30:36 2010 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
    Fri Apr 23 21:30:37 2010 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
    Fri Apr 23 21:30:37 2010 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
    When using 1200, I only had the above entry once. With 1472 three times.

    Anything else you could possibly think of that's causing this?
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I'm afraid I'd just be guessing from here. A few things to try:
    1. The example in the OpenVPN documentation uses the following numbers for MTU stuff:
      tun-mtu 1500
      fragment 1300
    2. Try TCP instead of UDP.
    3. Try TUN instead of TAP.
  7. Jimson

    Jimson Networkin' Nut Member

    I have already tried the example configuration described. That lead to the same error message.

    Changing the protocol or device type really scares me. As soon as I change one of both, Tomato offers different menu entries which I don't know what to set to. Worst case scenario really is not being able to connect to the VPN anymore, as you can probably guess :)
    Should I be scared? Or is that a pretty straightfordward thing to do?
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    TCP vs UDP is really a drop-in replacement. None of the menus change based on that.

    Try that one first, and we'll only worry about TAP vs TUN if it doesn't fix it. It's also not that big of a deal for use-case, but, as you mention, there are a couple of different options.

    If you're really worried about losing access, you could make your router admin pages accessible via the WAN. If you add your current IP address (or better an dynamic DNS name you can change at will) to "Access restricted to", then nobody but you will be able to access it. Then, if the tunnel chokes for some reason (shouldn't), you can still change it back.
  9. Jimson

    Jimson Networkin' Nut Member

    Oh yeah, you're right. Didn't think of that. That would be a great way to keep access.

    I will write back as soon as I tried TCP!
  10. Jimson

    Jimson Networkin' Nut Member

    After I was too scared, I finally tried TCP instead of UDP, but that didn't change anything.
    What I did see, though, was this entry in my router's log:
    Data Channel MTU parms [ L:1577 D:1450 EF:45 EB:135 ET:32 EL:0 AF:3/1 ]
    Does this help somehow? I'm still not completely over the whole MTU thing, as you may see :)

    Another thing I noticed is, that sometimes the connection is really fast (router's web interface responds nearly as if I was there) while other times (for example if I open internet pages or sometimes just after the VPN connection has been up for some time) it just freezes, not transfering a simple 1kb txt file forever.

    Thanks again... This place really gives me some hope after reading through 50+ archived threads!
  11. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    On the MTU front, you may want to look here. There are a couple of suggestions, including needing to put the fragment command on both ends of the tunnel.

    If you're ready to try TUN instead of TAP (unless you need TAP, I recommend TUN anyway), there shouldn't be much to change. Just change the server from tap to tun. The default values in the local/remote endpoint fields should be okay. On the client you'll need to add
    ifconfig <local address> <remote address>
    where those are in the reverse order that they are in the server GUI.
    I can't think of any other options that are TUN specific. If there are, and you're unsure of it, let me know.
  12. Jimson

    Jimson Networkin' Nut Member

    Okay now this seems to lead to something:
    I read your link and tried just
    mssfix 1200
    And it actually helped :clap2: It was possible to surf the web through the VPN and file transfers didn't lock everything up. They weren't too fast, but they worked. Changing from TAP to TUN would probably help speed a lot, since I'm on a wireless connection right now and all these duplicate wireless packages are bridged through TAP, but wouldn't be through TUN, right?

    Anyway, I would like to try fragment with mssfix now, as I've never done it correctly: What I tried before was always just client-side. After reading your link I would now like to set fragment on the server side too. But before doing that, I would like to know the following:
    If I set a hostname which is allowed admin access in Tomato, will that only apply to remote traffic? So if I enter an external hostname, will all internal hosts still be able to connect to the router or will ONLY the external hostname be allowed in?

    And finally: Which value would you try for fragment & mssfix? The ones I tried before, or just 1200 and leave it at that?
  13. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    :bigsmile: Sounds like we're on to something. I'm glad you're being so persistent; I've never messed with the MTU options, so I'm learning as well here.
    I'm not sure what "duplicate wireless packages" you're referring to (not questioning it, I'm just no wireless expert), but using TUN would save any non-IP traffic from going over the tunnel.
    The admin access restriction only applies to the WAN interface. LAN and VPN connected devices will still be able to use the web GUI.
    I would probably use the values mentioned in the link I provided (multiples of 100) and use the largest that fixed the problem. I wouldn't spend too much time trying to get more specific than that.
  14. Jimson

    Jimson Networkin' Nut Member

    Just a quick explanation here, don't have time to test right now:
    I'm not really sure about that, but I think wireless connections send out quite a load of overhead packages, as if they were already expecting a part of them not to reach the wireless receiver. If they reach the receiver, they're dropped. Now in my case that might flood the VPN connection because they're transferred all the way through the tunnel before being dropped.
    As I said: Not really sure about this. Just read somewhere that wireless + TAP might not be the best way to do it. I use the windows network environment and a few other services relying on broadcasts quite regularily, that's why I chose TAP in the first place.

    Let's see where this MTU thing leads us :)
  15. Jimson

    Jimson Networkin' Nut Member

    Holy guakamole! Just trying fragment and mssfix in combination, having fragment enabled in both the server's and the client's config and this connection is racing!
  16. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Great! Sounds like something that should be in the GUI.
  17. Jimson

    Jimson Networkin' Nut Member


    Thanks for your help mate, wouldn't have figured it out without it! Thanks, really!

Share This Page