Tomato 140 and OpenVPN setting

Discussion in 'Tomato Firmware' started by pylsar, May 6, 2019.

  1. pylsar

    pylsar Network Newbie Member

    Hi

    I have configured a tunnel between two routers with a tomato 140 firmware

    network by server - 172.16.15.1
    network by client - 10.10.1.1

    Custom Configuration of server:
    Code:
    client-config-dir /tmp/mnt/sda1/openvpn/server/ccd
    tls-server
    dh                /tmp/mnt/sda1/openvpn/server/dh2048.pem
    ca                /tmp/mnt/sda1/openvpn/server/ca.pem
    cert              /tmp/mnt/sda1/openvpn/server/server_cert.pem
    key               /tmp/mnt/sda1/openvpn/server/server_key.pem
    route 10.10.1.0 255.255.255.0
    client-to-client
    user nobody
    group nobody
    persist-key
    persist-tun
    ccd config:
    Code:
    route 172.16.15.0 255.255.255.0
    iroute 10.10.1.0 255.255.255.0
    Custom Configuration of client:
    Code:
    ca                /tmp/mnt/sda1/openvpn/client/ca.pem
    cert              /tmp/mnt/sda1/openvpn/client/client_cert.pem
    key               /tmp/mnt/sda1/openvpn/client/client_key.pem
    user nobody
    group nobody
    From the network behind the server, I see the network behind the client. But from the network behind the client I do not see the network behind the server.

    1. What should I do to see the network behind the server?
    2. How can I create a tunnel between a normal windows computer and a router with an openVPN server by tomato 140 firmware?

    best regards!
     
  2. eibgrad

    eibgrad Network Guru Member

    IIRC, v140 has (like all current versions) the Manage Client-Specific Options to manage the CCD file. You don't need to be handling this separately. It will add the route to the kernel, create the CCD file for the specified common name of the client's cert, and add the iroute directive to that file. One of the nicer features of the tomato OpenVPN server implementation.

    In order for the network behind the client to see the network behind the server, the server either has to push that network to the client, or just specify that network as a route directive on the client config.

    # server
    push "route 172.166.15.0 255.255.255.0"

    # client
    route 172.166.15.0 255.255.255.0

    As far as your second question, what exactly are you trying to accomplish? Because that can be a bit tricky. Remember, you're typically using OpenVPN to create a tunnel so you can route between different networks. But in the case of a Windows client configuring a tunnel to the router, the client and router are on the *same* local network. And you never want the same local network on both sides of the tunnel since the client and server will each use the local network to communicate, NOT the tunnel.

    Or have I misinterpreted your intentions, and you just want that Windows client to reach a *remote* OpenVPN server on a different network?
     
    Last edited: May 6, 2019
  3. eibgrad

    eibgrad Network Guru Member

    P.S. Just remembered, there should be a "Push LAN to clients" option on the OpenVPN server config that generates the push directive for you. Might not be on by default.
     
  4. cloneman

    cloneman LI Guru Member

    In order to do a VPN with both sides able to communicate with clients on each side, I followed the following instructions:

    https://www.sparklabs.com/support/k...nvpn-server-with-tomato-router-and-viscosity/

    At the end of that guide, I needed to put 1 line in custom configuration at the server end:
    route 192.168.7.0 255.255.255.0.

    This allowed the computers at the Server network to ping back to the client network.
     
  5. eibgrad

    eibgrad Network Guru Member

    I don't see how that's possible given those instructions.

    Because OpenVPN can support *multiple* OpenVPN clients to the same OpenVPN server (PTMP, point to multipoint), simply providing a route back to the client's network is insufficient. The OpenVPN server doesn't know *which* OpenVPN client that route applies to. So you need to have an iroute directive in the CCD file for the common-name used by that particular OpenVPN client that tells the OpenVPN server to route (internally, not the kernel) that particular traffic back to that specific client.

    https://community.openvpn.net/openvpn/wiki/RoutedLans

    That's what makes OpenVPN different from the old PPTP server. When a PPTP client connects to a PPTP server, every client gets its own network interface on the server (ppp0, ppp1, etc.). So providing a route back to the client's local network is simple; just add a route to the kernel. But in the case of OpenVPN, every OpenVPN client shares one (1) network interface (e.g., tun21), and so you need the iroute directive to resolve the ambiguity.

    The only time I've seen that NOT required is in a PTP (point to point) OpenVPN tunnel, which makes sense since that particular configuration supports only one client and one server. But I don't believe you can configure a PTP tunnel w/ the tomato OpenVPN GUI.

    As I said, all that's necessary to get bidirectional/site-to-site access is to use the Manage Client-Specific Options field. It does all this dirty work for you. It's great.
     
    Last edited: May 7, 2019
    Monk E. Boy likes this.
  6. pylsar

    pylsar Network Newbie Member

    hello

    Should I use both settings or just one?

    What checkboxes do I need to put in order (in web tomato) for all clients and server to see all computers on all networks and behind the server too?

    Yes. I want to connect my laptop (OpenVPN client) to the network (and see all the computers behind the server and clients) from any place where there is Internet. I have an Openvpn for Windows client installed, but I don’t know how to set it up so that I can connect to the OpenVpn server on a router with Tomato 140 firmware.

    best regards.
     
    Last edited: May 7, 2019
  7. eibgrad

    eibgrad Network Guru Member

    One or the other, NOT both. In most cases, it makes more sense to push the server's local network(s) to the client. Having the client specify the network(s) assumes the client knows what network(s) lies behind the server. And that might not always be the case.

    IIRC, on the OpenVPN server Advanced tab of v140, there's a "Push LAN to clients" option. This is exactly the same as specifying the server push directive for the immediate local network on which the server is running (specifically, the br0 bridge). So if you use that option, there's no need for the push directive, at least NOT for that local network.

    If you have any additional local networks that are accessible over the tunnel, then you need to handle those separately w/ their own push directives.

    There is one other configuration option to consider. If either the client or server configure the tunnel as the default gateway, you don't need *any* push directives since any networks unknown to the client will be directed over the tunnel anyway, and those networks will be discoverable on the other side of the tunnel at that time.

    There should plenty of other resources available on the web for configuring your OpenVPN client on Windows. No need for me to repeat them here. But I will give a brief overview.

    You'll need to create an OpenVPN config file w/ the extension .ovpn and store it in the OpenVPN installation directory's config folder. Usually that's C:\Program Files\OpenVPN\config.

    When you start the OpenVPN client, make sure you do so w/ Administrator privileges (right-click to see that option). When the icon appears in the system tray, you'll see the configuration file you added above will be available for selection.

    As far as the configuration file itself, I've provided my own as an example.

    Code:
    client
    dev tun
    proto udp
    remote <my-public-ip> 1194
    cipher aes-256-cbc
    auth sha256
    redirect-gateway def1
    route-delay
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    <ca>
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    </ca>
    <cert>
    -----BEGIN CERTIFICATE-----
    ...
    </cert>
    <key>
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----
    </key>
    remote-cert-tls server
    comp-lzo
    verb 4
    Obviously I had to remove my particular certs and keys. And you'll have to provide your own from when you used easyrsa to generate these files. You may also have different settings for things like cipher and auth. Notice I happen to use the redirect-gateway directive on the client rather than the server. This allows the client to decide if and when it wants the default gateway changed to the VPN.

    One last thing. I do NOT recommend using the well-known OpenVPN port of 1194 for your own server. Instead, choose something more obscure, like 34198. Hackers will always try the well-known ports when probing for vulnerable systems. If not found, they are more likely to move on to another public IP then perform a port scan to find your OpenVPN server.
     
    Last edited: May 7, 2019
  8. pylsar

    pylsar Network Newbie Member

    hi

    Config now:

    Custom Configuration of server:
    Code:
    client-config-dir /tmp/mnt/sda1/openvpn/server/ccd
    tls-server
    dh                /tmp/mnt/sda1/openvpn/server/dh2048.pem
    ca                /tmp/mnt/sda1/openvpn/server/ca.pem
    cert              /tmp/mnt/sda1/openvpn/server/server_cert.pem
    key               /tmp/mnt/sda1/openvpn/server/server_key.pem
    client-to-client
    route 10.10.1.0 255.255.255.0
    push "route 172.16.15.0 255.255.255.0"
    user nobody
    group nobody
    persist-key
    persist-tun
    
    ccd server config:
    Code:
    route 172.16.15.0 255.255.255.0
    iroute 10.10.1.0 255.255.255.0
    Custom Configuration of client:
    Code:
    ca                /tmp/mnt/sda1/openvpn/client/ca.pem
    cert              /tmp/mnt/sda1/openvpn/client/client_cert.pem
    key               /tmp/mnt/sda1/openvpn/client/client_key.pem
    user nobody
    group nobody
    server route:
    Code:
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    x.x.0.1      *               255.255.255.255 UH        0 0          0 vlan2
    10.8.0.2        *               255.255.255.255 UH        0 0          0 tun21
    10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun21
    10.10.1.0       10.8.0.2        255.255.255.0   UG        0 0          0 tun21
    172.16.15.0     *               255.255.255.0   U         0 0          0 br0
    x.x.0.0      *               255.255.240.0   U         0 0          0 vlan2
    127.0.0.0       *               255.0.0.0       U         0 0          0 lo
    default         host-x-x-0-1 0.0.0.0         UG        0 0          0 vlan2 
    client route:
    Code:
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    10.8.0.5        *               255.255.255.255 UH        0 0          0 tun11
    192.168.5.1     *               255.255.255.255 UH        0 0          0 vlan2
    172.16.15.0     10.8.0.5        255.255.255.0   UG        0 0          0 tun11
    192.168.5.0     *               255.255.255.0   U         0 0          0 vlan2
    10.8.0.0        10.8.0.5        255.255.255.0   UG        0 0          0 tun11
    10.10.1.0       *               255.255.255.0   U         0 0          0 br0
    127.0.0.0       *               255.0.0.0       U         0 0          0 lo
    default         unknown         0.0.0.0         UG        0 0          0 vlan2
    I cannot see the network behind the server. Help me please.

    Maybe you need to set some rules for iptables?
     
    Last edited: May 12, 2019
  9. eibgrad

    eibgrad Network Guru Member

    One thing is obvious; you're not using the Manage Client-Specific Options feature on the OpenVPN server config to handle this issue w/ iroute. You're doing it manually and specifying your own CCD directory in the server config. And that has lead to a mistake.

    ccd server config:
    Code:
    route 172.16.15.0 255.255.255.0
    iroute 10.10.1.0 255.255.255.0
    The first line doesn't belong. That's the server's local network. That's being pushed to *all* OpenVPN clients in the server config to notify them of the server's local network. The purpose of the CCD file is to inform the server of OpenVPN client specific settings. And at the moment, the only thing the OpenVPN server needs to know is *which* OpenVPN client should have 10.10.1.0 255.255.255.255 routed to it when a device on the 172.16.15.0 255.255.255.0 network attempts to initiate a connection to that OpenVPN client's local network.

    Had you used the Manage Client-Specific Options feature, it would have created the CCD directory for you, created a file based on the common name you specified in that section, added *only* the iroute 10.0.1.0 255.255.255.0 directive to that file, and finally, added the 10.0.1.0 255.255.255.0 route to the server config file so that that route was added to the kernel's routing table when the OpenVPN server was started. ALL of that done automatically!

    Instead, you created your own CCD directory ( /tmp/mnt/sda1/openvpn/server/ccd ), presumably added a file based on the common-name of the OpenVPN client, and added both route (which was a mistake) and iroute directives.

    Now whether this is the actual reason for your current problem, I'm not sure. All of this seems to have not caused a problem as far as the kernel's routing table goes, but it may have confused the OpenVPN server itself when it saw that route command in the CCD file.

    Yes, you can do it manually if you prefer. But that assumes you know how to do it correctly. Again, by using the Manage Client-Specific Options feature, you don't need to being managing all these fine details yourself, and then leaving yourself open to mistakes.
     
    Last edited: May 12, 2019
  10. pylsar

    pylsar Network Newbie Member

    Hi,

    I changed the configuration as you said (prtscr attached).

    after starting the server we have the configuration:
    Code:
    # Automatically generated configuration
    daemon
    server 10.8.0.0 255.255.255.0
    proto udp
    port 11111
    dev tun21
    comp-lzo adaptive
    keepalive 15 60
    verb 3
    push "route 172.16.15.0 255.255.255.0"
    client-config-dir ccd
    client-to-client
    route 10.10.1.0 255.255.255.0
    status-version 2
    status status
    
    # Custom Configuration
    tls-server
    dh                /tmp/mnt/sda1/openvpn/server/dh2048.pem
    ca                /tmp/mnt/sda1/openvpn/server/ca.pem
    cert              /tmp/mnt/sda1/openvpn/server/server_cert.pem
    key               /tmp/mnt/sda1/openvpn/server/server_key.pem
    user nobody
    group nobody
    persist-key
    persist-tun
    and CCD file "client":
    Code:
    iroute 10.10.1.0 255.255.255.0
    client settings did not change

    after establishing connection:
    now I don’t see (ping) the network behind the client (10.10.1.0/24) and I don’t see (ping) router (10.10.1.1). from the network behind the client, I only see (ping) the router server (172.16.15.1) and I don't see (ping) the network behind the server (172.16.15.0/24)
     

    Attached Files:

    • 1.jpg
      1.jpg
      File size:
      243.3 KB
      Views:
      4
    Last edited: May 13, 2019
  11. eibgrad

    eibgrad Network Guru Member

    Let's try to be methodical and solve this one step at a time. Let's just get the client side ping'ing the server side first, and deal w/ the server side ping'ing the client side later. For the time being, I'm only interested in two things.

    1. Can you ping a network device behind the OpenVPN server from a shell (telnet/ssh) on the client side router itself?

    2. Can you ping a network device behind the OpenVPN server from a device on the network behind the OpenVPN client?

    Those are two different situations. That's why I want you to try both and report the results.

    Also, if case #2 doesn't work, and you NAT the tunnel, does pinging for case #2 now work?

    P.S. One more thing. Is this OpenVPN server running on the primary/gateway router on that side of the tunnel? Sometimes ppl run it on a separate device, say a router configured as a bridge (LAN to LAN wrt the primary router), and that can cause routing problem.
     
    Last edited: May 14, 2019
  12. pylsar

    pylsar Network Newbie Member

    Create NAT on tunnel - OFF

    1. SSH - vpn client router (10.10.1.1)
    ping 172.16.15.1 - yes
    ping 172.16.15.10 - no
    2. from workstation behind vpn client router (10.10.1.7)
    ping 172.16.15.1 - no
    ping 172.16.15.10 - no

    Create NAT on tunnel - ON

    1. SSH - vpn client router (10.10.1.1)
    ping 172.16.15.1 - yes
    ping 172.16.15.10 - no
    2. from workstation behind vpn client router (10.10.1.7)
    ping 172.16.15.1 - yes
    ping 172.16.15.10 - no
     
  13. eibgrad

    eibgrad Network Guru Member

    You need to answer that last question too.

    Is this OpenVPN server running on the primary/gateway router on that side of the tunnel? Sometimes ppl run it on a separate device, say a router configured as a bridge (LAN to LAN wrt the primary router), and that can cause routing problems.
     
  14. pylsar

    pylsar Network Newbie Member

    OpenVPN server runs on the main router. There are no other routers on the network.

    Internet -> wan of tomato router with openvpn server -> workstations
     
    Last edited: May 14, 2019
  15. eibgrad

    eibgrad Network Guru Member

    What's baffling here is that when using a shell on the router, although you can ping 172.16.15.1 (so the routing is correct, it goes over the tunnel), even the router can't go beyond it. Normally it should just work, for the entire remote network. And if your routing tables remain the same as before (which appeared correct), the entire 172.16.15.0/24 network should be accessible.

    This sounds like an example of everything being correctly configured, but there's a personal firewall on the target device that's blocking access. I know on Windows systems of recent years, they've added security which prevents access from anything other than another device on its own network (172.16.15.0/24), or a public IP. Other devices may have similar requirements, or else it's just a common personal firewall.

    To fix the problem, you can reconfigure those personal firewalls to allow both 10.10.0.0/24 and 10.8.0.0/24 traffic to access them, or else NAT the traffic from the tunnel before it's dropped on the remote network.

    Code:
    iptables -t nat -I POSTROUTING -s 10.10.0.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    Personally, I prefer the former option. The latter masks the actual source IP from the target device (which is, of course, why it works), which means the target device can't do things like filter access based on that source IP (i.e., in a more selective manor than just blocking everything). Using NAT is the quick-n-dirty way to solve the problem. It prevents having to run around the entire remote network and reconfiguring every personal firewall (which might be a lot in some cases).

    That's my best guess at the moment. If this doesn't work, you'll probably have to dump everything on both sides (routing tables, firewall, etc.) to see what exactly is going on. But let's worry about that latter. Let's see if either of the two recommendations above solves the problem.
     
  16. pylsar

    pylsar Network Newbie Member

    the fact is that 172.16.15.10 is a DVR and I don't think it has a firewall

    this is for server? After making changes, does the router need to be rebooted?

    in the last configuration (in tomato GUI yesterday), I do not ping the addresses for the client (10.10.1.0/24) from the workstation for the server (172.16.15.0/24)
     
    Last edited: May 14, 2019
  17. eibgrad

    eibgrad Network Guru Member

    Yes, the server side. I wouldn't think the DVR has a firewall either, but this is my best guess at the moment. And until now, I've had no idea what the target device is. At least if you add those rules and it does't help, we know it's not likely a personal firewall issue.

    I understand that. We're trying to solve this problem one step at a time. The easiest thing to fix is accessing the server side from the client side. That's rarely a problem. And many times when you fix that problem, the other problem (accessing the client side from the server side) fixes itself!
     
  18. pylsar

    pylsar Network Newbie Member

    ок

    After making changes, does the router need to be rebooted?
     
  19. eibgrad

    eibgrad Network Guru Member

    For testing purposes, you can simply use a shell (telnet/ssh) to execute them on the running system. After testing, you can either delete them ...

    Code:
    iptables -t nat -D POSTROUTING -s 10.10.0.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    ... or just reboot the router to eliminate them. If it works, only then add them to the server's firewall script.
     
  20. pylsar

    pylsar Network Newbie Member

    I'm sorry. many many times.
    I ping the DVR all the time from another network and did not see it. Now I tried to ping other devices connected to the same network and received a positive ping from the address 172.16.15.5

    but why I do not ping the DVR - I do not understand)

    I did not make ipables settings yet

    now there is a second problem, see the addresses 10.10.1.0/24 from the network behind the server 172.16.15.0/24
     
  21. eibgrad

    eibgrad Network Guru Member

    LOL. Yeah, I didn't think about the possibility the device simply isn't responding to ping.

    You could have the same problem here as well. Did you try multiple devices on the network behind the OpenVPN client? Let's not make the same mistake twice.

    Also, make sure the common-name you specified in Manage Client-Specific Options is actually named "client". That's supposed to be the actual name in the cert, NOT just a generic reference to "the client".
     
  22. pylsar

    pylsar Network Newbie Member

    I can definitely ping DVR (172.16.15.10) from a workstation on the network 172.16.15.0/24. and now from a router (172.16.15.1) I do not ping it. in the evening I can check the performance of this device.

    here everything worked for me with manual settings that I had previously on the router.

    name matches. I'll check it again in the evening.
     
  23. pylsar

    pylsar Network Newbie Member

    maybe it is necessary to enable the Allow Only These Clients setting?
     
  24. eibgrad

    eibgrad Network Guru Member

    Not relevant. That just means that only an OpenVPN client by that common-name on its cert is allowed to establish a connection to the OpenVPN server. It's just a security measure, essentially an ACL (access control list) based on the common-name. You're already past that issue. You're connected.
     
  25. eibgrad

    eibgrad Network Guru Member

    Btw, Allow Client<-->Client isn't necessary either. That's only for cases where you want the OpenVPN server to allow all your OpenVPN clients (because there could many) to communicate with each other. IOW, the OpenVPN server acts like a gateway between those OpenVPN clients and the networks behind them. I assume that's NOT your intentions.

    It has nothing to do w/ this problem, but when I went back to check your OpenVPN server config (the one w/ the uploaded image), I noticed you had this enabled. Probably not going to do any harm, but I like to keep the configuration as secure as possible.
     
  26. eibgrad

    eibgrad Network Guru Member

    Let's dump the routing tables again, on both the client and server, just to make sure something hasn't changed.
     
  27. pylsar

    pylsar Network Newbie Member

    I found the cause of the problem:

    Code:
    user nobody
    group nobody
    With these settings, the server could not read the files in the folder CCD

    now everything works. networks respond in both directions!

    Now I will deal with the second question - connecting to openvpn server by tomato from a workstation from any other network!
     
    eibgrad likes this.
  28. eibgrad

    eibgrad Network Guru Member

    Glad it's working. You learn something new every day. Having those options enabled can also cause problems should the VPN come down and have to restart. It won't be able to re-establish the routing either due to lack of privileges! I ran into this problem quite some time ago, and only now recall it happening based on your last response. That's why those options, while in theory a good security measure, are not really practical.

    Finally making progress here.
     
  29. pylsar

    pylsar Network Newbie Member

    My working configuration for client openvpn - workstation windows:

    Code:
    client
    dev tun
    proto udp
    remote xxx yyy
    cipher bf-cbc
    auth sha1
    auth-nocache
    ca ca.crt
    cert nout.crt
    key  nout.key
    comp-lzo
    nobind
    persist-key
    persist-tun
    remote-cert-tls server
    verb 4
    route 10.10.1.0 255.255.255.0 10.8.0.9
    server config:
    Code:
    # Automatically generated configuration
    daemon
    server 10.8.0.0 255.255.255.0
    proto udp
    port yyy
    dev tun21
    comp-lzo adaptive
    keepalive 15 60
    verb 3
    push "route 172.16.15.0 255.255.255.0"
    client-config-dir ccd
    client-to-client
    ccd-exclusive
    route 10.10.1.0 255.255.255.0
    status-version 2
    status status
    
    # Custom Configuration
    tls-server
    dh                /tmp/mnt/sda1/openvpn/server/dh2048.pem
    ca                /tmp/mnt/sda1/openvpn/server/ca.pem
    cert              /tmp/mnt/sda1/openvpn/server/server_cert.pem
    key               /tmp/mnt/sda1/openvpn/server/server_key.pem
    persist-key
    persist-tun
    How to make the server itself issue a route command (route 10.10.1.0 255.255.255.0 10.8.0.9-gateway) for this client?

    Can I make so that the ip address for this client is always the same issued by the server?
     
  30. eibgrad

    eibgrad Network Guru Member

    If you want to force the OpenVPN client to use that OpenVPN server as its default gateway, then you need to check the "Direct clients to redirect Internet traffic" option (some bad labeling on that option if you ask me) on the OpenVPN server's Advanced page.

    It's also possible (and perhaps desirable in some cases) to NOT check that option on the OpenVPN server config, and instead configure the OpenVPN client to do it, by adding the following directive to its config file.

    Code:
    redirect-gateway def1
    IOW, it's sometimes advantageous to let the client decide rather than have the server dictate the client's actions.

    What IP? You mean the IP assigned to the OpenVPN client on the tunnel by the OpenVPN server?

    If so, then yes. That's another one of those settings you can add to that client's CCD file. But AFAIK, you can't do it through the GUI (at least I've never seen it done). So you'll probably have to go back to the manual configuration of the CCD file for that common-name (ironic, isn't it). But at least now you understand how to do it correctly.

    The specific directive is ifconfig-push.

    Code:
    ifconfig-push 10.8.0.2 255.255.255.255
    In the above example, if this is in the CCD file for the common-name "client", that client will always get assigned 10.8.0.2 during the connection process.

    Just beware. Now that you're assigning a static IP to that common-name, you can't be connected to the same OpenVPN server using the same common-name from multiple OpenVPN clients! I have no idea if that's your intention, but just something to take note of.
     
    pylsar likes this.
  31. pylsar

    pylsar Network Newbie Member

    There is no need to redirect Internet traffic.

    I want the vpn server to issue the setting to client2 (Windows workstation) so that client2 can see workstations in the client1 network (10.10.1.0/24).

    At the moment I did it in the settings in the client2 (route 10.10.1.0 255.255.255.0 10.8.0.9). But I think, if the address on the network vpn 10.8.0.10 is already taken, then this setting will not work. Is it possible to make the server itself do it?
     
  32. pylsar

    pylsar Network Newbie Member

    ???
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice