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

How can I test Openvpn from inside lan

Discussion in 'Tomato Firmware' started by Bird333, Dec 1, 2012.

  1. Bird333

    Bird333 Network Guru Member

    I have a working config but I want to be able to test things out from inside my lan by using my WAN ip address or DDNS address. How can I accomplish this?
     
  2. samwathegreat

    samwathegreat Serious Server Member

    In the web GUI under advanced > firewall

    set NAT loopback to "ALL"

    With NAT loopback set to All, I'm able to connect to my VPN just fine from both inside and outside the LAN.

    Your current setting is probably set to "Forwarded Only"


    Let us know if that does it.
     
  3. Bird333

    Bird333 Network Guru Member

    I tried all 3 settings and it didn't make a difference. I can connect using my routers LAN ip from inside the LAN. Also, I can connect from outside using my DDNS address but I can't use my DDNS address from inside the lan.
     
  4. samwathegreat

    samwathegreat Serious Server Member

    What error are you getting? Is openvpn client just not resolving the hostname? Or are you connecting 2 tomato routers together Server > Client ?

    Also, what version are you running? I'm just not understanding. It works fine for me both inside and out.

    Check inside your lan and see what your hostname resolves to:

    run nslookup myhostname.dyndns.com

    does it resolve to your internal ip 192.168.X.X

    or to your purblic IP?

    for this to work right, it needs to resolve to your public IP both inside and outside the LAN. Depending on whether or not you actually set up tomato's hostname and domain name, the router may be resolving your hostname to your routers internal IP - in this case, openvpn would be confused because the packets didn't originate from where they were supposed to.
     
  5. Bird333

    Bird333 Network Guru Member

    Running Shibby 1.28 Big VPN

    In Putty (i.e the router) I get this.
    root@DD-WRT:/tmp/home/root# nslookup XXXXXX.no-ip.org
    Server: 205.***.***.*
    Address 1: 205.***.***.*

    Name: XXXXXX.no-ip.org
    Address 1: 184.***.****.*
    root@DD-WRT:/tmp/home/root#

    In my windows 7 command prompt I get this

    C:\users\XXX\nslookup XXXXXX.no-ip.org
    Server: DD-WRT
    Address: 192.168.***.* (notice it's my router's LAN ip)

    Non-authoritative answer:
    Name: XXXXX.no-ip.org
    Address: 184.***.****.*
     
  6. samwathegreat

    samwathegreat Serious Server Member


    Thats all normal. The 205 ip is the dns server that your router is using.

    The reason the 192 ip shows up is because your pc is using your routers internal caching DNS, which is resolves your hostname to the appropriate 184 ip.

    It all looks good. I'm not sure if the firewall is rebuilt when you set the NAT loopback option to all or if it doesn't go in to effect until a reboot. Please try setting to ALL and reboot. Try again.

    If it still doesn't work, we will have to look further, but since your pc is resolving the correct ip for your hostname, and nat loopback set to all, I don't see any obvious problem.

    Have you made any changes to your routing table? Are you using the default vpn settings (routed lan, 10.8.0.0 subnet?

    If you are using a bridged vpn (same subnet as router), then it might be trickier. Give me a little more info on your settings. I'm guessing that you're using the windows openvpn client? Again, what error is shown? The windows client should show you the entire log while its trying to connect. You will also find helpful information in tomato's own log. There should be daemon notices for openvpn. This info should help too.



    samwathegreat
     
  7. rhester72

    rhester72 Network Guru Member

    Have you checked the OpenVPN logs? I suspect it thinks there's an attack because the IP you appear to be coming from is already *inside* the target network (this is only true of bridged, not routed). If that's the case, there are a few possible solutions depending on what the actual problem is.

    Rodney
     
  8. Bird333

    Bird333 Network Guru Member

    You could be right. My setup has tap0 bridged in br0. Here is the error I see.

    Sat Dec 01 22:20:54 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Sat Dec 01 22:20:54 2012 TLS Error: TLS handshake failed
    Sat Dec 01 22:20:54 2012 TCP/UDP: Closing socket
     
  9. rhester72

    rhester72 Network Guru Member

    Is that the client log or the server log? What is the server seeing? (The above looks like a firewall block.)

    Rodney
     
  10. Bird333

    Bird333 Network Guru Member

    That was the client log. This is the server log.

    Sat Dec 1 22:10:14 2012 192.168.***.**:63534 TLS: Initial packet from 192.168.***.**:63534, sid=38164417 0e414fd8
    Sat Dec 1 22:10:44 2012 192.168.***.**:60777 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Sat Dec 1 22:10:44 2012 192.168.***.**:60777 TLS Error: TLS handshake failed
     
  11. kthaddock

    kthaddock Network Guru Member

    Have looked at this FAQ ? Maby you can have some hints there. HERE
     
  12. Bird333

    Bird333 Network Guru Member

    When I run 'tracert' command from windows I get this

    Code:
    1   1ms   1ms   1ms   wan-ip [184.***.**.*]
    There is only 1 hop straight to the router. It is not traveling through the internet to get to the wan.
     
  13. rhester72

    rhester72 Network Guru Member

    It may be a single hop, but that doesn't mean you're not traversing iptables.

    What is the output of...

    iptables -L -nv
    iptables -t nat -L -nv

    ?

    Rodney
     
  14. Bird333

    Bird333 Network Guru Member

    Code:
    Tomato v1.28.0000 MIPSR2-102 K26 USB Big-VPN
    root@DD-WRT:/tmp/home/root# iptables -L -nv
    Chain INPUT (policy DROP 14 packets, 969 bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:25000
      279 49015 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:1194
        0    0 ACCEPT    tcp  --  br2    *      0.0.0.0/0            0.0.0.0/0          tcp dpt:53
        0    0 ACCEPT    udp  --  br2    *      0.0.0.0/0            0.0.0.0/0          udp dpt:53
        0    0 ACCEPT    udp  --  br2    *      0.0.0.0/0            0.0.0.0/0          udp dpt:67
        0    0 DROP      all  --  br2    *      0.0.0.0/0            0.0.0.0/0          state NEW
        0    0 ACCEPT    tcp  --  br1    *      0.0.0.0/0            0.0.0.0/0          tcp dpt:53
        3  194 ACCEPT    udp  --  br1    *      0.0.0.0/0            0.0.0.0/0          udp dpt:53
        1  328 ACCEPT    udp  --  br1    *      0.0.0.0/0            0.0.0.0/0          udp dpt:67
        0    0 DROP      all  --  br1    *      0.0.0.0/0            0.0.0.0/0          state NEW
        8  320 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    4518 4845K ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
        2    96 shlimit    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:22 state NEW
      24  1884 ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0 
    1379 94844 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  br1    *      0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:51413
     
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 ACCEPT    udp  --  br1    br0    0.0.0.0/0            0.0.0.0/0          udp dpts:8610:8614
        0    0 ACCEPT    tcp  --  br1    br0    0.0.0.0/0            0.0.0.0/0          tcp dpts:8610:8614
        0    0 DROP      all  --  br2    !ppp0  0.0.0.0/0            0.0.0.0/0 
        0    0 DROP      all  --  br1    !ppp0  0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  tap1  br0    0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  br0    tap1    0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  tap0  br0    0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  br0    tap0    0.0.0.0/0            0.0.0.0/0 
    320K  295M            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.200.0/255.255.255.0 name: lan
      55 13644            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.3.0/255.255.255.0 name: lan1
        0    0 ACCEPT    all  --  br0    br0    0.0.0.0/0            0.0.0.0/0 
        0    0 ACCEPT    all  --  br1    br1    0.0.0.0/0            0.0.0.0/0 
        2    80 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    3644  189K TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    318K  295M ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
        0    0 DROP      all  --  br0    br1    0.0.0.0/0            0.0.0.0/0 
        0    0 DROP      all  --  br1    br0    0.0.0.0/0            0.0.0.0/0 
        0    0 wanin      all  --  ppp0  *      0.0.0.0/0            0.0.0.0/0 
    1783 92768 wanout    all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0 
    1780 92576 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0 
        3  192 ACCEPT    all  --  br1    *      0.0.0.0/0            0.0.0.0/0 
     
    Chain OUTPUT (policy ACCEPT 5012 packets, 631K bytes)
    pkts bytes target    prot opt in    out    source              destination
     
    Chain shlimit (1 references)
    pkts bytes target    prot opt in    out    source              destination
        2    96            all  --  *      *      0.0.0.0/0            0.0.0.0/0          recent: SET name: shlimit side: source
        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
     
    Chain wanin (1 references)
    pkts bytes target    prot opt in    out    source              destination
     
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination
     
     
    root@DD-WRT:/tmp/home/root# iptables -t nat -L -nv
    Chain PREROUTING (policy ACCEPT 4942 packets, 873K bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 DNAT      udp  --  ppp0  *      0.0.0.0/0            184.**.***.***      udp dpt:53 to::1194
      14  969 WANPREROUTING  all  --  *      *      0.0.0.0/0            184.**.***.***
        0    0 DROP      all  --  ppp0  *      0.0.0.0/0            192.168.200.0/24
        0    0 DROP      all  --  ppp0  *      0.0.0.0/0            192.168.3.0/24
     
    Chain POSTROUTING (policy ACCEPT 23 packets, 1744 bytes)
    pkts bytes target    prot opt in    out    source              destination
    2194  121K MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0 
        0    0 MASQUERADE  all  --  *      vlan2  0.0.0.0/0            192.168.1.254
      14  3703 SNAT      all  --  *      br0    192.168.200.0/24    192.168.200.0/24    to:192.168.200.1
        1  328 SNAT      all  --  *      br1    192.168.3.0/24      192.168.3.0/24      to:192.168.3.1
     
    Chain OUTPUT (policy ACCEPT 507 packets, 36638 bytes)
    pkts bytes target    prot opt in    out    source              destination
     
    Chain WANPREROUTING (1 references)
    pkts bytes target    prot opt in    out    source              destination
        3  192 DNAT      icmp --  *      *      0.0.0.0/0            0.0.0.0/0          to:192.168.200.1
    
     
  15. rhester72

    rhester72 Network Guru Member

    There's no WANPREROUTING rule whatsoever, except a single global ICMP rule. Worse, in PREROUTING, you're DNATting anything coming in on port 53 to an undefined address on port 1194, which isn't even a valid rule to the best of my knowledge (and as you can see above, has 0 hits).

    Is this deliberate? If so, the firewall rules will have to be reworked (and maybe you can share what you're actually trying to achieve ;). Otherwise, you're a lot better off letting Tomato handle the firewall rules for you (i.e. Firewall = Automatic).

    Rodney
     
  16. Dr Strangelove

    Dr Strangelove Networkin' Nut Member

    I'm in the process of rebuilding my OpenVPN environment over again with new certs and the addition of new Android mobile devices.
    In testing I notice my Win7 Notebook using OpenVPN is able to connected to the TomatoUSB OpenVPN server internally via 'Private' IP where the 'Global' IP address is that of an ADSL2 modem which is then routed back to the E4200 router. So it seems to be doing an IP routing out and back and connecting OK.

    I do have a local DNS server on the TomatoUSB E4200 router too, so not sure if that helps.

    I just use Firewall 'automatic' and nothing much more than the defaults for OpenVPN server setup. This hasn't always been the case as I seem to remember having to use a Mobile phone WiFi tether on a Telco network to get an out and back connect in the past.

    AS an aside, my Android mobile phone(s) with OpenVPN via the telco IP network over 3G make a good out and back test from home. :)
     
  17. Bird333

    Bird333 Network Guru Member

    That PREROUTING rule is valid. It just takes whatever is coming in on my WAN IP on port 53 and changes it to port 1194 and it works. I am not using the gui to do Openvpn, Maybe that is why some of the rules don't show up. However, I did do a test using the gui and it made no difference. If you want I can post the firewall rules using the Openvpn gui? Should I change my PREROUTING rule to WANPREROUTING? I know this won't make a difference in my problem here because I am not trying to connect on port 53 and I going directly to port 1194, but I am just wondering if it is better?
     
  18. rhester72

    rhester72 Network Guru Member

    OK, I think I may be getting a clue now. Are you explicitly binding OpenVPN to a specific IP/interface? What is the output of "netstat -an | grep :1194"?

    Rodney
     
  19. Bird333

    Bird333 Network Guru Member

    I don't think I am binding Openvpn to a specific interface. I create tap0 and put it in bridge br0. Here is the output
    Code:
    udp        0      0 0.0.0.0:1194            0.0.0.0:*
     
  20. rhester72

    rhester72 Network Guru Member

    And when you're testing internally, what IP and port do you use on the client (i.e. what do you tell it the server IP and port is)?

    Rodney
     
  21. Bird333

    Bird333 Network Guru Member

    I am using my no-ip address and port 1194 in the client config. Which according to the client log resolves to the correct ip address.
     
  22. rhester72

    rhester72 Network Guru Member

    Huh? On the outside, you're listening to WAN-IP:U53 (though I still have my doubts that rule is correct). On the inside, you're listening to LAN-IP:U1194. WAN-IP:U1194 can't work by design (the way you've set it up), there is no outside listener at all on 1194.

    Rodney
     
  23. Bird333

    Bird333 Network Guru Member

    There is an input rule for port 1194.
     
  24. rhester72

    rhester72 Network Guru Member

    INPUT rules are for LAN-to-LAN connections only. Since you're trying to hit the ppp0 address, you'll never reach INPUT without going through (WAN)PREROUTING first.

    Rodney
     
  25. Bird333

    Bird333 Network Guru Member

    Your understanding of INPUT is different than mine. INPUT from my understanding is for when the router is the target of the packets. FORWARD is for packets going to other networks. I assure you I can connect just fine without any PREROUTING rule.
     
  26. rhester72

    rhester72 Network Guru Member

    OK - I'll let someone else chime in.
     
  27. samwathegreat

    samwathegreat Serious Server Member


    rchester72 is pretty much an expert with IPtables, and I'm certian he won't steer you in the wrong direction.

    I'm curious, however, why you're forwarding ports. In my setup, I've set openvpn to listen on port 443 - I've found this works great, because I haven't found a network yet that blocks udp on 443.

    Unfortunately, my knowledge is minimal compared to rchester72.

    Good Luck.
     
  28. Bird333

    Bird333 Network Guru Member

    I don't think the rchester72 will steer me in the wrong direction. I learned most of what I know about iptables from this tutorial. http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES Notice the 'caution' message right after table 6-3. It says "INPUT is meant solely for packets to our local host that do not get routed to any other destination." In our case the router. Opening post 1194 in the INPUT chain allows me to connect to openvpn because openvpn is running on the router itself. BTW, the reason why I have the PREROUTING rule, like you, I know some networks block certain ports, so if I can't get to Openvpn through port 1194 I can try port 53 which will still point to 1194 where openvpn is listening because that rule simply changes the port to 1194 before it hits the INPUT rule. Just so I am clear, I welcome anybody's help. :)
     
  29. samwathegreat

    samwathegreat Serious Server Member

    Would you consider trying a routed vpn vs bridged vpn? Obviously, if you are able to connect fine routed, then we will know that your iptables rules are good, and we can look into why the router thinks its under attack by having bridged vpn running on local IP.

    Also, just out of curiousity, what purpose does connecting to the vpn from inside the lan serve?
     
  30. Bird333

    Bird333 Network Guru Member

    I guess I could try routed but I'm not really sure how to set it up. I like bridged because it makes my computer behave like it is on my lan at home. Everything works as if I was at home. I want to be able to connect from inside so I don't have to drive to a free hotspot to test my Openvpn connection through my WAN ip. :)
     
  31. Bird333

    Bird333 Network Guru Member

    Ok, I just ran wireshark on my laptop while I tried to connect to my vpn through the WAN address. Based on my openvpn logs, I am failing at the TLS Handshake. I am no expert at reading wireshark logs but it looks like I am send the request out to my WAN IP for the TLS handshake but what is replying back is the local router IP. I don't know how you get the router to reply back through the WAN if the router knows that the IP that is sending the request is on its local network and wants to reply back using its local ip address. Is there a way to run my openvpn config without the TLS just to check to see if this is the problem?
     
  32. rhester72

    rhester72 Network Guru Member

    Your wireshark capture is correct. The purpose of WANPREROUTING is DNAT, which is the only way it's going to work.
     
  33. Bird333

    Bird333 Network Guru Member

    What rule do I need to put in WANPREROUTING to make this work?
     
  34. samwathegreat

    samwathegreat Serious Server Member


    try adding to firewall script, save, then reboot:

    iptables -A WANPREROUTING -t nat -p udp --dport 1194 -j DNAT --to-destination 192.168.1.1

    substitute, of course with your appropriate router ip address.



    rchester72 is right. DNAT is the mechanism that re-writes your packet header information to make the packet appear that it originated from your wan ip. Since you're using hostname in openvpn, openvpn is expecting the replies to be coming from this address. Without DNAT, your router is sending packets with its LAN ip as the source.

    Let us know if it works.
     
  35. Bird333

    Bird333 Network Guru Member

    The above works but now I can't connect from outside my network to openvpn.

    Questions:

    1. Which gets processed first WANPREROUTING or PREROUTING?
    2. Is WANPREROUTING a Tomato specific thing? I haven't seen it with other iptables rules.
    3. What rules are added/changed when Loopback setting is changed?
    4. Is it not possible to be able to test openvpn inside the LAN using the WAN address and also connect from outside the LAN? It seems it's one or the other.

    I tried to 'tighten' the rule by adding '-i ppp0' but that makes the rule fail. Just to be clear, the rule gets added but then Openvpn doesn't connect. Can someone explain why? Also, adding -d `nvram get wan_ipaddr` (i.e the WAN ip address) seems to make Openvpn fail to connect. Well it did earlier but now it seems to work. Why would adding that to the rule cause a problem?
     
  36. samwathegreat

    samwathegreat Serious Server Member


    I'm not sure about some of the questions (maybe someone else can chime in), but here is a good explaination of the difference between ALL and FORWARDED in NAT Loopback:

    http://www.dslreports.com/forum/r22683726-Tomato-tomato-firmware-NAT-loopback-settings

    Your problems are definitely coming from some of the iptables rules you have in place.

    Quoting rhester72:

    PLEASE try ditching all of the iptables rules that you already had in place. You ONLY need 2 rules for this to work.

    For the sake of testing, please set openvpn to ONLY listen on one port. I'm not sure why you would need to be able to use both ports 53 and port 1194 - please pick just one. If you're concerned about the possibility of someone blocking port 1194, then just use port 53. Set openvpn to listen on port 53

    Next, add the input rule:

    iptables -A INPUT -p udp --dport 53 -j ACCEPT

    and add the WANPREROUTING rule:

    iptables -A WANPREROUTING -t nat -p udp --dport 53 -j DNAT --to-destination 192.168.1.1

    and again, be sure NAT loopback is set to ALL

    I think your issue is the additional rules you have in place.

    Once we confirm that this solution works both inside and outside the LAN, we can look into customizing your configuration further.

    Just to confirm: there is NO reason (with correct iptables rules) that you shouldn't be able to connect to your vpn from both inside and outside the LAN. My configuration works both inside and out, using only the 2 rules listed above. The only difference between my configuration and yours is the port we are listening on, and the fact that I'm using routed vpn and you are using bridged vpn.
     
  37. samwathegreat

    samwathegreat Serious Server Member





    On second thought, having openvpn listen on port 53 will interfere with DNS when you're using it inside the LAN. DON'T USE 53.

    For the sake of testing, use port 1194 with the 2 rules above. Lets make sure this works, then move forward.


    Change syntax:

    iptables -A INPUT -p udp --dport 1194 -j ACCEPT

    iptables -A WANPREROUTING -t nat -p udp --dport 1194 -j DNAT --to-destination 192.168.1.1
     
  38. Bird333

    Bird333 Network Guru Member

    I have eliminated all of my rules but the ones you mentioned. I can connect through my WAN from inside my lan. I will have to go find another internet connection to test it externally. Unless there is something I don't understand, Openvpn is not set to listen on port 53. That PREROUTING rule I had just allowed traffic coming into the router on port 53 to get sent to port 1194 where openvpn is listening. For example, I could have 100 different ports all pointing to 1194 so I could start my client with any one of the 100 ports and still get to port 1194. I think I understand the WANPREROUTING chain. The first rule in the PREROUTING chain is to send all traffic coming to the WAN ip address to the WANPREROUTING chain. From there the packets will receive additional processing. In my case right now there are only 2 rules in WANPREROUTING. BTW, where did that quote from rhester72 come from?
     
  39. samwathegreat

    samwathegreat Serious Server Member

    It came from an older thread where he helped me solve my problem with lighttpd web server. :)

    As for openvpn, you can change the listen port in the web GUI, or in your case since you're on dd-wrt, you can edit your openvpn server.conf file to change the listen port. This avoids having to add additional rules to forward traffic. In my case, I use port 443 only, I've set openvpn to listen on port 443 directly, and so I only need the two referenced rules: the INPUT rule, and the corresponding WANPREROUTING rule. Generally, the fewer rules you can use to achieve your desired goal, the better.

    Sounds like you have your initial problem solved though....pending a test from WAN, of course.

    Please let us know how it turns out.
     
  40. Bird333

    Bird333 Network Guru Member

    Eventually, I am going to have to change the router name because I am not on DD-WRT. :) I'm on Tomato. Well I tried 3 different hotspots, and I couldn't connect from any of them. I ran wireshark on the last one and it looks like I am not getting any response from my WAN address.
     
  41. samwathegreat

    samwathegreat Serious Server Member

    You got rid of the prerouting rules, right? And your openvpn client config is set to port 1194?

    If so, then I'm at a loss. It just doesn't make sense that you would be able to connect via hostname from inside the lan, but can't connect from outside.
     
  42. Bird333

    Bird333 Network Guru Member

    Yes. The only thing I had was the two rules you mentioned above. That prerouting rule really shouldn't matter any way because it would only match if I was connecting on port 53 otherwise it would just be skipped. Just to be clear it wasn't in the firewall rules. :) I don't get it either.
     
  43. samwathegreat

    samwathegreat Serious Server Member

    The only think I can guess is that there is some code left over from when you ran DD-wrt. From the looks of it, it appears that you upgraded to Tomato without erasing all NVRAM. My guess is that you had a working config with dd-wrt and upgraded directly to tomato, leaving existing settings intact. This is the only logical reason that your router would still be named DD-WRT.

    Anytime you change firmware versions, its highly recommended that you erase all NVRAM and re-configure from scratch. This also has the added benefit of freeing as much NVRAM as possible.

    I've got a hunch that you are using an external usb drive with the same optware you were running with dd-wrt....I can't really imagine another reason you aren't using the webgui.

    Unless someone else wants to voice their suggestions, I would recommend doing complete nvram erase and re-configure. I'm really not seeing a reason not to use the webgui for openvpn when you're using a firmware with it built-in.

    I realize that this may be alot of work, but I fear that it may be the only way to get it working properly from both ends.
     
  44. Bird333

    Bird333 Network Guru Member

    I named my router DD-WRT just to make it easy on myself so I wouldn't have to change stuff on other devices in the house. I will change the name when I get everything working like I want. I have erased NVRAM more than once, but I may do it again. I'm not using the same optware either. I put a freshly partitioned hd on the router and installed Entware. The openvpn I am using is the one that is already in the firmware. I am just calling it manually from the 'init' script. My openvpn config file is stored on the usb drive though. The only thing I can think of is the fact that my tap0 is part of the br0 bridge. I have created a couple of additional iptables rules to deal with this that I am going to try out.
     
  45. Bird333

    Bird333 Network Guru Member

    I created a couple of new rules to handle both situations. I may try to run wireshark on the router itself to see why that one rule doesn't work for external connections.
     
  46. mobile_VPN

    mobile_VPN Serious Server Member

    Hi, I have a reverse problem in OpenVPN setting. I can test Openvpn successfully from inside lan, but I can never connect to my vpn server from outside. Can anyone please tell me what's going on? What should I do? Thanks!

    If I connect from outside (Wan), the openvpn client stop at below
    ---------------------------------------------------------------------
    Wed Dec 26 23:19:02 2012 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
    Wed Dec 26 23:19:02 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Wed Dec 26 23:19:02 2012 LZO compression initialized
    Wed Dec 26 23:19:02 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Wed Dec 26 23:19:02 2012 Socket Buffers: R=[8192->8192] S=[8192->8192]
    Wed Dec 26 23:19:02 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Wed Dec 26 23:19:02 2012 Local Options hash (VER=V4): '41690919'
    Wed Dec 26 23:19:02 2012 Expected Remote Options hash (VER=V4): '530fdded'
    Wed Dec 26 23:19:02 2012 UDPv4 link local: [undef]
    Wed Dec 26 23:19:02 2012 UDPv4 link remote: *.*.*.*(My Wan IP):1194
    -----------------------------------------------------------------------------------------

    Hers is my iptables (from iptables -t nat -L -nv)
    ---------------------------------------------------------------------------------------------------------------
    Chain PREROUTING (policy ACCEPT 9387 packets, 830K bytes)
    pkts bytes target prot opt in out source destination
    1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
    2709 306K WANPREROUTING all -- * * 0.0.0.0/0 (My Wan IP here)
    0 0 DROP all -- vlan2 * 0.0.0.0/0 192.168.1.0/24

    Chain POSTROUTING (policy ACCEPT 2529 packets, 290K bytes)
    pkts bytes target prot opt in out source destination
    10204 809K MASQUERADE all -- * vlan2 0.0.0.0/0 0.0.0.0/0
    4 1036 SNAT all -- * br0 192.168.1.0/24 192.168.1.0/24 to:192.168.1.1

    Chain OUTPUT (policy ACCEPT 1603 packets, 102K bytes)
    pkts bytes target prot opt in out source destination

    Chain WANPREROUTING (1 references)
    pkts bytes target prot opt in out source destination
    2 120 DNAT icmp -- * * 0.0.0.0/0 0.0.0.0/0 to:192.168.1.1
    0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:8200:8300 to:192.168.1.19
    0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:8200:8300 to:192.168.1.19
    493 26440 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:8000:8100 to:192.168.1.47
    2036 264K DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:8000:8100 to:192.168.1.47
    0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7001 to:192.168.1.46:7001
    0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:7001 to:192.168.1.46:7001
    ---------------------------------------------------------------------------------------------------------------
     
  47. _KaszpiR_

    _KaszpiR_ Reformed Router Member

    Sorry for ressurecting dead from the grave, but I have stumbled upon the same issue as described in the first post.
    I will have to yet to validate it in order to test connection from outside.
    Edit: looks like it does not work from the outside :/

    If described below, then it allows connection from the inside.
    When changing firewall to auto, and then disabling port forward rule then it works from the outside, but then does not work from the inside.

    The trick is quite easy using the default OpenVPN configuration on Tomato with TUN or TAP setup, without digging in custom firewall scripts or executing commands - just using web GUI.

    Go to Tomato > VPN Tunneling > OpenVPN Server and select proper server.
    In Basic:
    - select Firewall to Custom
    - remember Protocol (UDP heavily suggested)
    - remember Port (let say 1994, because it is default one).
    Save settings on the page, the services will restart.

    Now go to the Tomato > Port Forwarding > Basic.
    Add new rule:
    - choose the Proto the same as the one remembered.
    - leave Src Address blank
    - set Ext Ports to the remebered port, that is 1994 if default
    - set Int Address to the internal IP of the router, usually it is 192.168.1.1
    - add description to rememeber what it does, because you will forgot it after 4 weeks ;)
    Click Save, wait a few seconds to update ruleset.

    Now go to your computer and you should be able to connect to the OpenVPN via remote IP but from the inside LAN.

    You can do this with TAP, but then you have two IP addresses from the same LAN. ;)
     
    Last edited: Oct 12, 2013
  48. Bird333

    Bird333 Network Guru Member

    I think it is failing because the router is too smart for it's own good. :) It seems to recognize that the request is coming from inside the lan so it replies back using the the internal address instead of replying back through the external address.
     

Share This Page