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

Problem connecting to VPN...

Discussion in 'Tomato Firmware' started by peridoc, Dec 23, 2008.

  1. peridoc

    peridoc Addicted to LI Member

    I am trying to use the "1.23vpn2.0005" version of this firmware (http://www.linksysinfo.org/forums/showthread.php?t=59416) to get a VPN up from work to my home and I am having a problem. I am not new to OpenVPN, but I am new to this version of the tomato firmware. I have tried two different setups without success:

    1. TLS with tls-auth
    2. Static Key mode

    I can see my client come in and start negotiation with the VPN server, but I can never fully connect. With the TLS option I just get what appears to be a timeout and with the static key I see the router trying to get my client a IP address, but it never does get it. Any thoughts or help would be appreciated. Here are some logs of what I see:

    TLS Mode
    ----------
    Code:
    Dec 23 07:39:52 WRT54G daemon.notice openvpn[3912]: MULTI: multi_init called, r=256 v=256
    Dec 23 07:39:52 WRT54G daemon.notice openvpn[3912]: Initialization Sequence Completed
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: MULTI: multi_create_instance called
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 Re-using SSL/TLS context
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 LZO compression initialized
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 Control Channel MTU parms...
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 Data Channel MTU parms...
    Dec 23 07:40:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 TLS: Initial packet from XXX.XXX.XXX.XXX:63943, sid=XXX XXX
    Dec 23 07:41:15 WRT54G daemon.err openvpn[3912]: XXX.XXX.XXX.XXX:63943 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Dec 23 07:41:15 WRT54G daemon.err openvpn[3912]: XXX.XXX.XXX.XXX:63943 TLS Error: TLS handshake failed
    Dec 23 07:41:15 WRT54G daemon.notice openvpn[3912]: XXX.XXX.XXX.XXX:63943 SIGUSR1[soft,tls-error] received, client-instance restarting
    Static Key Mode
    ----------------
    Code:
    Dec 23 07:38:05 WRT54G daemon.notice openvpn[3851]: Peer Connection Initiated with XXX.XXX.XXX.XXX:64466
    Dec 23 07:38:05 WRT54G daemon.notice openvpn[3851]: Replay-window backtrack occurred [1]
    Dec 23 07:38:06 WRT54G daemon.notice openvpn[3851]: Initialization Sequence Completed
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPDISCOVER(br0) XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPOFFER(br0) 192.168.X.X XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPDISCOVER(br0) XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPOFFER(br0) 192.168.X.X XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPDISCOVER(br0) XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:08 WRT54G daemon.info dnsmasq[2755]: DHCPOFFER(br0) 192.168.X.X XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:24 WRT54G daemon.info dnsmasq[2755]: DHCPDISCOVER(br0) XX:XX:XX:XX:XX:XX 
    Dec 23 07:38:24 WRT54G daemon.info dnsmasq[2755]: DHCPOFFER(br0) 192.168.X.X XX:XX:XX:XX:XX:XX
    Again...neither mode actually fully connects. The Static mode at least starts up the TAP network adapter on my Vista client, but it never gets an IP address. Are there some options that I am missing that I need? Thanks for any assistance.

    I will post config files and settings shortly...
     
  2. peridoc

    peridoc Addicted to LI Member

    FYI...I have a linux server behind my firewall that I can run OpenVPN on just fine and connect with the TLS settings. This also proves that the keys are all ok and in order. I just prefer the VPN to be on my router.

    My VPN settings on my router are:

    Interface Type: TAP
    Protocol: UDP
    Authorization Mode: TLS
    tls-auth: Incoming (0)
    DHCP Checked
    Encryption: Use Default
    Compression: Enabled
    Custom Config: Empty

    OpenVPN Client Config: (tls)
    ----------------------------
    client
    dev tap
    proto udp
    remote XXX.XXX.XXX.XXX XXX
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert client.crt
    key client.key
    ns-cert-type server
    tls-auth ta.key 1
    comp-lzo
    verb 3
    float


    OpenVPN Client Config: (static)
    ------------------------------
    dev tap
    proto udp
    remote XXX.XXX.XXX.XXX XXX
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    secret static.key
    comp-lzo
    verb 3
     
  3. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Hmmm, everything looks okay there (not surprising since, as you say, it works with an external VPN server).

    From the logs, I'd say it is some kind of firewall issue. Let's try to narrow it down from both ends.
    • On the Vista machine, could you completely disable all firewalls (never used Vista, but from what I read you may need to logout/login to get it to really take effect) and try again?
    • Could you try to use the same config (changing the address to the router's LAN IP) and key files to connect from a LAN machine to the router's VPN server (this takes the router firewall out of the picture)?
     
  4. peridoc

    peridoc Addicted to LI Member

    Actually the VPN server I can connect to is behind my router at my home LAN. I basically just have to change the VPN port forward to go to that machine instead of my tomato router and it works with no firewall issues at all.

    I do not use the Windows built-in firewall...I have Kaspersky, and I have tried multiple times to disable it with no improvement in results. I have connected to the non-tomato VPN I mentioned above with OpenVPN and the Kaspersky software turned on though. (So it should not be an issue)

    I have tried this before (I am not at home currently) and I have been able to connect and get an IP address with both methods. I agree with you that this seems to act like a firewall issue, but VPN works from outside the LAN to the non-tomato LAN VPN and does not work to the tomato LAN VPN with the same client computer. I even wiped NVRAM and set up my tomato router from scratch and had no different results. It is very weird...
     
  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Could you log into the router while the VPN server is running and output the ovpn file in /etc/openvpn? Then compare it to the config file on the LAN VPN server that works.

    Also could you compare relevant entries from iptables -L on each?
     
  6. peridoc

    peridoc Addicted to LI Member

    My non-tomato box is a busybox system that uses a "post-firewall" file to set iptables permissions. iptables -L does not return anything on that box, but in the post-firewall the only real difference I note is a line for the tap and tun interfaces:

    Code:
    iptables -A INPUT -i tun+ -j ACCEPT
    iptables -A INPUT -i tap0 -j ACCEPT
    iptables -A INPUT -i br0 -j ACCEPT
    ...
    iptables -A FORWARD -i tun+ -j ACCEPT
    iptables -A FORWARD -i br0 -j ACCEPT
    
    Here is the config on my tomato router:


    Code:
    # Automatically generated configuration
    daemon
    server-bridge
    proto udp
    port XXXX
    dev tap21
    comp-lzo yes
    keepalive 15 60
    verb 3
    tls-auth server1-static.key 0
    ca server1-ca.crt
    dh server1-dh.pem
    cert server1.crt
    key server1.key
    status-version 2
    status server1.status
    My config on my other non-tomato box has two conf files (openvpn.conf and server.conf):

    openvpn.conf

    Code:
    dev tap0
    ifconfig 192.168.1.xxx 192.168.1.xxx-xxx
    up ./openvpn.up
    tls-server
    dh dh1024.pem
    ca my-ca.crt
    cert slug-certificate.crt
    key  slug-certificate.key
    comp-lzo
    ping               15
    ping-restart      300 # 5 minutes
    resolv-retry      300 # 5 minutes
    persist-tun
    persist-key
    verb 3
    server.conf

    Code:
    port xxxx
    proto udp
    dev tap0
    ca ca.crt
    cert server.crt
    key server.key  # This file should be kept secret
    dh dh1024.pem
    ifconfig-pool-persist ipp.txt
    server-bridge 192.168.1.xxx 255.255.255.xxx 192.168.1.xxx 192.168.1.xxx
    keepalive 10 120
    tls-auth ta.key 0 # This file is secret
    comp-lzo
    user nobody
    group nobody
    persist-key
    persist-tun
    status openvpn-status.log
    verb 3
     
  7. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Those entries (minus the tun, since you aren't using tun) should appear on the router as well. I wouldn't expect that to be a difference. Could you look at the contents of /etc/openvpn/server1-fw.sh?

    If possible, could try try different combinations of TAP/TUN and UDP/TCP to see if the problem is specific to one or the other?
     
  8. peridoc

    peridoc Addicted to LI Member

    Here is that file's entries:

    Code:
    iptables -I INPUT -p udp --dport XXXX -j ACCEPT
    iptables -A INPUT -i tap21 -j ACCEPT
    iptables -A FORWARD -i tap21 -j ACCEPT
    
    I will try this out and report back anything I find...
     
  9. peridoc

    peridoc Addicted to LI Member

    TCP worked the first time I tried it just now. I had not tried this before...altough I should have. Looks like it might be a problem with UDP.
     
  10. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Interesting. I'll have to think about it and see if I come up with anything.
     
  11. peridoc

    peridoc Addicted to LI Member

    Let me know if you need me to try anything for you. (At least after Christmas :))
     
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Okay. But, yes, it will probably have to be after Christmas on my end as well.
     
  13. peridoc

    peridoc Addicted to LI Member

    One minor addition I would like to request be made to the VPN page of the firmware would be that the "Start Now"/"Stop Now" button be at the top and bottom of the "VPN Tunneling" page rather than just the bottom.
     
  14. rlray64

    rlray64 Addicted to LI Member

    I'm also having a problem with UDP VPN connection. My configuration is WRT54GL tomato v1.23 w/vpn using tun + certs + tls auth

    I can connect consistently using TCP and have access to everything in my home (server side) network. If I change the server config to UDP and the client side to UDP (leaving everything else the same) I get the following error in the server logs:

    daemon.err openvpn[3456]: xx.xx.xx.xx:3255 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    daemon.err openvpn[3456]: xx.xx.xx.xx:3255 TLS Error: TLS handshake failed
    daemon.notice openvpn[3456]: xx.xx.xx.xx:3252 SIGUSR1[soft,tls-error] received, client-instance restarting
    daemon.notice openvpn[3456]: MULTI: multi_create_instance called

    [continues to retry until I disconnect]

    Other than this issue, the VPN mod works great. I'd like the option to use a UDP connection but TCP will do what I need. I've collected routing tables, iptables, config files, etc. and will look over those tonight.
     
  15. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Yes, UDP is preferable. TCP should only be used if necessary (eg tunnelling through a http proxy). However, it looks like there is a bug in the current version of OpenVPN (Nothing I've done could cause what you're seeing). If there is not a new version out soon (I've gotten word that there will be at least one more RC before 2.1 final), I'll make a release with 2.1rc13, since I don't think any of these issues were seen with that version.
     
  16. rlray64

    rlray64 Addicted to LI Member

    UPDATE: Open VPN with UDP tunnel works

    I originally used the stable Open VPN Gui for Windows -- OpenVPN 2.0.9 & OpenVPN GUI 1.0.3. After reading your reply (listing OpenVPN 2.1r13 didn't have issues), I upgraded to Windows Gui OpenVPN 2.1_beta7 & OpenVPN GUI 1.0.3. Now my UDP [tun + certs + tls auth] connection works with no issues.
     

Share This Page