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

    IPSec/L2TP listen address 0.0.0.0 on reboot

    Scheduled Pinned Locked Moved IPsec
    8 Posts 3 Posters 730 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.
    • R
      raab
      last edited by raab

      Weird one, running 2.4.4-p3 or 2.4.5-RC

      WAN is PPPOE
      L2TP interface = WAN
      L2TP server address = 192.168.32.1
      L2TP remote range = 192.168.32.128/25

      Whenever I reboot the pfsense box ipsec/l2tp ends up listening on 0.0.0.0 instead of my WAN IP:

      Feb 11 20:05:47 pfSense l2tps: L2TP: waiting for connection on 0.0.0.0 1701

      I know this isn't standard practice, but when I try initiate a VPN connection from my phone (192.168.1.141, connected to the LAN wifi) I get:

      Feb 11 20:09:37 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:38 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:38 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:09:40 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:40 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:09:44 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:44 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:09:48 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:48 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:09:52 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:52 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:09:56 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51478
Feb 11 20:09:56 pfSense l2tps: L2TP: connect: Address already in use
Feb 11 20:10:37 pfSense l2tps: L2TP: Control connection 0x803849310 terminated: 6 (expecting reply; none received)
Feb 11 20:10:48 pfSense l2tps: L2TP: Control connection 0x803849310 destroyed

      Until it fails.

      If I disable then enable l2tp again, it listens on my WAN IP:

      pfSense l2tps: L2TP: waiting for connection on 219.x.x.x 1701

      And then I can connect from my phone, still connected to the LAN wifi:

      Feb 11 20:38:12 pfSense l2tps: Incoming L2TP packet from 192.168.1.141 51411
Feb 11 20:38:12 pfSense l2tps: L2TP: Control connection 0x803849310 219.x.x.x 1701 <-> 192.168.1.141 51411 connected
Feb 11 20:38:12 pfSense l2tps: L2TP: Incoming call #1 via connection 0x803849310 received
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] L2TP: Incoming call #1 via control connection 0x803849310 accepted
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] Link: OPEN event
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: Open event
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: state change Initial --> Starting
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: LayerStart
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] L2TP: Call #1 connected
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] Link: UP event
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: Up event
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: state change Starting --> Req-Sent
Feb 11 20:38:12 pfSense l2tps: [l2tp_l-1] LCP: SendConfigReq #1

      If I look at /var/etc/l2tp-vpn/mpd.conf, it appears to be missing set l2tp self <WAN IP>

      startup:

l2tps:
        set ippool add p0 192.168.32.128 192.168.32.129

        create bundle template l2tp_b
        set bundle enable compression
        set bundle yes crypt-reqd

        set ccp yes mppc

        set iface name l2tp
        set iface group l2tp
        set iface up-script /usr/local/sbin/vpn-linkup-l2tp
        set iface down-script /usr/local/sbin/vpn-linkdown-l2tp
        set iface disable on-demand
        set iface enable proxy-arp

        set ipcp yes vjcomp
        set ipcp ranges 192.168.32.1/32 ippool p0
        set ipcp dns 192.168.1.250

        create link template l2tp_l l2tp
        set link action bundle l2tp_b

        set link yes acfcomp protocomp
        set link enable multilink
        set link no pap chap chap-msv2
        set link enable chap

        set link keep-alive 10 180
        set link enable incoming

      When I restart l2tp:

      startup:

l2tps:
        set ippool add p0 192.168.32.128 192.168.32.129

        create bundle template l2tp_b
        set bundle enable compression
        set bundle yes crypt-reqd

        set ccp yes mppc

        set iface name l2tp
        set iface group l2tp
        set iface up-script /usr/local/sbin/vpn-linkup-l2tp
        set iface down-script /usr/local/sbin/vpn-linkdown-l2tp
        set iface disable on-demand
        set iface enable proxy-arp

        set ipcp yes vjcomp
        set ipcp ranges 192.168.32.1/32 ippool p0
        set ipcp dns 192.168.1.250

        create link template l2tp_l l2tp
        set link action bundle l2tp_b

        set link yes acfcomp protocomp
        set link enable multilink
        set link no pap chap chap-msv2
        set link enable chap
        set l2tp self 219.x.x.x
        set link keep-alive 10 180
        set link enable incoming

      I know its not normal to establish a VPN connection from within the LAN so I'm just trying to understand what's happening

      Is it listening on 0.0.0.0 after a reboot because L2TP is starting before my WAN connection is up? Is this a bug or intended behaviour?

      K 1 Reply Last reply Reply Quote 0
      • GrimetonG
        Grimeton
        last edited by

        I think your problem here is that the phone is behind the firewall when you try to connect to pfSense.

        As WAN is a PPPoE connection, the system expects the IP-address to change every now and then. So to listen on 0.0.0.0 is the better choice here.

        Don't know enough about your topology to tell you where the problem is exactly, but I'd try to go with 0.0.0.0 and make it work that way.

        R 1 Reply Last reply Reply Quote 0
        • K
          Konstanti @raab
          last edited by Konstanti

          @raab said in IPSec/L2TP listen address 0.0.0.0 on reboot:

          set l2tp self

          hi
          This means that when mpd configs are created , the WAN interface does not yet have an IP address.

            set link enable chap
  set link keep-alive 10 180

          When you restart l2tp:

          set link enable chap
set l2tp self 219.x.x.x
set link keep-alive 10 180
          1 Reply Last reply Reply Quote 0
          • R
            raab
            last edited by

            This post is deleted!
            1 Reply Last reply Reply Quote 0
            • R
              raab @Grimeton
              last edited by raab

              @Grimeton said in IPSec/L2TP listen address 0.0.0.0 on reboot:

              I think your problem here is that the phone is behind the firewall when you try to connect to pfSense.

              As WAN is a PPPoE connection, the system expects the IP-address to change every now and then. So to listen on 0.0.0.0 is the better choice here.

              Don't know enough about your topology to tell you where the problem is exactly, but I'd try to go with 0.0.0.0 and make it work that way.

              Yeah I know, which wouldn’t be a common scenario but I just find it annoying that l2tp starting before the WAN connection is up

              My wan ip is static so I wouldn’t have that issue

              Basically pfsense connected via rj45 to an ONT (fibre) pppoe is using igb0.10 (vlan 10).

              igb1 connected to a Cisco SG500 switch, AP connected to that

              Couple of vlans on igb1 for guest wireless and iot

              Pretty simple setup.

              I didn’t have this problem with the EdgeRouter 4 but I was able to specify the wan IP address in the config

              I should add this doesn’t affect connections coming from the internet, when listening on 0.0.0.0

              @Konstanti said in IPSec/L2TP listen address 0.0.0.0 on reboot:

              @raab said in IPSec/L2TP listen address 0.0.0.0 on reboot:

              set l2tp self

              hi
              This means that when mpd configs are created , the WAN interface does not yet have an IP address.

                set link enable chap
  set link keep-alive 10 180

              When you restart l2tp:

              set link enable chap
set l2tp self 219.x.x.x
set link keep-alive 10 180

              Bug or intended behaviour?

              1 Reply Last reply Reply Quote 0
              • GrimetonG
                Grimeton
                last edited by

                The thing here is that even if you'd set the ip address in the l2tp config, the moment it starts it would not find the address as the pppoe starts afterwards. Also pppoe connections can go down, which deletes the interface IP.

                I do not see a problem with l2tp listening to 0.0.0.0. The problem I see here is your testing scenario, because IPSec is pretty picky when it comes to subnets and the side you're on.

                A simple solution for the l2tp problem could be to src nat everything going out on the LAN interface from l2tp to the WAN IP...

                Problem solved.

                R 1 Reply Last reply Reply Quote 0
                • R
                  raab @Grimeton
                  last edited by

                  @Grimeton said in IPSec/L2TP listen address 0.0.0.0 on reboot:

                  The thing here is that even if you'd set the ip address in the l2tp config, the moment it starts it would not find the address as the pppoe starts afterwards. Also pppoe connections can go down, which deletes the interface IP.

                  I do not see a problem with l2tp listening to 0.0.0.0. The problem I see here is your testing scenario, because IPSec is pretty picky when it comes to subnets and the side you're on.

                  A simple solution for the l2tp problem could be to src nat everything going out on the LAN interface from l2tp to the WAN IP...

                  Problem solved.

                  Yep fair enough, I’ll leave it be 👍

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

                    Was able to get internal clients connecting just by adding a host override for my vpn domain name to point to pfsense e.g. 192.168.1.1 instead of trying to come in via the WAN IP

                    Not sure what I achieved in the end, but happy days.. 😂

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