[Solved] Why is OpenVPN routing traffic for one specific IP wrong?

[CodeNinja]

I have the following topology where x differs per site:

Code: Select all

[OpenVPN client] < - > [OpenVPN Access Server] < - > [pfSense router] < - > [IPSec connected sites]
 172.27.244.21          10.128.20.5                    10.128.20.1            10.130.x.1

I'm able to ping devices in the IPSec sites from an OpenVPN client or directly from the OpenVPN access server. There is one site (10.130.7.1) what i can't ping from one an OpenVPN client but i can ping the site direclty from the OpenVPN Access Server.


Ping result from OpenVPN (Windows) client:

Code: Select all

Pinging 10.130.2.1 with 32 bytes of data:
Reply from 10.130.2.1: bytes=32 time=160ms TTL=62
Reply from 10.130.2.1: bytes=32 time=142ms TTL=62
Reply from 10.130.2.1: bytes=32 time=126ms TTL=62
Reply from 10.130.2.1: bytes=32 time=103ms TTL=62

Pinging 10.130.17.1 with 32 bytes of data:
Reply from 10.130.17.1: bytes=32 time=46ms TTL=62
Reply from 10.130.17.1: bytes=32 time=51ms TTL=62
Reply from 10.130.17.1: bytes=32 time=55ms TTL=62
Reply from 10.130.17.1: bytes=32 time=29ms TTL=62

Pinging 10.130.7.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
[-code]

Ping results from OpenVPN access server (SSH)
[code]
PING 10.130.2.1 (10.130.2.1) 56(84) bytes of data.
64 bytes from 10.130.2.1: icmp_seq=1 ttl=63 time=136 ms
64 bytes from 10.130.2.1: icmp_seq=2 ttl=63 time=111 ms
64 bytes from 10.130.2.1: icmp_seq=3 ttl=63 time=122 ms
64 bytes from 10.130.2.1: icmp_seq=4 ttl=63 time=166 ms

PING 10.130.17.1 (10.130.17.1) 56(84) bytes of data.
64 bytes from 10.130.17.1: icmp_seq=1 ttl=63 time=29.1 ms
64 bytes from 10.130.17.1: icmp_seq=2 ttl=63 time=29.1 ms
64 bytes from 10.130.17.1: icmp_seq=3 ttl=63 time=29.5 ms
64 bytes from 10.130.17.1: icmp_seq=4 ttl=63 time=29.5 ms

PING 10.130.7.1 (10.130.7.1) 56(84) bytes of data.
64 bytes from 10.130.7.1: icmp_seq=1 ttl=63 time=29.5 ms
64 bytes from 10.130.7.1: icmp_seq=2 ttl=63 time=28.8 ms
64 bytes from 10.130.7.1: icmp_seq=3 ttl=63 time=28.5 ms
64 bytes from 10.130.7.1: icmp_seq=4 ttl=63 time=28.5 ms

For me it looks like routing goes wrong for request to `10.130.7.1`. To debug this, i did a trace route from my OpenVPN client:

Code: Select all

Tracing route to 10.130.2.1 over a maximum of 30 hops
  1     1 ms     1 ms     1 ms  172.27.232.1
  2     2 ms     2 ms     1 ms  10.128.20.1
  3   115 ms   115 ms   116 ms  10.130.2.1

Tracing route to 10.130.17.1 over a maximum of 30 hops
  1     1 ms     1 ms     2 ms  172.27.232.1
  2     1 ms     1 ms     1 ms  10.128.20.1
  3    76 ms    38 ms    42 ms  10.130.17.1

Tracing route to 10.130.7.1 over a maximum of 30 hops
  1     1 ms     2 ms     2 ms  172.27.232.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

As the requests seems to go to the OpenVPN Access Server (172.27.253.1) i did a `tcpdump` there when pinging from the Windows client:

Code: Select all

10:27:53.900720  In ethertype IPv4 (0x0800), length 76: 172.27.244.21 > 10.130.2.1: ICMP echo request, id 1, seq 1036, length 40
10:27:53.900756 Out 6a:fd:3e:82:c5:b8 ethertype IPv4 (0x0800), length 76: 10.128.20.5 > 10.130.2.1: ICMP echo request, id 1, seq 1036, length 40
10:27:54.001502  In 00:25:90:bd:8a:4a ethertype IPv4 (0x0800), length 76: 10.130.2.1 > 10.128.20.5: ICMP echo reply, id 1, seq 1036, length 40
10:27:54.001531 Out ethertype IPv4 (0x0800), length 76: 10.130.2.1 > 172.27.244.21: ICMP echo reply, id 1, seq 1036, length 40

10:27:57.048858  In ethertype IPv4 (0x0800), length 76: 172.27.244.21 > 10.130.17.1: ICMP echo request, id 1, seq 1037, length 40
10:27:57.048909 Out 6a:fd:3e:82:c5:b8 ethertype IPv4 (0x0800), length 76: 10.128.20.5 > 10.130.17.1: ICMP echo request, id 1, seq 1037, length 40
10:27:57.077173  In 00:25:90:bd:8a:4a ethertype IPv4 (0x0800), length 76: 10.130.17.1 > 10.128.20.5: ICMP echo reply, id 1, seq 1037, length 40
10:27:57.077204 Out ethertype IPv4 (0x0800), length 76: 10.130.17.1 > 172.27.244.21: ICMP echo reply, id 1, seq 1037, length 40

10:27:59.502909  In ethertype IPv4 (0x0800), length 76: 172.27.244.21 > 10.130.7.1: ICMP echo request, id 1, seq 1038, length 40
10:27:59.502966 Out 6a:fd:3e:82:c5:b8 ethertype IPv4 (0x0800), length 76: 172.27.244.21 > 10.130.7.1: ICMP echo request, id 1, seq 1038, length 40

Hah!, the request to `10.130.7.1` goes "out" from the server via `172.27.244.21` (the OpenVPN clients address where the ping request comes from). Why is this happening? Why doesn't it go out via `10.128.20.5` (the OpenVPN Access Servers IP) like the requests to `10.130.2.1` and `10.130.17.1`?

I don't know if its needed but just for sure the routing table of the Access Server

Code: Select all

root@axx-ovpn-as01:/home/axxmin# routel
         target            gateway          source    proto    scope    dev tbl
        default        10.128.20.1                   static           ens18
   10.128.20.0/ 24                     10.128.20.5   kernel     link  ens18
  172.27.224.0/ 21                    172.27.224.1   kernel     link  as0t0
  172.27.232.0/ 21                    172.27.232.1   kernel     link  as0t1
  172.27.244.21                                      static           as0t1
    10.128.20.0          broadcast     10.128.20.5   kernel     link  ens18 local
    10.128.20.5              local     10.128.20.5   kernel     host  ens18 local
  10.128.20.255          broadcast     10.128.20.5   kernel     link  ens18 local
      127.0.0.0          broadcast       127.0.0.1   kernel     link     lo local
     127.0.0.0/ 8            local       127.0.0.1   kernel     host     lo local
      127.0.0.1              local       127.0.0.1   kernel     host     lo local
127.255.255.255          broadcast       127.0.0.1   kernel     link     lo local
   172.27.224.0          broadcast    172.27.224.1   kernel     link  as0t0 local
   172.27.224.1              local    172.27.224.1   kernel     host  as0t0 local
 172.27.231.255          broadcast    172.27.224.1   kernel     link  as0t0 local
   172.27.232.0          broadcast    172.27.232.1   kernel     link  as0t1 local
   172.27.232.1              local    172.27.232.1   kernel     host  as0t1 local
 172.27.239.255          broadcast    172.27.232.1   kernel     link  as0t1 local
            ::1              local                   kernel              lo
        fe80::/ 64                                   kernel           ens18
        fe80::/ 64                                   kernel           as0t0
        fe80::/ 64                                   kernel           as0t1
            ::1              local                   kernel              lo local
fe80::1cea:a857:88ab:b687              local                   kernel           as0t1 local
fe80::68fd:3eff:fe82:c5b8              local                   kernel           ens18 local
fe80::a3cb:f651:4066:8cb              local                   kernel           as0t0 local
        ff00::/ 8                                                     ens18 local
        ff00::/ 8                                                     as0t0 local
        ff00::/ 8                                                     as0t1 local

[CodeNinja]

The issue was that i configured the 10.130.7.0/24 network in the `Subnets assigned to this group (optional):` field instead of in the `Allow Access To networks and service` field like i did for the other networks. I did not directly notice it as the different networks are configured in different groups.

[Pippin]

Thanks for reporting back.