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

    OpenVPN client specific overrides and order of push options

    Scheduled Pinned Locked Moved OpenVPN
    1 Posts 1 Posters 1.9k Views
    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.
    • A
      arion_p
      last edited by

      I was trying to connect two Mikrotik router as OpenVPN client to pfSense and have pfSense allow traffic between the two Mikrotik routers. After much hair-pulling and a lot of debugging, I found out that routes pushed by Client Specific Overrides->IPv4 Local Network/s are placed at the end of the push options, after the route-gateway option. Here is a sample:

      PUSH_REPLY,route 192.168.214.0 255.255.255.0,route-gateway 192.168.217.1,topology subnet,ping 10,ping-restart 60,route 192.168.210.0 255.255.255.0,ifconfig 192.168.217.2 255.255.255.248
      

      192.168.214.0 is specified on the server configuration while 192.168.210.0 is specified in client specific overrides (because it should be applied only to that specific client). Now what happens is Mikrotik will interpret the routes before route-gateway correctly but any route after route-gateway will get a gateway of 255.255.255.248 (i.e. ifconfig's netmask!). Surely interpreting the ifconfig netmask as the gateway of any prior routes must be a bug in RouterOS. But since I can find no official specification of OpenVPN protocol, this begs the question:

      Does the order of options in the push reply matter (per specs)?

      And even if this is correct according to specs, should pfSense - regardless of specs - place route-gateway after any route in the reply, to ensure compatibility with buggy routers? (taking into account that Mikrotiks are quite popular)?

      Edit: for anyone interested, I have worked around the issue by specifying the full push route in advanced options of client specific overrides as in:

      push "route 192.168.210.0 255.255.255.0 192.168.217.1"
      

      So the gateway is unambiguously specified. Not ideal but it works.

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