Project

General

Profile

Actions

Bug #3747

closed

Route uses wrong interface (lo0) when tun local and remote are the same

Added by Renato Botelho over 10 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Ermal Luçi
Category:
Routing
Target version:
Start date:
07/08/2014
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:
All

Description

When an openvpn client is configured using tun, and server sets topology subnet, we end up with routing issues. tun interface is configured as POINTTOPOINT with the same IP address for local and remote, what is wrong, it should be set as BROADCAST.

Actions #1

Updated by Renato Botelho over 10 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Pushed a fix on tools, next round of snapshots should be ok

Actions #2

Updated by Renato Botelho over 10 years ago

  • Status changed from Feedback to Resolved
Actions #3

Updated by Renato Botelho over 10 years ago

  • Category changed from OpenVPN to Routing
  • Status changed from Resolved to New

It works as expected on stock FreeBSD

Actions #4

Updated by Renato Botelho over 10 years ago

  • Assignee changed from Renato Botelho to Ermal Luçi

Ermal is checking routing issue, here are some details:

ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::a00:27ff:fe12:ee56%ovpnc1 prefixlen 64 scopeid 0xa
        inet 172.99.99.2 --> 172.99.99.2 netmask 0xffffff00
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        Opened by PID 36620

tunnel is .2 -> .2 because server has topology set to subnet

---------------------------------------------------------------------------
2.2-snapshot (with the issue)

OpenVPN logs:

Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 PUSH: Received control message: 'PUSH_REPLY,route 10.130.130.0 255.255.255.0,
route 10.221.221.0 255.255.255.0,route-gateway 172.99.99.1,topology subnet,ping 10,
ping-restart 60,ifconfig 172.99.99.2 255.255.255.0'
Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 /sbin/ifconfig ovpnc1 172.99.99.2 172.99.99.2 mtu 1500 netmask 255.255.255.0 up
Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 /sbin/route add -net 172.99.99.0 172.99.99.2 255.255.255.0
Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1505 172.99.99.2 255.255.255.0 init
Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 /sbin/route add -net 10.130.130.0 172.99.99.1 255.255.255.0
Jul 18 13:11:08 pfs22i386 openvpn[79073]:
 /sbin/route add -net 10.221.221.0 172.99.99.1 255.255.255.0

2.2-ALPHA][root@pfs22i386.localdomain]/root(22): netstat -nrf inet
Routing tables

Internet:
Destination        Gateway            Flags    Netif Expire
10.130.130.0/24    172.99.99.1        UGS       lo0 <--- this is supposed to be ovpnc1
10.221.221.0/24    172.99.99.1        UGS       lo0 <--- this is supposed to be ovpnc1
172.99.99.0/24     172.99.99.2        UGS    ovpnc1
172.99.99.2        link#10            UH     ovpnc1

[2.2-ALPHA][root@pfs22i386.localdomain]/root(6): route get 172.99.99.1
   route to: 172.99.99.1
destination: 172.99.99.0
       mask: 255.255.255.0
    gateway: 172.99.99.2
        fib: 0
  interface: ovpnc1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
[2.2-ALPHA][root@pfs22i386.localdomain]/root(7): route get 10.221.221.1
   route to: 10.221.221.1
destination: 10.221.221.0
       mask: 255.255.255.0
    gateway: 172.99.99.1
        fib: 0
  interface: lo0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0

---------------------------------------------------------------------------
2.1.4 (works as expected)

[2.1.4-RELEASE][root@pfs21amd64.localdomain]/var/etc/openvpn(36): netstat -nrf inet
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
10.130.130.0/24    172.99.99.1        UGS         0        0 ovpnc1
10.221.221.0/24    172.99.99.1        UGS         0        0 ovpnc1
172.99.99.0/24     172.99.99.3        UGS         0        0 ovpnc1
172.99.99.3        link#10            UH          0        0 ovpnc1

[2.1.4-RELEASE][root@pfs21amd64.localdomain]/root(26): route get 172.99.99.1
   route to: 172.99.99.1
destination: 172.99.99.0
       mask: 255.255.255.0
    gateway: 172.99.99.2
  interface: ovpnc1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
[2.1.4-RELEASE][root@pfs21amd64.localdomain]/root(27): route get 10.221.221.1
   route to: 10.221.221.1
destination: 10.221.221.0
       mask: 255.255.255.0
    gateway: 172.99.99.1
  interface: ovpnc1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

---------------------------------------------------------------------------
Stock FreeBSD current (also works as expected)

oot@cur:/usr/home/garga/openvpn # netstat -nrf inet
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
10.130.130.0/24    172.99.99.1        UGS        tun1
10.221.221.0/24    172.99.99.1        UGS        tun1
172.99.99.0/24     172.99.99.4        UGS        tun1
172.99.99.4        link#4             UH         tun1

root@cur:/usr/home/garga/openvpn # route get 172.99.99.1
   route to: 172.99.99.1
destination: 172.99.99.0
       mask: 255.255.255.0
    gateway: 172.99.99.4
        fib: 0
  interface: tun1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
root@cur:/usr/home/garga/openvpn # route get 10.221.221.1
   route to: 10.221.221.1
destination: 10.221.221.0
       mask: 255.255.255.0
    gateway: 172.99.99.1
        fib: 0
  interface: tun1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
Actions #5

Updated by Greg B over 10 years ago

I wrote up what looks to be a similar issue here in the forums:
https://forum.pfsense.org/index.php?topic=79305.0

I can confirm that the interface is also point-to-point:

ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::2aa:aff:fe14:1902%ovpnc1 prefixlen 64 scopeid 0x6
        inet 5.5.25.122 --> 5.5.25.122 netmask 0xfffff800
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 19390

Using FreeBSD 10.0-STABLE #16 0d8378f(HEAD)-dirty: Fri Jul 11 23:28:35 CDT 2014

Actions #6

Updated by Renato Botelho over 10 years ago

It's not related with openvpn, it's an issue on FreeBSD routing. A simple step to reproduce is:

# ifconfig tun10 create
# ifconfig tun10 10.199.199.2 10.199.199.2 netmask 255.255.255.0
# route add -net 10.199.199.0/24 10.199.199.2
# route add -net 172.16.16.0/24 10.199.199.1
# netstat -nrf inet | grep 10.199.199
10.199.199.0/24    10.199.199.2       UGS     tun10
10.199.199.2       link#15            UH      tun10
172.16.16.0/24     10.199.199.1       UGS       lo0   <-- HERE is the issue, it should be tun10
Actions #7

Updated by Renato Botelho over 10 years ago

  • Subject changed from Openvpn route issues with topology subnet to Route uses wrong interface (lo0) when tun local and remote are the same

Using a more appropriate subject

Actions #8

Updated by Ermal Luçi over 10 years ago

  • Status changed from New to Feedback

Patch put on pfSense module to not set netmask to 0 on interfaces.

Actions #9

Updated by Renato Botelho over 10 years ago

  • Status changed from Feedback to Resolved
Actions #10

Updated by Greg B over 10 years ago

Sorry to ask a novice question in an issue/ticket, but is there a link to the code checkin that relates to this candidate fix please? It might also let me review it and determine if the snapshot I have includes the fix. Thanks.

Actions #11

Updated by Renato Botelho over 10 years ago

Greg B wrote:

Sorry to ask a novice question in an issue/ticket, but is there a link to the code checkin that relates to this candidate fix please? It might also let me review it and determine if the snapshot I have includes the fix. Thanks.

The fix was applied on tools repository. If you want to have access to this repo you need to follow the instructions from:

https://forum.pfsense.org/index.php?topic=73101.msg412692#msg412692

Actions #12

Updated by Renato Botelho over 10 years ago

Greg B wrote:

Sorry to ask a novice question in an issue/ticket, but is there a link to the code checkin that relates to this candidate fix please? It might also let me review it and determine if the snapshot I have includes the fix. Thanks.

Snapshots from Aug 17 or newer includes the fix for sure.

Actions

Also available in: Atom PDF