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

Openvpn(from tomato gui) DNS routing problem

Discussion in 'Tomato Firmware' started by jiml, Apr 2, 2009.

  1. jiml

    jiml Addicted to LI Member

    Long story short, I couldn't get Openvpn working with a tap interface. I went with TUN and the client is a mac connecting using viscosity.

    I can connect and web traffic is routed through the VPN, however DNS is not being routed through the tunnel. Viscosity automatically sets up DNS through the tunnel if configured to do so. I have been looking through the server logs and I think I found the error causing the problem but I am not sure how to resolve it. I edited my public ip with xxx.xxx

    Apr 2 13:54:31 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 LZO compression initialized
    Apr 2 13:54:31 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Apr 2 13:54:31 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Apr 2 13:54:31 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 TLS: Initial packet from xxx.xxx.247.82:55536, sid=cc6c06de 58c3e4b1
    Apr 2 13:54:33 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 VERIFY OK: depth=1, /C=US/ST=SC/L=GOOSECREEK/O=NOWHEREMAN/OU=Cool/CN=yes/Email=mail@host.domain
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 VERIFY OK: depth=0, /C=US/ST=SC/O=NOWHEREMAN/OU=macbook/CN=jimmacbook/Email=mail@host.domain
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
    Apr 2 13:54:34 unknown daemon.notice openvpn[23356]: xxx.xxx.247.82:55536 [jimmacbook] Peer Connection Initiated with xxx.xxx.247.82:55536
    Apr 2 13:54:35 unknown daemon.notice openvpn[23356]: MULTI: new connection by client 'jimmacbook' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or userna
    Apr 2 13:54:35 unknown daemon.notice openvpn[23356]: MULTI: Learn: 10.8.0.6 -> jimmacbook/xxx.xxx.247.82:55536
    Apr 2 13:54:35 unknown daemon.notice openvpn[23356]: MULTI: primary virtual IP for jimmacbook/xxx.xxx.247.82:55536: 10.8.0.6
    Apr 2 13:54:35 unknown daemon.notice openvpn[23356]: jimmacbook/xxx.xxx.247.82:55536 PUSH: Received control message: 'PUSH_REQUEST'
    Apr 2 13:54:35 unknown daemon.notice openvpn[23356]: jimmacbook/xxx.xxx.247.82:55536 SENT CONTROL [jimmacbook]: 'PUSH_REPLY,route 192.168.15.0 255.255.255.0,redirect-gateway,route 10.8.0.0 255.255.255.0,topology net30,ping 15,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (s
    Apr 2 13:54:36 unknown daemon.notice openvpn[23356]: jimmacbook/xxx.xxx.247.82:55536 MULTI: bad source address from client [192.168.1.25], packet dropped
    Apr 2 13:54:36 unknown daemon.notice openvpn[23356]: jimmacbook/xxx.xxx.247.82:55536 MULTI: bad source address from client [192.168.1.25], packet dropped
    Apr 2 13:54:36 unknown daemon.notice openvpn[23356]: jimmacbook/xxx.xxx.247.82:55536 MULTI: bad source address from client [192.168.1.25], packet dropped


    So if you look at that, you will see that the ip address for my macbook is 192.168.1.25. That is my nat'ed address on my local router. My actual public ip address is the xxx.xxx.247.82

    The address for my tun is 10.8.0.6

    So what is going on and how do I get the DNS routed correctly?
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The "bad source address" error in that log don't have anything to do with DNS. My guess is that you have not configured the server to accept the client router's LAN and don't have the NAT checkbox on the client router selected. Is that right? You'll have to do one or the other.

    But, for DNS, there are two problems:
    1. It doesn't look like your server is configured to send the DNS options to the clients. There should be a "dhcp-option DNS" line in the push.
    2. Even if it was configured to push DNS out, Linux clients (which your router is) cannot natively accept dhcp-option directives. Please try (after remedying number 1) adding the scripts found here or here to add this capability. Also try replacing all occurances of /etc/resolv.dnsmasq with /etc/resolv.conf in those scripts.

    Let me know how it goes.
     
  3. jiml

    jiml Addicted to LI Member

    Either I am not following you or I miscommunicated something.

    The client is a mac laptop. Not a router. I am not setting up a router to router tunnel.

    So I have my server that is tomato with your openvpn gui. My client is a mac connecting using viscosity.

    I manually changed the DNS server on my client to use the router DNS where openvpn is running but the requests just time out. That is why I thought maybe the dropped packets were the problem.

    How do I configure the server router to accept my client's lan?

    It is just weird because I am able to connect manually to all my samba shares that are sitting on the LAN where the openvpn router exists. I just can't get DNS to work.

     
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I misread/misunderstood. I thought the laptop was on the LAN behind a VPN client router. This was partially due to the error being displayed (see below). My mistake.
    Strange indeed. The server should never never hear about the "192.168.1.25". As far as it is concerned, the client is 10.8.0.6. Period. Apparently, it is sending traffic back to the server saying it is 192.168.1.25, which the server doesn't know about - so it drops the packets.

    Do you have the TAP/TUN setting the same on the server router and client laptop? If so, I think there is a bug in the viscosity client. Though, I could see how this could happen if you accidentally chose TAP on your laptop. Also, I can't see off-hand how it would result in this error, but to be safe, the LAN subnet is different on each end of the tunnel, right?

    If you've double-checked the above, and it is a bug in viscosity, I think we can work around it. In the server configuration, select Manage Client-Specific Options (Advanced section), and enter your laptop's common name (jimmacbook) with subnet/netmask (192.168.1.0/255.255.255.0, presumably). This should teach the router that "when jimmacbook is connected, any 192.168.1.x address is reachable on the other side of this tunnel somewhere".

    Also, my previous comment on DNS options apply to Macs, too. In order to get it to accept the DNS (so you don't have to manually enter it when connected), you'll need to run up/down scripts on the client. See the openvpn-tun-up-down.sh script here for one to try. You'll need to add
    Code:
    up /path/to/openvpn-tun-up-down.sh
    down /path/to/openvpn-tun-up-down.sh
    to your client OpenVPN config, however you do that in Viscosity. Also, you'll want to add
    Code:
    push "dhcp-option DNS <lan_ip_of_server_router>"
    to the Custom Config of the server router.
     
  5. jiml

    jiml Addicted to LI Member

    Ok I will break down my configuration completely. Still getting the dropped packets with the changes.

    Home:
    WAN xxx.xxx.203.9
    Router ip: 192.168.15.1
    netmask: 255.255.255.0
    OpenVPN Server Configuration:
    TUN
    UDP
    4443
    Automatic
    TLS
    Disabled
    VPN subnet/netmask: 10.8.0.0/255.255.255.0

    Work:
    WAN: xxx.xxx.247.82
    Router ip: 192.168.1.1
    netmask: 255.255.255.0
    jimmacbook en0 ip:192.168.1.25
    jimmacbook tun ip: 10.8.0.6
    Viscosity configuration:
    TUN
    udp
    4443
    Enable DNS Support(this does something similar as your scripts do. It adds the DNS settings on the client to reference the one through the tunnel)
    Send all traffic over VPN connection

    Packets are still being dropped and as before if I use the local DNS, I can still web browse through the tunnel. I can also remote desktop in various computers on the home network. So it seems only the packets intended for the router's DNS get dropped.

    EDIT: This is actual config generated by Viscosity that is used when it calls openvpn

    persist-key
    tls-client
    remote xxxxx.homeip.net 4443
    proto udp
    ca ca.crt
    redirect-gateway def1
    dev tun
    persist-tun
    cert cert.crt
    comp-lzo
    nobind
    key key.key
    pull

    Then it runs a DNS script for doing the modification of DNS settings.


    EDIT2:

    Just copied that exact configuration that Viscosity generates to my Windows Virtual machine running in VMWARE.

    It connected fine and I had the same problem. I could surf the web if I changed the DNS to do local lookups. BTW, I am using the same certs/keys of course.

    The 172.16 address is the NAT'ed VMWare address.

    I see in the server log:
    Apr 3 10:56:30 unknown daemon.notice openvpn[23883]: jimmacbook/150.125.247.82:57082 MULTI: bad source address from client [172.16.249.128], packet dropped
     
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Sorry, I'm out of ideas. The problem appears to be on your client, as the server should see things coming from 10.8.0.6, not 192.168.1.25. If there is a Viscosity forum/IRC, you may try asking there.
     
  7. jiml

    jiml Addicted to LI Member

    Check my edit. This is happening with the exact configuration file used in Windows.

    Here is my configuration in windows:

    ca ca.crt
    cert client.crt
    key client.key
    persist-key
    tls-client
    remote xxxx.homeip.net 4443
    proto udp
    redirect-gateway def1
    dev tun
    persist-tun
    comp-lzo
    nobind
    pull
     
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I'm afraid I don't have any personal experience routing internet traffic or DNS over VPN (I only use it for remote LAN access), so I'm kind of shooting in the dark here. However, a couple of google searches has indicated that at least Windows incorrectly tries to bypass the tunnel when trying to reach the DNS server, causing what you see (wrong source address). OS X may have the same flaw. What I've seen indicates that using TAP corrects this. Could you give that a shot?
     
  9. jiml

    jiml Addicted to LI Member

    I originally went with TAP. My problem is that no traffic flowed over the VPN. So lets try this with windows since it is straight openvpn.

    So if I just change it to TAP on the client and the server. Leave everything else exactly the same. DHCP is enabled on the server openvpn config.

    I go to connect on my windows machine and I get an ip of 192.168.15.107

    The log is:

    Fri Apr 03 12:19:49 2009 OpenVPN 2.1_beta7 Win32-MinGW [SSL] [LZO2] built on Nov 12 2005
    Fri Apr 03 12:19:49 2009 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
    Fri Apr 03 12:19:49 2009 LZO compression initialized
    Fri Apr 03 12:19:49 2009 UDPv4 link local: [undef]
    Fri Apr 03 12:19:49 2009 UDPv4 link remote: xx.xx.203.9:4443
    Fri Apr 03 12:19:52 2009 [whserver] Peer Connection Initiated with 68.58.203.9:4443
    Fri Apr 03 12:20:05 2009 RESOLVE: Cannot resolve host address: dhcp: [HOST_NOT_FOUND] The specified host is unknown.
    Fri Apr 03 12:20:05 2009 OpenVPN ROUTE: failed to parse/resolve default gateway: dhcp
    Fri Apr 03 12:20:05 2009 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Fri Apr 03 12:20:05 2009 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0
    Fri Apr 03 12:20:05 2009 TAP-WIN32 device [Local Area Connection 6] opened: \\.\Global\{D4F39C30-FA60-4E44-9339-4B71E651338C}.tap
    Fri Apr 03 12:20:05 2009 Successful ARP Flush on interface [3] {D4F39C30-FA60-4E44-9339-4B71E651338C}
    Fri Apr 03 12:20:12 2009 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
    Fri Apr 03 12:20:12 2009 Initialization Sequence Completed

    My configuration on the windows client is:
    ca ca.crt
    cert client.crt
    key client.key
    persist-key
    tls-client
    remote xxxxx.homeip.net 4443
    proto udp
    redirect-gateway def1
    dev tap
    comp-lzo
    nobind
    pull

    Nothing goes over the VPN.

    The server log shows:

    Dec 31 19:31:10 ? daemon.notice openvpn[300]: UDPv4 link remote: xx.xx.203.9:80
    Dec 31 19:31:10 ? daemon.err openvpn[300]: TLS Error: Unroutable control packet received from xx.xx.203.9:80 (si=3 op=P_CONTROL_V1)
    Dec 31 19:31:10 ? daemon.err openvpn[300]: TLS Error: Unroutable control packet received from xx.xx.203.9:80 (si=3 op=P_CONTROL_V1)
    Dec 31 19:31:10 ? daemon.err openvpn[300]: TLS Error: Unroutable control packet received from xx.xx.203.9:80 (si=3 op=P_CONTROL_V1)
    Dec 31 19:31:10 ? daemon.err openvpn[300]: TLS Error: Unroutable control packet received from xx.xx.203.9:80 (si=3 op=P_CONTROL_V1)
    Dec 31 19:31:11 ? daemon.err openvpn[300]: TLS Error: Unroutable control packet received from xx.xx.203.9:80 (si=3 op=P_CONTROL_V1)
     
  10. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The version of OpenVPN client you're using is quite old (over three years) and doesn't understand "redirect-gateway dhcp". That is causing the the problems seen there. You can either download newer verison or work around this by unchecking "DHCP" under "Client address pool" in the server config and entering an IP range.
     
  11. jiml

    jiml Addicted to LI Member

    Updated my client. Still no traffic flows over the VPN

    Fri Apr 03 13:26:38 2009 OpenVPN 2.1_rc15 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 19 2008
    Fri Apr 03 13:26:38 2009 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
    Fri Apr 03 13:26:38 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Fri Apr 03 13:26:39 2009 LZO compression initialized
    Fri Apr 03 13:26:39 2009 UDPv4 link local: [undef]
    Fri Apr 03 13:26:39 2009 UDPv4 link remote: xx.xx.203.9:4443
    Fri Apr 03 13:26:41 2009 [whserver] Peer Connection Initiated with xx.xx.203.9:4443
    Fri Apr 03 13:26:42 2009 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Fri Apr 03 13:26:42 2009 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0
    Fri Apr 03 13:26:42 2009 TAP-WIN32 device [Local Area Connection 7] opened: \\.\Global\{AF026BD9-9B7C-449E-9B33-E1E794E5FB14}.tap
    Fri Apr 03 13:26:42 2009 Successful ARP Flush on interface [131075] {AF026BD9-9B7C-449E-9B33-E1E794E5FB14}
    Fri Apr 03 13:27:17 2009 Warning: route gateway is not reachable on any active network adapters: 0.0.0.0
    Fri Apr 03 13:27:17 2009 Warning: route gateway is not reachable on any active network adapters: 0.0.0.0
    SYSTEM ROUTING TABLE
    0.0.0.0 0.0.0.0 172.16.249.2 p=0 i=2 t=4 pr=3 a=9283 h=0 m=10/-1/-1/-1/-1
    0.0.0.0 0.0.0.0 192.168.15.1 p=0 i=131075 t=4 pr=3 a=27 h=0 m=30/-1/-1/-1/-1
    68.58.203.9 255.255.255.255 172.16.249.2 p=0 i=2 t=4 pr=3 a=0 h=0 m=1/-1/-1/-1/-1
    127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=184256 h=0 m=1/-1/-1/-1/-1
    169.254.0.0 255.255.0.0 172.16.249.128 p=0 i=2 t=3 pr=3 a=9281 h=0 m=30/-1/-1/-1/-1
    172.16.249.0 255.255.255.0 172.16.249.128 p=0 i=2 t=3 pr=2 a=9285 h=0 m=10/-1/-1/-1/-1
    172.16.249.128 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=9285 h=0 m=10/-1/-1/-1/-1
    172.16.255.255 255.255.255.255 172.16.249.128 p=0 i=2 t=3 pr=2 a=9285 h=0 m=10/-1/-1/-1/-1
    192.168.15.0 255.255.255.0 192.168.15.109 p=0 i=131075 t=3 pr=2 a=30 h=0 m=30/-1/-1/-1/-1
    192.168.15.109 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=30 h=0 m=30/-1/-1/-1/-1
    192.168.15.255 255.255.255.255 192.168.15.109 p=0 i=131075 t=3 pr=2 a=30 h=0 m=30/-1/-1/-1/-1
    224.0.0.0 240.0.0.0 172.16.249.128 p=0 i=2 t=3 pr=2 a=9285 h=0 m=10/-1/-1/-1/-1
    224.0.0.0 240.0.0.0 192.168.15.109 p=0 i=131075 t=3 pr=2 a=30 h=0 m=30/-1/-1/-1/-1
    255.255.255.255 255.255.255.255 172.16.249.128 p=0 i=2 t=3 pr=2 a=184256 h=0 m=1/-1/-1/-1/-1
    255.255.255.255 255.255.255.255 192.168.15.109 p=0 i=131075 t=3 pr=2 a=190 h=0 m=1/-1/-1/-1/-1
    255.255.255.255 255.255.255.255 192.168.15.109 p=0 i=65541 t=3 pr=2 a=184255 h=0 m=1/-1/-1/-1/-1
    SYSTEM ADAPTER LIST
    TAP-Win32 Adapter V9 - Teefer2 Miniport
    Index = 131075
    GUID = {AF026BD9-9B7C-449E-9B33-E1E794E5FB14}
    IP = 192.168.15.109/255.255.255.0
    MAC = 00:ff:af:02:6b:d9
    GATEWAY = 192.168.15.1/0.0.0.0
    DHCP SERV = 192.168.15.1
    DHCP LEASE OBTAINED = Fri Apr 03 13:26:47 2009
    DHCP LEASE EXPIRES = Sat Apr 04 13:26:47 2009
    DNS SERV = 192.168.15.1
    Juniper Network Connect Virtual Adapter - Deterministic Network Enhancer Miniport
    Index = 65541
    GUID = {70DCD026-0499-4376-8C11-D506CF6BF2C4}
    IP = 0.0.0.0/0.0.0.0
    MAC = 00:ff:d8:2a:94:86
    GATEWAY =
    DHCP SERV = 150.125.138.6
    DHCP LEASE OBTAINED = Tue Mar 10 10:48:12 2009
    DHCP LEASE EXPIRES = Tue Mar 17 10:48:12 2009
    DNS SERV =
    VMware Accelerated AMD PCNet Adapter - Teefer2 Miniport
    Index = 2
    GUID = {99981CA2-A965-4CAF-B4EC-DDB642B015E9}
    IP = 172.16.249.128/255.255.255.0
    MAC = 00:0c:29:f3:3c:91
    GATEWAY = 172.16.249.2/0.0.0.0
    DHCP SERV = 172.16.249.254
    DHCP LEASE OBTAINED = Fri Apr 03 13:22:33 2009
    DHCP LEASE EXPIRES = Fri Apr 03 13:52:33 2009
    PRI WINS = 172.16.249.2/0.0.0.0
    SEC WINS = 0.0.0.0/0.0.0.0
    DNS SERV = 172.16.249.2
    Fri Apr 03 13:27:17 2009 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )
     
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Try the workaround I mentioned before.
     
  13. jiml

    jiml Addicted to LI Member

    Thank you so much for your help.

    Unchecking the DHCP fixed it.

    I fought for days trying to get TAP to work. I gave up and switched to TUN and it partially worked so I figured I would try to get it completely working.

    Again, thanks for your help.
     
  14. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Glad you got something working! And, I learned something new with Windows/OSX DNS trying (unsuccessfully) to bypass the TUN tunnel. :smile:
     

Share This Page