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

[guillaume14]

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

[guillaume14]

Hello

Nobody ?

Thanks a lot in advance
Guillaume

[guillaume14]

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

Regards
Guillaume

[jimp]

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.

[guillaume14]

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 ...

[Pippin]

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.

[jimp]

@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.

[Pippin]

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

[Pippin]

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"