Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Routing problem - Newbee question

    OpenVPN
    3
    22
    6.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rumpelstilzchen
      last edited by

      @marvosa:

      Yes, this is not making sense.

      You said your network is now 10.0.0.0/9, so why are you pushing routes to 10.2.1.0/24, 10.0.0.0/24 and 10.1.0.0/24?  Those are all inside of 10.0.0.0/9… you've got something mixed up.  Give us a network map, so we can see how you're connected and what you're trying to accomplish.

      If your LAN is truly 10.0.0.0/9 then in your VPN config, under Tunnel Settings, your Local Network should only read 10.0.0.0/9…. does it?

      If so, we should see this in your server1.conf -> push "route 10.0.0.0 255.128.0.0" but we don't.

      Also, you are using split tunnel, so why are you pushing google's DNS to your clients?  And your DNS servers are also inside your LAN, so I'm not sure why you're pushing those out either.

      Ok, looks like i misunderstand things and I need some help in the design of my network.

      As already explained I have a big LAN, which is not yet partitionned finally. The idea is, that there are several subnets for server with special purpose. Then there are subnets for different customers, and there are subnets for ourselfes.

      There should be different VPNs: Some Super-Admins can connect to the 'root' and see the whole network and can admin all machines there.
      There should be other subnets, where only people can connect, who are allowed to see these machines.

      Example:

      A super admin should be able to connect to any machine in any subnet below 10.0.0.0/9

      Lets say cutomer X has three virtual machines and some virtual desktops in a subnet 10.53.99.0/28. To access these machines, he should have a VPN, only showing him these 14 usable IP adresses.

      The plan is to use openVPN for mobile/home office users and IPSec for network to network connections.

      Is this not possible?

      Rumpi

      1 Reply Last reply Reply Quote 0
      • R
        rumpelstilzchen
        last edited by

        @marvosa:

        Yes, this is not making sense.

        You said your network is now 10.0.0.0/9, so why are you pushing routes to 10.2.1.0/24, 10.0.0.0/24 and 10.1.0.0/24?  Those are all inside of 10.0.0.0/9… you've got something mixed up.  Give us a network map, so we can see how you're connected and what you're trying to accomplish.

        If your LAN is truly 10.0.0.0/9 then in your VPN config, under Tunnel Settings, your Local Network should only read 10.0.0.0/9…. does it?

        If so, we should see this in your server1.conf -> push "route 10.0.0.0 255.128.0.0" but we don't.

        Also, you are using split tunnel, so why are you pushing google's DNS to your clients?  And your DNS servers are also inside your LAN, so I'm not sure why you're pushing those out either.

        Ok, I made some changes. First forget about the google DNS server. It is a lab environment and at the beginning I had no working nameserver.

        So here is the new configuration:

        login as: root
        Using keyboard-interactive authentication.
        Password:
        *** Welcome to pfSense 2.1-BETA1-pfSense (amd64) on dcsfire1 ***

        WAN (wan)      -> igb1      -> v4: 172.16.63.120/16
        LAN (lan)      -> igb0      -> v4: 10.0.0.1/9

        1. Logout (SSH only)                  8) Shell
        2. Assign Interfaces                  9) pfTop
        3. Set interface(s) IP address      10) Filter Logs
        4. Reset webConfigurator password    11) Restart webConfigurator
        5. Reset to factory defaults        12) pfSense Developer Shell
        6. Reboot system                    13) Upgrade from console
        7. Halt system                      14) Disable Secure Shell (sshd)
        8. Ping host                        15) Restore recent configuration

        Enter an option: 8

        [2.1-BETA1][root@dcsfire1.datacave.biz]/var/etc/openvpn(51): cat server1.conf
        dev ovpns1
        dev-type tun
        tun-ipv6
        dev-node /dev/tun1
        writepid /var/run/openvpn_server1.pid
        #user nobody
        #group nobody
        script-security 3
        daemon
        keepalive 10 60
        ping-timer-rem
        persist-tun
        persist-key
        proto udp
        cipher AES-256-CBC
        up /usr/local/sbin/ovpn-linkup
        down /usr/local/sbin/ovpn-linkdown
        client-connect /usr/local/sbin/openvpn.attributes.sh
        client-disconnect /usr/local/sbin/openvpn.attributes.sh
        local 172.16.63.120
        tls-server
        server 10.200.1.0 255.255.255.0
        client-config-dir /var/etc/openvpn-csc
        username-as-common-name
        auth-user-pass-verify /var/etc/openvpn/server1.php via-env
        tls-verify /var/etc/openvpn/server1.tls-verify.php
        lport 1194
        management /var/etc/openvpn/server1.sock unix
        max-clients 10
        push "route 10.0.0.0 255.128.0.0"
        push "dhcp-option DOMAIN datacave.local"
        push "dhcp-option DNS 10.1.0.5"
        push "dhcp-option DNS 10.1.0.6"
        ca /var/etc/openvpn/server1.ca
        cert /var/etc/openvpn/server1.cert
        key /var/etc/openvpn/server1.key
        dh /etc/dh-parameters.1024
        tls-auth /var/etc/openvpn/server1.tls-auth 0
        comp-lzo
        persist-remote-ip
        float
        topology subnet
        [2.1-BETA1][root@dcsfire1.datacave.biz]/var/etc/openvpn(52):

        So the whole big flat LAN should be accessible now. But after a restart of the openVPN server, it behaves still as before! I can ping 10.1.0.5 but NOT 10.2.1.199.

        Rumpi

        1 Reply Last reply Reply Quote 0
        • M
          marvosa
          last edited by

          What is the subnet mask of 10.2.1.199?  And where is it located on the network?

          1 Reply Last reply Reply Quote 0
          • R
            rumpelstilzchen
            last edited by

            Currently I only have two machines and a small switch. One of the machines is the IPFire Server.

            The other box is a powerfull Win 2012 Server with Hyper-V 3 with 8 network ports. This machine is a host which will have many many VMs soon. Currently both of the networks are connected to a 'Virtual Switch' with 255.0.0.0 as subnet. The interface itself has 10.0.2.129. You can create many Virtual Switches and connect them to physical network ports which you connect then to a physical switch. Currently I have simply connected two cables to the physical switch. One is for the host computer and one is for the virtual switch.

            Don't know, if this answers your question….

            Rumpi

            1 Reply Last reply Reply Quote 0
            • M
              marvosa
              last edited by

              Actually no.  but we seem to get more new information with every post :)

              You said you couldn't ping a device with an IP of 10.2.1.199….  I am asking what that is and where that device is located... (physical machine, vm, router, etc?) ... and what is the subnet mask configured on that device?

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                If 10.2.1.199 has a subnet mask 255.0.0.0 in it (/8 from the past) then it will think that the OpenVPN tunnel is part of the /8 and will expect it to be on the LAN,  which it is not. Hopefully it is just simply fixing up the subnet mask on the unpingable machines to use /9.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • R
                  rumpelstilzchen
                  last edited by

                  @marvosa:

                  What is the subnet mask of 10.2.1.199?  And where is it located on the network?

                  Hi Guys,

                  All Machines (the 'pingable' ones and those who do not answer) are CentOS boxes as VMs. The host is a Windows 2012 Server with 10.0.2.128/255.128.0.0 (I changed the netmask everywhere). Still no change in the situation. So I tried the ping and traceroute tools in pfSense. And thats showing the following results  (see attached screenshots):

                  Is there any better way to see what is going on in the firewall? Are there any logs that contain information?

                  If I look at the openVPN log under system logs I only see successful connections:

                  May 21 08:20:14 openvpn[18150]: MAvpnAdmin/172.16.63.214:1194 send_push_reply(): safe_cap=940
                  May 21 08:20:12 openvpn[18150]: MAvpnAdmin/172.16.63.214:1194 MULTI_sva: pool returned IPv4=10.200.1.2, IPv6=(Not enabled)
                  May 21 08:20:12 openvpn[18150]: 172.16.63.214:1194 [MAvpnAdmin] Peer Connection Initiated with [AF_INET]172.16.63.214:1194
                  May 21 08:20:12 openvpn: user 'MAvpnAdmin' authenticated
                  May 21 07:24:16 openvpn[18150]: Initialization Sequence Completed
                  May 21 07:24:16 openvpn[18150]: UDPv4 link remote: [undef]
                  May 21 07:24:16 openvpn[18150]: UDPv4 link local (bound): [AF_INET]172.16.63.120:1194
                  May 21 07:24:16 openvpn[13606]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 10.200.1.1 255.255.255.0 init
                  May 21 07:24:16 openvpn[13606]: /sbin/ifconfig ovpns1 10.200.1.1 10.200.1.1 mtu 1500 netmask 255.255.255.0 up
                  May 21 07:24:16 openvpn[13606]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
                  May 21 07:24:16 openvpn[13606]: TUN/TAP device /dev/tun1 opened
                  May 21 07:24:16 openvpn[13606]: TUN/TAP device ovpns1 exists previously, keep at program end
                  May 21 07:24:16 openvpn[13606]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
                  May 21 07:24:16 openvpn[13606]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
                  May 21 07:24:16 openvpn[13606]: Could not retrieve default gateway from route socket:: No such process (errno=3)
                  May 21 07:24:16 openvpn[13606]: OpenVPN 2.3.1 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on May 6 2013
                  May 20 22:26:08 openvpn[16884]: tbVpnAdmin/172.16.63.102:1194 send_push_reply(): safe_cap=940
                  May 20 22:26:06 openvpn[16884]: tbVpnAdmin/172.16.63.102:1194 MULTI_sva: pool returned IPv4=10.200.1.2, IPv6=(Not enabled)
                  May 20 22:26:06 openvpn[16884]: 172.16.63.102:1194 [tbVpnAdmin] Peer Connection Initiated with [AF_INET]172.16.63.102:1194
                  May 20 22:26:06 openvpn: user 'tbVpnAdmin' authenticated

                  The firewall log may also be interesting:

                  block May 21 08:51:08 WAN 172.16.63.150:138 172.16.63.255:138 UDP
                  block May 21 08:50:00 WAN 172.16.63.111:138 172.16.63.255:138 UDP
                  block May 21 08:49:05 WAN 172.16.63.102:138 172.16.63.255:138 UDP
                  block May 21 08:48:04 WAN 172.16.63.204:138 172.16.63.255:138 UDP
                  block May 21 08:47:37 WAN 172.16.63.1:67 255.255.255.255:68 UDP
                  block May 21 08:47:37 WAN 0.0.0.0:68 255.255.255.255:67 UDP
                  block May 21 08:45:19 WAN 172.16.63.1:67 255.255.255.255:68 UDP
                  block May 21 08:45:19 WAN 0.0.0.0:68 255.255.255.255:67 UDP
                  block May 21 08:44:04 WAN 172.16.63.100:138 172.16.63.255:138 UDP
                  block May 21 08:44:04 WAN 172.16.63.100:138 172.16.63.255:138 UDP
                  block May 21 08:42:45 LAN 10.1.0.5:669 10.0.2.128:2049 TCP:RA
                  block May 21 08:42:43 WAN 172.16.63.214:137 172.16.63.255:137 UDP
                  block May 21 08:42:43 WAN 172.16.63.214:137 172.16.63.255:137 UDP
                  block May 21 08:42:42 WAN 172.16.63.214:137 172.16.63.255:137 UDP
                  block May 21 08:42:30 LAN 10.1.0.5:2990208737 10.0.2.128:2049 TCP:etatt
                  block May 21 08:42:21 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:56 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:43 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:36 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:33 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:32 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:31 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:30 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:41:30 LAN 10.1.0.5:2973431521 10.0.2.128:2049 TCP:etatt
                  block May 21 08:39:40 WAN 172.16.63.1:67 255.255.255.255:68 UDP

                  Just to summarize the IPs again:

                  pfSense box: WAN 172.16.63.120/16  (static address from our internal office LAN), Gateway 172.16.63.1 (a Fortinet Firewall)
                                    LAN  10.0.0.0/8  (the LAN for all the datacenter servers), Gateway 10.0.0.1

                  Host1 (Windows 2012 server):  10.0.2.128/255.128.0.0  (This is one of the 8 NIC ports, connected to a physical switch)
                                                            10.0.2.129/255.128.0.0  (This is another NIC port, connected to the physical switch, used for the virtual Switch for Hyper-V 3. This switch then connects the virtual NICs of the VMs)

                  Now we have the following VM's all running on physical machine Host1:

                  10.1.0.5    ns1  DNS server running on CentOS 6.4
                  10.1.0.6    ns2  DNS server running on CentOS 6.4
                  10.2.1.193 - 199  several servers all running CentOS 6.4 working as web-, database- and application servers
                  10.2.1.129 - 135  several servers all running Windows 2012 woring as AD, RDS and other Windows servers

                  ALL OF THESE VMs are currently connected to the virtual switch described above with 10.0.2.129. However depending on the machines and applications, it is possible to create multiple virtual switches and assign different physical NICs to each switch. NIC teaming is also possible. I currently use none of these feature, it is currently as simple as possible.

                  Any more help would be greatly appreciated.  Also the question if this could be a problem of the Beta release (I currently doubt that, but you never know). If so I would buy a LSI card and switch back to the official 2.0.3 release. I use the beta only for hw compatibility reasons.

                  Rumpi

                  Traceroute_DNS.jpg
                  Traceroute_DNS.jpg_thumb
                  Traceroute_WebServer.jpg
                  Traceroute_WebServer.jpg_thumb

                  1 Reply Last reply Reply Quote 0
                  • M
                    marvosa
                    last edited by

                    pfSense box: WAN 172.16.63.120/16  (static address from our internal office LAN), Gateway 172.16.63.1 (a Fortinet Firewall)
                                      LAN  10.0.0.0/8  (the LAN for all the datacenter servers), Gateway 10.0.0.1

                    Is this a typo?  I thought this was changed to 10.0.0.0/9?

                    So, I'm not sure if you're specifically not answering the question or if I'm not being direct enough when I ask for the subnet mask.  For instance, when you say:

                    10.1.0.5    ns1  DNS server running on CentOS 6.4
                    10.1.0.6    ns2  DNS server running on CentOS 6.4
                    10.2.1.193 - 199  several servers all running CentOS 6.4 working as web-, database- and application servers
                    10.2.1.129 - 135  several servers all running Windows 2012 woring as AD, RDS and other Windows servers

                    You still have not given us the masks for the servers you are trying to reach.  You've given us the mask for the host machine, but not each guest.  Double check the mask on each guest and report back.

                    It would also be helpful if you provided a network map, so we can see how things are physically connected.  Also, where are you testing from?

                    Your firewall log is interesting.  You shouldn't be getting blocks between 10.1.0.5 and 10.0.2.128 because they are on the same LAN… that traffic should not be hitting the firewall.  Just another reason to double check connections and masks.

                    1 Reply Last reply Reply Quote 0
                    • R
                      rumpelstilzchen
                      last edited by

                      @marvosa:

                      pfSense box: WAN 172.16.63.120/16   (static address from our internal office LAN), Gateway 172.16.63.1 (a Fortinet Firewall)
                                         LAN  10.0.0.0/8  (the LAN for all the datacenter servers), Gateway 10.0.0.1

                      Is this a typo?  I thought this was changed to 10.0.0.0/9?

                      Sorry this is a typo, I changed all to 255.128.0.0

                      @marvosa:

                      So, I'm not sure if you're specifically not answering the question or if I'm not being direct enough when I ask for the subnet mask.  For instance, when you say:

                      10.1.0.5     ns1   DNS server running on CentOS 6.4
                      10.1.0.6     ns2   DNS server running on CentOS 6.4
                      10.2.1.193 - 199  several servers all running CentOS 6.4 working as web-, database- and application servers
                      10.2.1.129 - 135  several servers all running Windows 2012 woring as AD, RDS and other Windows servers

                      You still have not given us the masks for the servers you are trying to reach.   You've given us the mask for the host machine, but not each guest.  Double check the mask on each guest and report back.

                      It would also be helpful if you provided a network map, so we can see how things are physically connected.  Also, where are you testing from?

                      Your firewall log is interesting.  You shouldn't be getting blocks between 10.1.0.5 and 10.0.2.128 because they are on the same LAN… that traffic should not be hitting the firewall.  Just another reason to double check connections and masks.

                      Sorry, I currently don't have a map, I need a tool for that like Nagios. But I haven't installed yet.

                      BUT I THINK YOU GOT IT! At least I found one machine with 255.0.0.0 instead of 255.128.0.0 running CentOS. I changed that and it is answering now on pings!! I have a Windows box setup correctly which does not anser. I will have to check the other machines, check local firewalls on windows and reboot all the boxes and see if it is working. I will give feedback later.  Hopefully one major problem is solved.

                      First of all thanks a lot for your help! Coming back soon with the results.

                      Rumpi

                      1 Reply Last reply Reply Quote 0
                      • R
                        rumpelstilzchen
                        last edited by

                        Hi Guys, seems that the problem is solved. The main problem was to have the tunnel network inside the LAN which does not work. Reducing the LAN network and placing the tunnel network outside was the main fix. All other problems where a result of not having consequently changed all netmasks to the reduced LAN network on my guest operating systems. The two name servers had 255.255.0.0 as netmask, thats why they answered ping requests through the tunnel. The other boxes still had 255.0.0.0. All have now 255.128.0.0 and everything works fine.

                        So many thanks again to all who helped me! Great work!

                        Rumpi

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.