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

Multiple OpenVPN Servers on Multi WAN

Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
3 Posts 3 Posters 3.2k 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
    Boolah
    last edited by Aug 9, 2010, 4:17 PM

    Running pfSense 2.0-BETA4 built on Mon Aug 9 13:46:39 UTC 2010

    I've got two WAN connections (both connections are static with unique gateways).  I'm trying to setup two OpenVPN servers, each dedicated to their respective WAN connection, and I can in fact do this.  The issue is I cannot have both OpenVPN servers bind to the same port, even though each server is bound to a unique WAN interface.  Creating the first OpenVPN server on WAN1 and UDP port 1194 works fine, but when I create the second OpenVPN server on WAN2 and UDP port 1194, I get the follow error from the WebGUI:

    The following input errors were detected:

    * The specified 'Local port' is in use. Please select another value

    If I change the port to UDP 1195 on WAN2, both servers start up fine.  Looking at a 'netstat -np udp' I can see each server bound to their respective IPs, albeit on different ports.

    Is there a reason why both servers cannot bind to 1194 since they're on different IPs/interfaces?

    1 Reply Last reply Reply Quote 0
    • E
      eri--
      last edited by Aug 9, 2010, 10:11 PM

      I opened a bug for this to not forget because it should be allowed.
      http://redmine.pfsense.org/issues/814

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by Aug 14, 2010, 7:30 PM

        Technically, no, but the port used is also the port selected for the management interface, which all run on 127.0.0.1, hence allowing that would create a number of complications. There needs to be an alternative for that in the future without breaking the Status page, that's a pretty involved change though so the ticket has been postponed to a future release.

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