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

Site-to-Site VPN can ping from router but not from inside network

Discussion in 'Tomato Firmware' started by mcbsys, Nov 9, 2011.

  1. mcbsys

    mcbsys Networkin' Nut Member

    Hi,

    Trying to set up an OpenVPN between an E2000 and an E3000. I'm using a Toastman build of TomatoUSB 1.28.

    E2000 Server LAN: 192.168.100.x
    (running Tomato Firmware v1.28.4407 MIPSR2-Toastman-VLAN-RT K26 VPN)
    WAN provided by Cox Internet

    E3000 Client LAN: 192.168.200.x
    (running Tomato Firmware v1.28.4407 MIPSR2-Toastman-VLAN-RT K26 USB VPN)
    WAN provided by DSL Extreme

    These builds do include extra VLAN functionality but I'm trying to do the VPN on the primary LAN (br0, VLAN 1).

    Each network has a device on .2 (192.168.100.2 and 192.168.200.2 respectively).

    Closely followed this guide:

    http://www.wasagacomputers.com/home...te-vpn-using-tomato-firmware-and-openvpn.html

    According to the Status pages, the VPN is established.

    If I go to Tools > Ping on the client router, I can ping 192.168.100.2 (ping past router to device).

    If I go to Tools > Ping on the server router, I can ping 192.168.200.2 (ping past router to device).

    However if I try to ping the server router or device from a device inside the client network, it doesn't work. Ditto the other way.

    These routers replace two Netgear FVS318s which had IPSec VPN working fine. In other words, I don't think client firewalls are the issue; I've tried disabling a firewall and pinging "dumb" devices (like a print server) without success.

    What am I missing? How do I get the traffic to go all the way from _inside_ the server network to the client network and vice versa?

    Setup details below. IP addresses changed to protect the guilty :).

    Thanks in advance for your help!

    Mark Berry
    MCB Systems

    SERVER setup

    Server1 > Basic
    Start with WAN [check]
    Interface Type TUN
    Protocol UDP
    Port 1194
    Firewall Automatic
    Authorization Mode TLS
    Extra HMAC authorization (tls-auth) Disabled
    VPN subnet/netmask 10.8.0.0/255.255.255.0

    Server1 > Advanced
    Poll Interval 0
    Push LAN to clients [check]
    Direct clients to redirect Internet traffic [blank]
    Respond to DNS [blank]
    Encryption cipher Use Default
    Compression Adaptive
    TLS Renegotiation Time -1
    Manage Client-Specific Options [check]
    Allow Client<->Client [check]
    Allow Only These Clients [check]

    Enable Common Name Subnet Netmask Push
    [check] ClientName_VPNClient 192.168.200.0 255.255.255.0 [check]

    Server1 > Status
    Client List
    Common Name Real Address Virtual Address Bytes Received Bytes Sent Connected Since
    ClientName_VPNClient 66.154.223.153:25975 10.8.0.6 8555 10041 Wed Nov 9 13:52:15 2011

    Routing Table
    Virtual Address Common Name Real Address Last Ref
    192.168.200.0/24 ClientName_VPNClient 66.154.223.153:25975 Wed Nov 9 13:52:16 2011
    10.8.0.6 ClientName_VPNClient 66.154.223.153:25975 Wed Nov 9 14:01:31 2011

    General Statistics
    Name Value
    Max bcast/mcast queue length 0

    Port Forwarding (per instructions; needed?)

    On Proto Src Address Ext Ports Int Port Int Address Description
    [check] UDP 1194 1194 192.168.100.1 Site-to-Site OpenVPN

    Advanced > Routing

    Current Routing Table
    Destination Gateway / Next Hop Subnet Mask Metric Interface
    68.117.14.1 * 255.255.255.255 0 vlan2 (WAN)
    10.8.0.2 * 255.255.255.255 0 tun21
    192.168.100.0 * 255.255.255.0 0 br0 (LAN)
    10.0.0.0 * 255.255.255.0 0 br1 (LAN1)
    10.8.0.0 10.8.0.2 255.255.255.0 0 tun21
    192.168.200.0 10.8.0.2 255.255.255.0 0 tun21
    68.117.14.0 * 255.255.252.0 0 vlan2 (WAN)
    127.0.0.0 * 255.0.0.0 0 lo
    default 68.117.14.1 0.0.0.0 0 vlan2 (WAN)

    CLIENT setup

    Client1 > Basic
    Start with WAN [check]
    Interface Type TUN
    Protocol UDP
    Server Address/Port [external fqdn of server]:1194
    Firewall Automatic
    Authorization Mode TLS
    Extra HMAC authorization (tls-auth) Disabled
    Create NAT on tunnel [blank]

    Client1 > Advanced
    Poll Interval 0
    Redirect Internet traffic Gateway: [blank]
    Accept DNS configuration Disabled
    Encryption cipher Use Default
    Compression Adaptive
    TLS Renegotiation Time -1
    Connection retry 30
    Custom Configuration [blank]

    Advanced > Routing
    Current Routing Table
    Destination Gateway / Next Hop Subnet Mask Metric Interface
    10.8.0.5 * 255.255.255.255 0 tun11
    66.154.223.1 * 255.255.255.255 0 vlan2 (WAN)
    192.168.100.0 10.8.0.5 255.255.255.0 0 tun11
    66.154.223.0 * 255.255.255.0 0 vlan2 (WAN)
    10.0.1.0 * 255.255.255.0 0 br1 (LAN1)
    10.8.0.0 10.8.0.5 255.255.255.0 0 tun11
    192.168.200.0 * 255.255.255.0 0 br0 (LAN)
    127.0.0.0 * 255.0.0.0 0 lo
    default 66.154.223.1 0.0.0.0 0 vlan2 (WAN)
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Things look generally okay to me. I've never worked with multiple VLANs + TomatoVPN before, so I don't know how well they play together.

    A few things to try/check:
    • Your devices don't have routes configured for the remote subnet, do they? Without further configuration, it's expected that the LAN devices' default route will be used, and that will land them at the TomatoVPN router (who will route it over the VPN).
    • Try changing the VPN subnet to 172.22.0.0/24 (or something in that private space). Some network stacks do really weird things when there are two 10.x.x.x subnets (even if they don't overlap).
    • Use traceroute/tracert in addition to ping. It might give you an idea as to where the packets are going astray (eg, if you do it from a LAN device and it looks like it tries to go out the WAN)
    • Based on the routing table from the server's VPN status page, it looks like you got it right. However, double check that the CommonName in the client-specific options table is exactly right (also, check the server router's logs to make sure it's finding the client-config-dir options). If it's different at all, you'd get the symptoms you're experiencing (it works fine router->remoteLAN, but not from the LAN->remoteAnything).
     
  3. mcbsys

    mcbsys Networkin' Nut Member

    Dear SgtPepper,

    Thanks very much for your reply.

    No, there are no mappings in the clients AFAIK. How would I check that? With the FVS318s, if the VPN was up, I could ping the remote subnet; when it got hung occasionally, no ping. Once I restarted the VPN, I could ping again.

    I'm pretty sure the CommonName is correct. I had it wrong initially and no connection at all.

    Before changes:

    The (failed) traceroute from the server LAN to client LAN just gets stuck on the server's gateway.
    The (successful) traceroute from the server router to the client LAN shows two hops: 10.8.0.6 and 192.68.0.2.

    After the traceroutes, the VPN Server Status shows something odd. First, there are now three lines. But check out the first virtual address--it ends in "C". That can't be normal?

    Code:
    Client List
    
    Common Name Real Address Virtual Address Bytes Received Bytes Sent Connected Since
    ClientName_VPNClient 66.154.223.153:25975 10.8.0.6 131459 142809 Wed Nov 9 13:52:15 2011
    
    Routing Table
    
    Virtual Address Common Name Real Address Last Ref
    192.168.200.2C ClientName_VPNClient 66.154.223.153:25975 Wed Nov 9 21:26:00 2011
    192.168.200.0/24 ClientName_VPNClient 66.154.223.153:25975 Wed Nov 9 13:52:16 2011
    10.8.0.6 ClientName_VPNClient 66.154.223.153:25975 Wed Nov 9 21:25:59 2011
    
    General Statistics
    
    Name Value
    Max bcast/mcast queue length 0
    Okay, the VPN subnet/netmask is interesting, especially since each network has a VLAN 3 (LAN1 / br1) in the 10.x.x.x range (mostly used to set up guest wireless). I thought the 255.255.255.0 netmask would limit each range of addresses but let's try 172.22.0.0/24...

    Stand by for the big test...

    Server LAN to client LAN: nope
    Server LAN to client router: nope
    Client LAN to server LAN: nope
    Client LAN to server router: nope

    I pulled the last 100 lines of the server's log. I don't see "client-config-dir". Below is the log since I started the testing above.

    What's next? Thanks again for your help!

    Mark Berry

    MCB Systems

    Code:
    Nov  9 21:00:01 unknown syslog.info root: -- MARK --
    Nov  9 21:25:05 unknown daemon.notice openvpn[1923]: MULTI: Learn: 192.168.200.2 -> ClientName_VPNClient/66.154.223.153:25975
    Nov  9 21:34:54 unknown daemon.notice openvpn[1923]: MULTI: Learn: 192.168.200.2 -> ClientName_VPNClient/66.154.223.153:25975
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: TCP/UDP: Closing socket
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: /sbin/route del -net 192.168.200.0 netmask 255.255.255.0
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: Closing TUN/TAP interface
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: /sbin/ifconfig tun21 0.0.0.0
    Nov  9 21:42:52 unknown daemon.notice openvpn[1923]: SIGTERM[hard,] received, process exiting
    Nov  9 21:42:53 unknown user.info kernel: tun: Universal TUN/TAP device driver, 1.6
    Nov  9 21:42:53 unknown user.info kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
    Nov  9 21:42:53 unknown user.info kernel: device tun21 entered promiscuous mode
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: OpenVPN 2.1.1 mipsel-unknown-linux-gnu [SSL] [LZO2] [EPOLL] built on Oct 10 2011
    Nov  9 21:42:53 unknown daemon.warn openvpn[2433]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: Diffie-Hellman initialized with 1024 bit key
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: TUN/TAP device tun21 opened
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: TUN/TAP TX queue length set to 100
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: /sbin/ifconfig tun21 172.22.0.1 pointopoint 172.22.0.2 mtu 1500
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 172.22.0.2
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: /sbin/route add -net 172.22.0.0 netmask 255.255.255.0 gw 172.22.0.2
    Nov  9 21:42:53 unknown daemon.notice openvpn[2433]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: Socket Buffers: R=[112640->131072] S=[112640->131072]
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: UDPv4 link local (bound): [undef]:1194
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: UDPv4 link remote: [undef]
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: MULTI: multi_init called, r=256 v=256
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: IFCONFIG POOL: base=172.22.0.4 size=62
    Nov  9 21:42:53 unknown daemon.notice openvpn[2442]: Initialization Sequence Completed
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: TCP/UDP: Closing socket
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: /sbin/route del -net 172.22.0.0 netmask 255.255.255.0
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: /sbin/route del -net 192.168.200.0 netmask 255.255.255.0
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: Closing TUN/TAP interface
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: /sbin/ifconfig tun21 0.0.0.0
    Nov  9 21:42:54 unknown daemon.notice openvpn[2442]: SIGTERM[hard,] received, process exiting
    Nov  9 21:44:34 unknown user.info kernel: tun: Universal TUN/TAP device driver, 1.6
    Nov  9 21:44:34 unknown user.info kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
    Nov  9 21:44:34 unknown user.info kernel: device tun21 entered promiscuous mode
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: OpenVPN 2.1.1 mipsel-unknown-linux-gnu [SSL] [LZO2] [EPOLL] built on Oct 10 2011
    Nov  9 21:44:34 unknown daemon.warn openvpn[2489]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: Diffie-Hellman initialized with 1024 bit key
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: TUN/TAP device tun21 opened
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: TUN/TAP TX queue length set to 100
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: /sbin/ifconfig tun21 172.22.0.1 pointopoint 172.22.0.2 mtu 1500
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 172.22.0.2
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: /sbin/route add -net 172.22.0.0 netmask 255.255.255.0 gw 172.22.0.2
    Nov  9 21:44:34 unknown daemon.notice openvpn[2489]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: Socket Buffers: R=[112640->131072] S=[112640->131072]
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: UDPv4 link local (bound): [undef]:1194
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: UDPv4 link remote: [undef]
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: MULTI: multi_init called, r=256 v=256
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: IFCONFIG POOL: base=172.22.0.4 size=62
    Nov  9 21:44:34 unknown daemon.notice openvpn[2499]: Initialization Sequence Completed
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: MULTI: multi_create_instance called
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Re-using SSL/TLS context
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 LZO compression initialized
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Nov  9 21:44:36 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 TLS: Initial packet from 66.154.223.153:32148, sid=48d15f5a df9c0046
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 VERIFY OK: depth=1, /C=US/ST=CA/L=SanDiego/O=My_Company/OU=System_Administration/CN=OpenVPN-CA/name=My_Name/emailAddress=sysadmin@mydomain.com
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 VERIFY OK: depth=0, /C=US/ST=CA/L=SanDiego/O=Client_Name/OU=System_Administration/CN=ClientName_VPNClient/name=My_Name/emailAddress=sysadmin@clientdomain.org
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: 66.154.223.153:32148 [ClientName_VPNClient] Peer Connection Initiated with 66.154.223.153:32148
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 OPTIONS IMPORT: reading client specific options from: ccd/ClientName_VPNClient
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 MULTI: Learn: 172.22.0.6 -> ClientName_VPNClient/66.154.223.153:32148
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 MULTI: primary virtual IP for ClientName_VPNClient/66.154.223.153:32148: 172.22.0.6
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 MULTI: internal route 192.168.200.0/24 -> ClientName_VPNClient/66.154.223.153:32148
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 MULTI: Learn: 192.168.200.0/24 -> ClientName_VPNClient/66.154.223.153:32148
    Nov  9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 REMOVE PUSH ROUTE: 'route 192.168.200.0 255.255.255.0'
    Nov  9 21:44:41 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 PUSH: Received control message: 'PUSH_REQUEST'
    Nov  9 21:44:41 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/66.154.223.153:32148 SENT CONTROL [ClientName_VPNClient]: 'PUSH_REPLY,route 192.168.100.0 255.255.255.0,route 172.22.0.0 255.255.255.0,topology net30,ping 15,ping-restart 60,ifconfig 172.22.0.6 172.22.0.5' (status=1)
     
  4. mcbsys

    mcbsys Networkin' Nut Member

    Hmm...wonder if this could be relevant. Here is a screenshot of Advanced > LAN Access from the server. Is this a standard screen? Or is the VLAN add-in doing something to restrict LAN access? The Source and Destination drop-downs only list br0 and br1, with br2 and br3 grayed out, nothing about tunnels... IIRC, one can add to this table to grant LAN access to the VLAN, but I specifically wanted to keep the guest wireless off the LAN, so I didn't change the default below.

    LAN Access.png
     
  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    FYI: These are the lines in the log I wanted to make sure were there
    Code:
    Nov 9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX OPTIONS IMPORT: reading client specific options from: ccd/ClientName_VPNClient
    Nov 9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX MULTI: Learn: 172.22.0.6 -> ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX
    Nov 9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX MULTI: primary virtual IP for ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX: 172.22.0.6
    Nov 9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX MULTI: internal route 192.168.200.0/24 -> ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX
    Nov 9 21:44:38 unknown daemon.notice openvpn[2499]: ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX MULTI: Learn: 192.168.200.0/24 -> ClientName_VPNClient/XXX.XXX.XXX.XXX:XXXXX
    Also, the C after the device's IP is normal. That happens when the device is in the learned remote subnet, but not explicitly routed.

    When you say the failed traceroute "gets stuck on the server's gateway", do you mean the in the server (the LAN device's gateway) or in an upstream router (the server's gateway, the gateway the server is configured to use)?

    That is not a standard screen, and I suspect it is the VLAN stuff that is causing problems here. Could you post the output of
    Code:
    iptables -t mange -nvL
    iptables -t nat -nvL
    iptables -t filter -nvL
     
  6. mcbsys

    mcbsys Networkin' Nut Member

    The local LAN's gateway:
    Code:
    C:\>tracert 192.168.200.2
    Tracing route to 192.168.200.2 over a maximum of 30 hops
      1    <1 ms    <1 ms    <1 ms  192.168.100.1
      2    *        *        *    Request timed out.
      3    *        *        *    Request timed out.
      4    *        *        *    Request timed out.
    Here are the results from the router running the VPN server. Did you want the client's results as well?
    Code:
    iptables v1.3.8: can't initialize iptables table `mange': Table does not exist (do you need to insmod?)
    Perhaps iptables or your kernel needs to be upgraded.
    Chain PREROUTING (policy ACCEPT 15847 packets, 1327K 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
    1200 90309 WANPREROUTING  all  --  *      *      0.0.0.0/0            68.117.14.107
        0    0 DROP      all  --  vlan2  *      0.0.0.0/0            192.168.100.0/24
        0    0 DROP      all  --  vlan2  *      0.0.0.0/0            10.0.0.0/24
    
    Chain POSTROUTING (policy ACCEPT 12 packets, 1372 bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.30      tcp dpt:888 to:68.117.14.107
        1    52 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.11      tcp dpt:5993 to:68.117.14.107
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.2        tcp dpt:81 to:68.117.14.107
        2  104 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.2        tcp dpt:443 to:68.117.14.107
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.101      tcp dpt:32751 to:68.117.14.107
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.11      tcp dpt:3391 to:68.117.14.107
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.2        tcp dpt:987 to:68.117.14.107
        0    0 SNAT      tcp  --  *      *      192.168.100.0/24      192.168.100.2        tcp dpt:1723 to:68.117.14.107
        0    0 SNAT      udp  --  *      *      192.168.100.0/24      192.168.100.1        udp dpt:1194 to:68.117.14.107
    14100  870K MASQUERADE  all  --  *      vlan2  0.0.0.0/0            0.0.0.0/0
    
    Chain OUTPUT (policy ACCEPT 58 packets, 5409 bytes)
    pkts bytes target    prot opt in    out    source              destination
    
    Chain WANPREROUTING (1 references)
    pkts bytes target    prot opt in    out    source              destination
      20  1074 DNAT      icmp --  *      *      0.0.0.0/0            0.0.0.0/0          to:192.168.100.1
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:888 to:192.168.100.30
        1    52 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:5993 to:192.168.100.11
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:81 to:192.168.100.2
        4  212 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:443 to:192.168.100.2
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:32751 to:192.168.100.101
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:3391 to:192.168.100.11
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:987 to:192.168.100.2
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:1723 to:192.168.100.2
      22  924 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:1194 to:192.168.100.1:1194
    Chain INPUT (policy DROP 1463 packets, 75827 bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 ACCEPT    all  --  tun21  *      0.0.0.0/0            0.0.0.0/0
    3885  318K ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:1194
        0    0 DROP      all  --  br0    *      0.0.0.0/0            68.117.14.107
        0    0 DROP      all  --  br1    *      0.0.0.0/0            68.117.14.107
      150  5632 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    7336 2758K ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
        6  300 shlimit    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:22 state NEW
        0    0 shlimit    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:23 state NEW
      18  1315 ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0
    5877  631K ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0
      243 22422 ACCEPT    all  --  br1    *      0.0.0.0/0            0.0.0.0/0
      962  341K ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp spt:67 dpt:68
    
    Chain FORWARD (policy DROP 204 packets, 13152 bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 ACCEPT    all  --  tun21  *      0.0.0.0/0            0.0.0.0/0
      232 51581            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 10.0.0.0/255.255.255.0 name: lan1
    523K  330M            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.100.0/255.255.255.0 name: lan
      241  162K 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
      66  2640 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    12625  665K TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    508K  329M ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
        2  108 wanin      all  --  vlan2  *      0.0.0.0/0            0.0.0.0/0
    14022  864K wanout    all  --  *      vlan2  0.0.0.0/0            0.0.0.0/0
    14004  862K ACCEPT    all  --  br0    vlan2  0.0.0.0/0            0.0.0.0/0
      18  1100 ACCEPT    all  --  br1    vlan2  0.0.0.0/0            0.0.0.0/0
    
    Chain OUTPUT (policy ACCEPT 13207 packets, 6497K bytes)
    pkts bytes target    prot opt in    out    source              destination
    
    Chain shlimit (2 references)
    pkts bytes target    prot opt in    out    source              destination
        6  300            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
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.30      tcp dpt:888
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.11      tcp dpt:5993
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.2        tcp dpt:81
        2  108 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.2        tcp dpt:443
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.101      tcp dpt:32751
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.11      tcp dpt:3391
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.2        tcp dpt:987
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.100.2        tcp dpt:1723
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.100.1        udp dpt:1194
    
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination          
    Thanks again,
     
  7. mcbsys

    mcbsys Networkin' Nut Member

  8. mcbsys

    mcbsys Networkin' Nut Member

    With the help provided here, got VPN working together with VLAN.

    On both the client and sever, my main LAN (that I want to share across the VPN) is on br0. After checking the tunnel names under Advanced > Routing, on the OpenVPN server router, I ran:
    Code:
    iptables -A FORWARD -i br0 -o tun21 -j ACCEPT
    and on the OpenVPN client router I ran
    Code:
    iptables -A FORWARD -i br0 -o tun11 -j ACCEPT
    Voila! Bi-directional pings from server's LAN to client's LAN and vice-versa.

    Any suggestions on how to make those settings sticky? Just paste the commands into Administration > Scripts > WAN Up? Will the tunnel names always be the same?

    Thanks and regards,
     
  9. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The tunnel names will not always be there. However, the rules will still work even if you set them before the interface exists (it just won't ever match anything until the tun interface is created).
    Put them in scripts->firewall.

    Normal TomatoVPN opens up the firewall for inbound tunnel traffic but assumes there are existing rules (there's normally a rule that accepts anything coming from br0) that wil work for outbound traffic. The VLAN code changes the firewall rules in a way that breaks that assumption. The help you received from Teaman is the correct fix.

    Since it will be harmless (though, unnecessary) in the non-VLAN case, I'll add it to TomatoVPN code. So, it's likely that in the future you won't need those rules in your firewall script.
     
    mcbsys likes this.
  10. mcbsys

    mcbsys Networkin' Nut Member

    SgtPepper,

    Thanks for the confirmation and instructions.

    I wasn't asking if the tunnel will always be there, but if it will have the same name whenever it is created. I.e. will it work to always forward to tun21 on the server and tun11 on the client? Does tun11 correspond to VPN Client 1 and tun21 correspond to Server 1?

    Thanks for considering adding this to the VPN code. Note that teaman has already updated his "lan isolation" code (see this post) though I'm not clear on whether it already covers this issue.

    The one suggestion/request I would have is to keep in mind that if I'm using VLANs, I don't necessarily want the VPN tunnel mapped to the primary LAN. Maybe the VPN should only be available from my isolated VLAN3, for example. Or maybe it should go to multiple VLANs. Would it make sense for one of you to update the screen I pasted in post #4 above, so that I can use a GUI to choose which LAN(s) forward to which VPN tunnel(s)? A default to cover the common case of mapping to the primary LAN seems like a good idea, but it would be nice to have flexibility.

    You and teaman have made this a Happy Tomato week! Thanks for all your help,
     
  11. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Yes, exactly. For reasons just as yours, I made it always use the same device names. tun11==Client1, tun12==Client2,tun21==Server1,tun22=Server2
     
    JValmont likes this.
  12. mcbsys

    mcbsys Networkin' Nut Member

  13. 3lixy

    3lixy Networkin' Nut Member

    Hey guys i am also having a simillar problem.

    Setup:
    Server OpenVPN-AS - devices on local LAN (192.168.0.0) Site A
    Client Router: tomato-ND-1.28.7632.1-Toastman-VLAN-IPT-ND-VPN (192.168.1.0) Site B

    I can ping devices on server local lan 192.168.0.0 from client router. However I cannot ping devices on the server local lan from the client routers lan.

    There is not a route on the the computer on the client lan that would re-direct the request away from the client router

    A tracert fails after hitting the router (192.168.1.1)
    C:\Users\Anon>tracert 192.168.0.12

    Tracing route to 192.168.0.12 over a maximum of 30 hops

    1 <1 ms <1 ms <1 ms 9Parry [192.168.1.1]
    2 * * * Request timed out.
    3 * * * Request timed out.
    4 * * * Request timed out.
    5 * * * Request timed out.
    6 * * * Request timed out.
    7 * * * Request timed out.
    8 * ^C

    Ping times out.

    Routing Table: (note the router is currently in wireless client mode - currently I am living in a shared house and am connection my WRT54GL to the sky router wirelessly. I am aware this is double natting but this is all I can do for the moment if i want to 'play' with vpn etc..)

    DestinationGateway / Next HopSubnet MaskMetricInterface
    192.168.5.1*255.255.255.2550eth1 (WAN)
    192.168.5.0*255.255.255.00eth1 (WAN)
    192.168.1.0*255.255.255.00br0 (LAN)
    192.168.0.05.5.8.1255.255.255.0101tun11
    5.5.8.0*255.255.254.00tun11
    5.5.0.05.5.8.1255.255.240.0101tun11
    127.0.0.0*255.0.0.00lo
    default192.168.5.10.0.0.00eth1 (WAN)

    Here is the IP Tables dump:

    It seems to that the packets sent from the computer on the client lan are not being directed through the tunnel.

    Code:
    Chain INPUT (policy DROP 39 packets, 3678 bytes)
    pkts bytes target prot opt in out source destination
    5 420 ACCEPT all -- tun11 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun11 * 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    801 157K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    1 69 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    190 12507 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT all -- tun11 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun11 * 0.0.0.0/0 0.0.0.0/0
    7280 3655K all -- * * 0.0.0.0/0 0.0.0.0/0 account: network/netmask: 192.168.1.0/255.255.255.0 name: lan
    0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    424 22008 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    6985 3635K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 wanin all -- eth1 * 0.0.0.0/0 0.0.0.0/0
    253 16304 wanout all -- * eth1 0.0.0.0/0 0.0.0.0/0
    295 19580 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- br0 tun11 0.0.0.0/0 0.0.0.0/0
    
    Chain OUTPUT (policy ACCEPT 922 packets, 423K bytes)
    pkts bytes target prot opt in out source destination
    
    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
    
    Chain PREROUTING (policy ACCEPT 670 packets, 97997 bytes)
    pkts bytes target prot opt in out source destination
    60 3972 WANPREROUTING all -- * * 0.0.0.0/0 192.168.5.16
    0 0 DROP all -- eth1 * 0.0.0.0/0 192.168.1.0/24
    
    Chain POSTROUTING (policy ACCEPT 15 packets, 1137 bytes)
    pkts bytes target prot opt in out source destination
    339 19713 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
    0 0 SNAT all -- * br0 192.168.1.0/24 192.168.1.0/24 to:192.168.1.1
    
    Chain OUTPUT (policy ACCEPT 120 packets, 7893 bytes)
    pkts bytes target prot opt in out source destination
    
    Chain WANPREROUTING (1 references)
    pkts bytes target prot opt in out source destination
    0 0 DNAT icmp -- * * 0.0.0.0/0 0.0.0.0/0 to:192.168.1.1
    
    Chain PREROUTING (policy ACCEPT 8539 packets, 3899K bytes)
    pkts bytes target prot opt in out source destination
    
    Chain INPUT (policy ACCEPT 1066 packets, 175K bytes)
    pkts bytes target prot opt in out source destination
    
    Chain FORWARD (policy ACCEPT 7282 packets, 3655K bytes)
    pkts bytes target prot opt in out source destination
    
    Chain OUTPUT (policy ACCEPT 1185 packets, 561K bytes)
    pkts bytes target prot opt in out source destination
    
    Chain POSTROUTING (policy ACCEPT 8467 packets, 4216K bytes)
    pkts bytes target prot opt in out source destination
    Any help welcomed
     
  14. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Did you either set up the Client-specific options properly or check the "Create NAT on tunnel" option on the client?
     
    3lixy likes this.
  15. 3lixy

    3lixy Networkin' Nut Member

    It was me being too impatient. I apologise to waste your time.

    I did not wait long enough for the router to establish the connection and do the routing etc. I had tried several combinations, last time i tried create nat on tunnel checked it did not work, this time it did. I was not waiting long enough.

    Again I apologise

    Many Thanks
    Nick
     
  16. nick antony

    nick antony Networkin' Nut Member

    Hi, i have quite the same problem. I have set up a tun vpn between 2 tomato routers both with latest shibby firmware. the server (e3000) has the br0 with ip 172.16.54.1 and a separate vLan2 (br1) at 172.16.53.1 (vlan2 is for router port4 only). The vpn client (wl500gpv2) has only a one lan (br0) with 172.16.55.1 ip. all of them have subnet 255.255.255.0.
    Now the vpn setup on the server is tun with 10.8.0.0 subnet and netmask 255.255.255.0, certificates ecc.. all correct advanced settings all enabled.
    the thing is, the vpn is working correctly.I can ping the vpn addresses 10.8.0.1(e3000) and 10.8.0.6 (wl500gpv2) from each router, and from the lan computers of each router. i can also ping from the lan computers of the client (wl500gpv2) all the devices on the Lan side of the server (e3000) .
    The problem is that i can't do the reverse. I mean, ping from the lan devices of the server (e3000) the devices on the Lan side of the client (wl500gpv2).
    I have tried the method with the firewall scripts, and port forward 1194 but without result. (Also with and without the scripts, i have the same result).
    In the routing table of the client router (wl500gpv2) i can see the routing at the 172.16.54.0 subnet at tun11, but in the server router (e3000) i can't see the routing at the 172.16.55.0 subnet on tun21.

    Any help would be appreciated.
    Thank you in advance for any response!
     
  17. SgtPepperKSU

    SgtPepperKSU Network Guru Member

  18. nick antony

    nick antony Networkin' Nut Member

  19. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The symptoms you describe strongly suggest that you have the NAT checkbox checked and/or the Client-Specific options table on the server isn't filled in correctly. Please triple check this, keeping in mind that the CommonName field must match the name used used when creating the client certificate exactly.

    If you still feel you have those covered, post the server logs from when the client connects.
     
  20. nick antony

    nick antony Networkin' Nut Member

  21. nick antony

    nick antony Networkin' Nut Member

    I have tried again everything from the beginning enabling and disabling advanced options but no result. i can ping between the vpn router-client routers and from the client LAN side the devices on the server LAN side. i cannot vice versa. hope someone figures out a solution.

    thanks
     
  22. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Your screenshot shows that you have not filled in the client-specific options table. For bi-directional communication, you need to do so.
     
  23. nick antony

    nick antony Networkin' Nut Member

    Firstly thank you for helping me. You are right about this.I tried by inserting the common name (CLIENT in my case), address subnet (172.16.50.0) and netmask(255.255.255.0), but with no result (also tried both with enabling and not the PUSH option,don't know what this do :) ). I have also completely disabled the extra HMAC option and left everything else as is. any way it did not solve the problem i had.
    i don't know i will try hard reset both and reconfigure hoping and praying to work.


    -UPDATE no result even after hard reset and same settings no possibility to ping from the server side lan devices, to the client side lan devices.
    Is there anything else to do? i don't know :/
     
  24. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Post the server logs from when the client connects.
     
  25. nick antony

    nick antony Networkin' Nut Member

    OpenVPN 2.1.1 mipsel-unknown-linux-gnu [SSL] [LZO2] [EPOLL] built on Feb 17 2012
    NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Diffie-Hellman initialized with 2048 bit key Control Channel Authentication: using 'static.key' as a free-form passphrase file Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication TLS-Auth MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ] TUN/TAP device tun21 opened TUN/TAP TX queue length set to 100 /sbin/ifconfig tun21 172.16.50.1 pointopoint 172.16.50.2 mtu 1500 /sbin/route add -net 172.16.50.0 netmask 255.255.255.0 gw 172.16.50.2 /sbin/route add -net 172.16.50.0 netmask 255.255.255.0 gw 172.16.50.2 daemon.warn openvpn[5915]: ERROR: Linux route add command failed: external program exited with error status: 1 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] Socket Buffers: R=[114688->131072] S=[114688->131072] UDPv4 link local (bound): [undef]:1194 UDPv4 link remote: [undef] MULTI: multi_init called, r=256 v=256 IFCONFIG POOL: base=172.16.50.4 size=62 Initialization Sequence Completed MULTI: multi_create_instance called 2.87.15.43:16947 Re-using SSL/TLS context 2.87.15.43:16947 LZO compression initialized 2.87.15.43:16947 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ] 2.87.15.43:16947 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] 2.87.15.43:16947 TLS: Initial packet from 2.87.15.43:16947, sid=ace5cd8e 904f52b5 2.87.15.43:16947 VERIFY OK: depth=1, /C=GR/ST=ATH/L=ATH/O=WORK/OU=VPN/CN=WORK.VPN/name=changeme/emailAddress=mail@host.domain 2.87.15.43:16947 VERIFY OK: depth=0, /C=GR/ST=ATH/L=CHA/O=WORK/OU=VPN/CN=CLIENT/name=changeme/emailAddress=mail@host.domain 2.87.15.43:16947 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 2.87.15.43:16947 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 2.87.15.43:16947 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 2.87.15.43:16947 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 2.87.15.43:16947 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 2.87.15.43:16947 [CLIENT] Peer Connection Initiated with 2.87.15.43:16947 CLIENT/2.87.15.43:16947 OPTIONS IMPORT: reading client specific options from: ccd/CLIENT CLIENT/2.87.15.43:16947 MULTI: Learn: 172.16.50.6 -> CLIENT/2.87.15.43:16947 CLIENT/2.87.15.43:16947 MULTI: primary virtual IP for CLIENT/2.87.15.43:16947: 172.16.50.6 CLIENT/2.87.15.43:16947 MULTI: internal route 172.16.50.0/24 -> CLIENT/2.87.15.43:16947 CLIENT/2.87.15.43:16947 MULTI: Learn: 172.16.50.0/24 -> CLIENT/2.87.15.43:16947 CLIENT/2.87.15.43:16947 REMOVE PUSH ROUTE: 'route 172.16.50.0 255.255.255.0' CLIENT/2.87.15.43:16947 REMOVE PUSH ROUTE: 'route 172.16.50.0 255.255.255.0' CLIENT/2.87.15.43:16947 PUSH: Received control message: 'PUSH_REQUEST' CLIENT/2.87.15.43:16947 SENT CONTROL [CLIENT]: 'PUSH_REPLY,route 172.16.54.0 255.255.255.0,dhcp-option DNS 172.16.54.1,topology net30,ping 15,ping-restart 60,ifconfig 172.16.50.6 172.16.50.5' (status=1)

    Thank you for helping me ;)
     
  26. nick antony

    nick antony Networkin' Nut Member

    anything wrong so?

    UPDATE:

    Problem solved. The problem was that in the server part, at specific client options i had to insert the subnet of the client and not of the vpn i had inserted.
    Everything works like a charm now.

    Thank you for your help.
     
  27. fersingb

    fersingb Serious Server Member

    Hi,

    this is an interesting question. Does someone have the answer to this?

    Right know I'm using a toastman build to connect to my work's OpenVPN server. It looks like the VPN is "linked" to br0/LAN. What should I do if I want to link it to br1/LAN1 ?

    Thanks,
    Boris
     

Share This Page