Don't understand the 10.0.8.2 route in Diagnostics -> Routes



  • Hello

    I have a Netgate XG-7100 appliance with:

    • a single Wan interface (pppoe fiber connection)
    • a single LAN inferface (192.168.100.0/24 network)
    • an OpenVPN "roadwarrior" server (IPv4 Tunnel Network: 10.0.8.0/24)
    • an IPSEC tunnel to a remote Netgate SG-3100 appliance (LAN network on the other side: 192.168.5.0/24, correct P2 entries so both ends can communicate with the 192.168.5.0/24, 192.168.100.0/24 and 10.0.8.0/24 networks)

    In Diagnostic -> Routes i can see the following lines:

    10.0.8.0/24 10.0.8.2 UGS 11683861 1500 ovpns1
    10.0.8.1 link#24 UHS 0 16384 lo0
    10.0.8.2 link#24 UH 2797328 1500 ovpns1

    I understand that the 10.0.8.1 (as the first usable address in the network) is assigned to the server virtual interface. But what is the meaning of the 10.0.8.2 route ?

    As the 10.0.8.2 IP was assigned to an OpenVPN client by the server i got strange behavior for that specific client:

    • he was able to acces 192.168.100.0 network shares
    • he was able to list shares on a server in the 192.168.5.0 network but was NOT able to browse the share
    • he can initiate a remote desktop connexion in the 192.168.5.0 network but then a blank screen occur just after the connection

    I had to make a reservation in the "Client Specific Overrides" tab for that OpenVPN client so he gets the 10.0.8.200 IP address. With that IP everything is working ...

    Any clue ?

    Thanks a lot in advance
    Guillaume



  • Hello

    Nobody ?

    Thanks a lot in advance
    Guillaume



  • Looks like my question must be stupid ... :)

    Regards
    Guillaume


  • Rebel Alliance Developer Netgate

    It's a dummy entry to nudge traffic for networks using that OpenVPN instance to use the VPN for the traffic. The route tells the OS to send the traffic across the OpenVPN interface.

    It doesn't necessarily mean the traffic will be delivered there. OpenVPN handles that internally. It could be any address inside the tunnel network.



  • Thanks a lot for your time

    What i don't understand is why the user can't access the 192.168.5.0 ressources if the OpenVPN roadwarrior DHCP gives the 10.0.8.2 address to that user. If i manually assign another IP to the user he can access the ressources ...



  • Yeah, pfS does something different.

    Just fired up a server on Linux.

    Basic roadwarrior setup:

    log /etc/openvpn/server/111.log
    verb 4
    daemon
    dev tunudp
    dev-type tun
    proto udp
    port 11194
    local 192.168.25.82
    
    server 192.168.168.0 255.255.255.0 'nopool'
    ifconfig-pool 192.168.168.16 192.168.168.253
    topology subnet
    

    Log:

    do_ifconfig, tt->did_ifconfig_ipv6_setup=0
    /sbin/ip link set dev tunudp up mtu 1500
    /sbin/ip addr add dev tunudp 192.168.168.1/24 broadcast 192.168.168.255
    

    Route:

    0.0.0.0         192.168.25.1    0.0.0.0         UG    600    0        0 wlp2s0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
    192.168.25.0    0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
    192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 tunudp
    

    ifconfig:

    tunudp    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
              inet addr:192.168.168.1  P-t-P:192.168.168.1  Mask:255.255.255.0
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100 
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
    

    I guess the route scripts do some magic on pfS.....or something is wrong.


  • Rebel Alliance Developer Netgate

    @Pippin said in Don't understand the 10.0.8.2 route in Diagnostics -> Routes:

    Yeah, pfS does something different.
    Just fired up a server on Linux.

    That's not a 1:1 test. You'd need to see his full OpenVPN config file to make a direct comparison.

    You don't have any routes pointing into OpenVPN. At least add a route statement and see what happens.



  • That's not a 1:1 test.

    True
    Added a route directive.
    Route:

    0.0.0.0         192.168.25.1    0.0.0.0         UG    600    0        0 wlp2s0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
    192.168.25.0    0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
    192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 tunudp
    192.168.178.0   192.168.168.2   255.255.255.0   UG    0      0        0 tunudp
    

    192.168.178.0/24 pointing to 192.168.168.2 .... indeed but different, also no loopback.
    .
    ifconfig:

    inet addr:192.168.168.1  P-t-P:192.168.168.1  Mask:255.255.255.0
    

    .
    If i'm not mistaken ifconfig on pfS will show:

    inet addr:192.168.168.1  P-t-P:192.168.168.2  Mask:255.255.255.0
    


  • Ok, fired up a virtual box and topology subnet for pfS shows

    inet 172.16.25.1 --> 172.16.25.2
    

    while on Linux

    inet 172.16.25.1 --> 172.16.25.1
    

    .
    Then I remembered something about topology in FreeBSD and found it:
    "Repair topology subnet on FreeBSD 11"
    https://sourceforge.net/p/openvpn/mailman/message/35478475/
    So I guess it's related to that for why it's different.

    But don't know it's related to OPs

    "the user can't access the 192.168.5.0 ressources if the OpenVPN roadwarrior DHCP gives the 10.0.8.2"


Log in to reply