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

Route-gateway wrong with server-bridge dhcp set

Scheduled Pinned Locked Moved OpenVPN
3 Posts 2 Posters 1.7k 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.
  • B
    bmwt
    last edited by Mar 16, 2017, 3:42 PM

    Good morning,

    We are currently using pfsense as a road-warrior vpn service, bridged to a subnet that already has a (non-pfsense) router.  I'm having a problem with the openvpn service .  The service is running in tap mode to a bridge on LAN, for which the pfsense server is not the primary gateway.

    (I've changed the first 2 octets to 10.1 in the following output- the real subnet is internet route-able)

    10.1.0.1 - non-pfsense router gateway
    10.1.0.2 - pfsense LAN interface

    LAN has 10.1.0.1 properly set as its interface gateway, yet openvpn still pushes "route-gateway 10.1.0.2" when a client connects (along with the proper ifconfig address).  This of course means that traffic isnt flowing, as 10.1.0.2 isn't a forwarding gateway for the network.  10.1.0.1 is defined as the gateway for the LAN interface, and is also specified in the DHCP config as the gateway.

    Please note that the bridge is working.  If i leave out the "server bridge dhcp start" range, windows clients do pass through and get an address from the DHCP server on the LAN interface.  This isnt workable for us tho, as the linux clients need the ifconfig line pushed.

    relevant openvpn settings:

    bridge dhcp : checked
    bridge interface : LAN
    server bridge dhcp start:  10.1.0.150
    server bridge dhcp end:  10.1.0.200
    redirect-gateway: checked
    no extra options set

    I've tried unchecking redirect-gateway and adding my own push "route-gateway" with the proper gateway, but the service still sets it to 10.1.0.2

    029838/Z.Z.Z.51:1194 SENT CONTROL [029838]: 'PUSH_REPLY,dhcp-option DNS X.X.X.X,dhcp-option DNS Y.Y.Y.Y,redirect-gateway def1,route-gateway 10.1.0.2,ping 10,ping-restart 60,ifconfig 10.1.0.150 255.255.255.0' (status=1)

    Am i missing something?  is there a way to tell openvpn to use the correct value for route-gateway?

    thanks,

    -bmwt

    1 Reply Last reply Reply Quote 0
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Mar 16, 2017, 8:04 PM

      For a bridged setup, our config doesn't specify that, so it uses whatever OpenVPN decides to use. That gets muddy when a bridge is involved, since OpenVPN doesn't have any knowledge of what the "real" gateway should be.

      Have you tried setting "route gateway 10.1.0.1;" in the advanced options of the server (without using push) to see if that kicks it in?

      Alternately, you can push route statements to the clients that include a gateway using advanced options for example:

      push "route x.x.x.0 255.255.255.0 10.1.0.1";

      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      1 Reply Last reply Reply Quote 0
      • B
        bmwt
        last edited by Mar 16, 2017, 9:15 PM

        I found a workaround of sorts:

        • unchecked the "bridge dhcp" box
        • left "bridge interface" set to none
        • left "server bridge dhcp start" and "end" blank

        in custom options i added:

        server-bridge 10.1.0.1 255.255.255.0 10.1.0.150 10.1.0.200; push "redirect-gateway def1"

        (it was the "server bridge" command that was setting the wrong gateway in the openvpn config.  As i wanted to keep all config in the xml, this seemed like the easiest workaround)

        thanks!

        -bmwt

        1 Reply Last reply Reply Quote 0
        2 out of 3
        • First post
          2/3
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
          This community forum collects and processes your personal information.
          consent.not_received