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

    2.3 - IP alias issues broke OpenVPN on upgrade [Solved]

    Problems Installing or Upgrading pfSense Software
    4
    12
    4.6k
    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.
    • T
      techytim
      last edited by

      NOW FIXED - But only until reboot I think due to IP alias

      Apparently restarting the PHP-FPM from console broke this again or when rc.newwanip ran (but I don't know what causes that to run)

      syslog
      Apr 19 11:21:42 pfsense php-fpm[33994]: /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
      Apr 19 11:21:42 pfsense php-fpm[33994]: /rc.newwanip: rc.newwanip: on (IP address: 10.8.1.1) (interface: []) (real interface: ovpns1).
      Apr 19 11:21:42 pfsense check_reload_status: Reloading filter
      Apr 19 11:21:42 pfsense php-fpm[33994]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection -  ->  10.8.1.1 - Restarting packages.
      Apr 19 11:21:42 pfsense check_reload_status: Starting packages
      Apr 19 11:21:44 pfsense xinetd[20690]: Starting reconfiguration
      Apr 19 11:21:44 pfsense xinetd[20690]: Swapping defaults
      Apr 19 11:21:44 pfsense xinetd[20690]: readjusting service 6969-udp
      Apr 19 11:21:44 pfsense xinetd[20690]: Reconfigured: new=0 old=1 dropped=0 (services)
      Apr 19 11:21:44 pfsense php-fpm[56810]: /rc.start_packages: Restarting/Starting all packages.
      Apr 19 11:21:44 pfsense check_reload_status: Reloading filter

      openvpn
      Apr 19 11:21:41 pfsense openvpn[54461]: UDPv4 link remote: [undef]
      Apr 19 11:21:41 pfsense openvpn[54461]: Initialization Sequence Completed
      Apr 19 11:24:49 pfsense openvpn[52539]: OpenVPN 2.3.9 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Apr  6 2016
      Apr 19 11:24:49 pfsense openvpn[52539]: library versions: OpenSSL 1.0.1s-freebsd  1 Mar 2016, LZO 2.09
      Apr 19 11:24:49 pfsense openvpn[52862]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
      Apr 19 11:24:49 pfsense openvpn[52862]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
      Apr 19 11:24:49 pfsense openvpn[52862]: TCP/UDP: Socket bind failed on local address [AF_INET]x.x.x.x:1194: Address already in use
      Apr 19 11:24:49 pfsense openvpn[52862]: Exiting due to fatal error

      I've now reverted back to using LAN interface and 'local 192.168.1.254' and we're in business!

      So I think it's the IP alias issue that's caused me problems.

      Tim

      Thoughts would be helpful!

      1 Reply Last reply Reply Quote 0
      • R
        robi
        last edited by

        Why do you need an IP alias for OpenVPN?

        1 Reply Last reply Reply Quote 0
        • T
          techytim
          last edited by

          Hi Robi,

          I don't need an IP alias for OpenVPN, I need one for my PPPoE WAN connection as its a dynamic IP with routed static public IPs from BT. I just open the ports for OpenVPN only for that VIP.

          I can't use the VIPs currently as I keep getting the error 'Can't assign requested address' but I never did it like that in the first place.

          Am I making sense?

          1 Reply Last reply Reply Quote 0
          • R
            robi
            last edited by

            Perhaps you should bind your OpenVPN server only to localhost (127.0.0.1), and make a simple port forward from your VIP address to localhost.
            You could also bind your OpenVPN server to all interfaces (any), and make a simple allow firewall rule for the incoming traffic on that interface, with "Destination" set to that specific VIP address.

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              Probably better to have those aliases on localhost rather than the WAN in the case of a routed subnet over PPPoE anyway. Though I wouldn't have expected that to stop working. I'll check into that circumstance when I have a moment.

              1 Reply Last reply Reply Quote 0
              • T
                techytim
                last edited by

                Thanks robi and cmb.

                At the moment, midweek, I need to leave it up, but I'll try a reboot at the weekend and then look in to that.

                I've ended up confusing myself with the Outbound NAT configuration though, should I need a rule from the OpenVPN subnet via the VIP I want to use?

                The reason I ask is when it all screwed up, during diagnosis at one point I could see the traffic would get in…it just couldn't get it to go back out!

                Since upgrade I also still can't see all of my VIPs in the drop down in OpenVPN, only those I've deleted and re-added - see the attachments.

                vip.PNG
                vip.PNG_thumb
                OpenVPN_inteface-dropdown.png
                OpenVPN_inteface-dropdown.png_thumb

                1 Reply Last reply Reply Quote 0
                • G
                  gerdesj
                  last edited by

                  @cmb:

                  Probably better to have those aliases on localhost rather than the WAN in the case of a routed subnet over PPPoE anyway. Though I wouldn't have expected that to stop working. I'll check into that circumstance when I have a moment.

                  As CMB points out, the aliases for a PPPo(EA) link do not work properly if attached to the WAN itself.  You can use localhost as suggested but if you have a device such as a modem and it has a web interface then I do the following:

                  • Assign a new interface that corresponds to the physical NIC that WAN "dials" through.  Call it something like WANNIC (I've got four of them on one box I manage WAN1NIC, WAN2NIC etc)

                  • Give it an RFC1918 IP address that will work with your modem.  Some modems have a little DHCP server on them, so you could use that

                  • Create a NAT rule on WANNIC that NATs your internal LAN to the IP on the new interface

                  Now you can get to the web interface for the modem for monitoring or whatever

                  Finally, attach the relevant IP aliases to the WANNIC interface and you can now bind IPSEC/OpenVPN etc to them and they will work.

                  Inbound access rules to your IP aliases go on the WAN interface and not WANNIC.  You will need one for OpenVPN but not for IPSEC (automatically works)

                  1 Reply Last reply Reply Quote 0
                  • R
                    robi
                    last edited by

                    As far as I understood, aren't these Alias IPs public addresses? What would be the point to create aliases of public addresses to interfaces belonging to private networks (including localhost)?

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      @robi:

                      As far as I understood, aren't these Alias IPs public addresses? What would be the point to create aliases of public addresses to interfaces belonging to private networks (including localhost)?

                      So you have them bound somewhere. In non-PPPoE cases, you usually need them on WAN to answer ARP for those addresses. In the PPPoE case, the static subnet is routed to your dynamically-assigned PPPoE address by the ISP, so no need for ARP, but you need the IPs bound somewhere to use them for services.

                      1 Reply Last reply Reply Quote 0
                      • T
                        techytim
                        last edited by

                        I know this is an old thread now but I only just rebooted my box the other day after upgrading the hardware - the restore was fine but the reboot broke the VIPs again and the same errors resulted in the logs.

                        I made the suggestions and bound the VIPs to the localhost and everything came back up okay! :)

                        Thank you for all your help, had I have not heard that from you guys I'd have had to result to command line to fix.

                        Cheers,

                        Tim

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