Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    L2TP tunnel struggles to reconnect

    Scheduled Pinned Locked Moved General pfSense Questions
    36 Posts 2 Posters 559 Views 2 Watching
    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 Offline
      aznarepse
      last edited by

      When it works these lines are not included in the log. However, it appears to me that it receives the IP6 address in the log lines that precede these as follows:
      Apr 7 08:50:41 ppp 40211 [opt2] IPV6CP: rec'd Configure Request #0 (Ack-Rcvd)
      Apr 7 08:50:41 ppp 40211 [opt2] IPV6CP: SendConfigAck #0
      Apr 7 08:50:41 ppp 40211 [opt2] IPV6CP: state change Ack-Rcvd --> Opened
      Apr 7 08:50:41 ppp 40211 [opt2] IPV6CP: LayerUp
      Apr 7 08:50:41 ppp 40211 [opt2] 0215:5dff:xx:xx -> 9e89:xx:xx:0000

      1 Reply Last reply Reply Quote 0
      • stephenw10S Offline
        stephenw10 Netgate Administrator
        last edited by stephenw10

        Hmm, so it completes the connection then receives additional config from the server end.

        Do you actually need IPv6 there?

        Can you use some other tunnel type?

        You might be able to use a custom mpd.conf file with that. I've only ever tried that for PPPoE though.

        1 Reply Last reply Reply Quote 0
        • A Offline
          aznarepse
          last edited by

          I do not need IPv6. Have set the interface as SLAAC for IPv6 after trying other options without success.
          Unfortunately, the reason I am using this tunnel is because I need a static IP that cannot be obtained through the 5G supplier. The tunnel is with A&A. This tunnel is not encrypted and the performance is almost identical than without tunnel.

          I could try to get a VPN of sorts with nord or similar, but was conscious of the potential impact in performance.

          That's an interesting suggestion. I have looked into mpd5 and have found some examples for L2TP.
          Sorry for the ignorant question: what would the advantage be compared to using the UI for configuring the tunnel?

          stephenw10S 1 Reply Last reply Reply Quote 0
          • A Offline
            aznarepse
            last edited by

            Right, I might have found something.

            When the interface is in this state, the remote server still thinks it is connected.
            The dpinger log checking for monitoring the gateway gives an error and the...
            The log of the firewall shows
            Screenshot 2026-04-08 094413.png
            where WAN2 is the 5G gateway. The ping seems to be channeled through the active gateway (from the fail-over group) but it is being blocked by the firewall. Odd

            1 Reply Last reply Reply Quote 0
            • A Offline
              aznarepse
              last edited by

              Sorry, forgot to highlight that the ping through the 5G gateway is from the static IP of the tunnel gateway to 1.1.1.1

              1 Reply Last reply Reply Quote 0
              • A Offline
                aznarepse
                last edited by aznarepse

                checking /tmp/rules.debug in SSH list, among many, the following rule:

                "# gateway monitoring
                block out log quick inet proto icmp from any to 1.1.1.1 icmp-type echoreq ridentifier 1000008011 label "gateway monitoring""

                Which I have definitely not created and it is not visible from the UI.

                I have created a floating rule to allow ICMP to any address but does not seem to work and the traffic is still blocked.

                1 Reply Last reply Reply Quote 0
                • A Offline
                  aznarepse
                  last edited by aznarepse

                  Correction. After further testing, the below does not hold true. Still unreachable.

                  "One more update.
                  I have deleted the gateway monitoring IP so it defaults to its own address (according to the documentation at https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html)

                  With this change the inbound traffic works, even if the interface falls into the discussed status, routing outbound traffic through the 5G gateway. The server is reachable from the internet through its static IP. The gateway status shows as 'Pending'

                  This is an improvement, but I still think the tunnel gateway should work in both directions."

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S Offline
                    stephenw10 Netgate Administrator
                    last edited by

                    Do you not see states on the L2TP interface when the tunnel is up correctly? I expect to see the gateway monitoring pings there and specifically not on the 5G WAN.

                    Traffic using the L2TP tunnel address as source should be blocked on the 5G WAN since that should only ever leave over the tunnel.

                    One thing to check is that if you use 1.1.1.1 for monitoring it should not be used anywhere else. Or at least if it is care must be taken that the static routes it adds do not create a conflict,

                    1 Reply Last reply Reply Quote 0
                    • A Offline
                      aznarepse
                      last edited by

                      The tunnel seems to be up in all cases. Checking the connection status at A&A confirms this.

                      When no traffic goes through the L2TP gateway, I only see incoming states (robots looking for open ports that are blocked) but no open states.
                      When all is working well, the expected states for the L2TP gateway are present.

                      I can see the logic for the ping to 1.1.1.1 being blocked through the 5G gateway. However, it appears that since the L2TP gateway is down the ping is routed to the now promoted to 'default' (by the fail-over) 5G gateway?

                      I tried to set a static route for 1.1.1.1 to the L2TP gateway, but it does not work, since I cannot ping through the tunnel interface.

                      Every time that I bring down the tunnel to test, it takes me few hours to make it work again by repeatedly bringing it down and up until eventually works. If I restart the router it normally works first time.
                      Another thing that helps is if I change the monitoring IP (until it goes down again).

                      stephenw10S 1 Reply Last reply Reply Quote 0
                      • stephenw10S Offline
                        stephenw10 Netgate Administrator @aznarepse
                        last edited by

                        @aznarepse said in L2TP tunnel struggles to reconnect:

                        I tried to set a static route for 1.1.1.1 to the L2TP gateway, but it does not work, since I cannot ping through the tunnel interface.

                        Hmm, you shouldn't need to do that. Adding a custom monitoring IP automatically adds a static route unless you explicitly choose not to.

                        It's got to be some bad state that gets created. What happens if you just reset all the states?

                        1 Reply Last reply Reply Quote 0
                        • A Offline
                          aznarepse
                          last edited by

                          I have tried resetting the states (many times) but it does not make any difference.

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S Offline
                            stephenw10 Netgate Administrator
                            last edited by

                            Hmm. So maybe forcing all states to recreate hits the same issue again. The required ordering is in place only at boot or perhaps by luck when you're restarting it.

                            So when it's in the failed state you see incoming blocked traffic on the L2TP interface. But no outgoing states?

                            If you send some test traffic do you see it leaving on the L2TP or 5G interfaces?

                            1 Reply Last reply Reply Quote 0
                            • A Offline
                              aznarepse
                              last edited by

                              There are no outgoing states when it does not work. Occasionally, an income state shows on the interface with no outgoing traffic; this, I assume, because DNS are pointing to the static IP.
                              Any traffic leaves through the 5G interface. If I try to do a ping through the L2TP interface, it fails.
                              If I check the public IP, I get the IP of the 5G gateway.

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S Offline
                                stephenw10 Netgate Administrator
                                last edited by

                                Hmm, so the L2TP gateway is shown as down and the policy routing group therefore switches to the 5G gateway?

                                Something else potentially is that there are two L2TP sessions established somehow with each using a different one. But in that case I'd expect to see two states present.

                                1 Reply Last reply Reply Quote 0
                                • A Offline
                                  aznarepse
                                  last edited by

                                  Not sure I understand. The ISP provider would only allow one session?
                                  To me, a significant difference between when it works or not is that the uptime shows or not. There must be something in the logic that triggers that and tells the router that the connection is available?

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S Offline
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    I've never really looked too deep into L2TP but, for example, with IPSec we have seen situations where a connection is renegotiated and one end switches to the new connection before the other end completes the connection. Then you end up with each end using a different connection until it fails completely.

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S Offline
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Just reviewing; has this ever worked reliably? In another pfSense version perhaps?

                                      1 Reply Last reply Reply Quote 0
                                      • A Offline
                                        aznarepse
                                        last edited by

                                        I have only had this since last October and have been behaving like this since.
                                        Once it works, it stays up solid
                                        affbb86d-4831-4ae8-bcee-7c30a38d2447-image.png

                                        It is only when it drops and reconnects. It then misbehaves: both ends, client and server, say it is connected, but the Uptime shows nothing and no traffic can go through it.

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S Offline
                                          stephenw10 Netgate Administrator @aznarepse
                                          last edited by

                                          @aznarepse said in L2TP tunnel struggles to reconnect:

                                          I do not need IPv6. Have set the interface as SLAAC for IPv6 after trying other options without success.

                                          If you set IPv6 to none do you still hit this?

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S Offline
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            I'm failing to replicate this locally with a 2.8.1 client device so far but I can't test it with IPv6.

                                            Manually disconnecting and reconnecting the tunnel works everytime for me:

                                            Apr 10 15:03:48 	ppp 	44970 	caught fatal signal TERM
Apr 10 15:03:48 	ppp 	44970 	[opt2] IFACE: Close event
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: Close event
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: state change Opened --> Closing
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: SendTerminateReq #4
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: LayerDown
Apr 10 15:03:48 	ppp 	44970 	[opt2] IFACE: Removing IPv4 address from l2tp0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address
Apr 10 15:03:48 	ppp 	44970 	[opt2] IFACE: Down event
Apr 10 15:03:48 	ppp 	44970 	[opt2] IFACE: Rename interface l2tp0 to l2tp0
Apr 10 15:03:48 	ppp 	44970 	[opt2] IFACE: Set description "L2TP0"
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: rec'd Terminate Ack #3 (Closing)
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: state change Closing --> Closed
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: LayerFinish
Apr 10 15:03:48 	ppp 	44970 	[opt2] Bundle: No NCPs left. Closing links...
Apr 10 15:03:48 	ppp 	44970 	[opt2] Bundle: closing link "opt2_link0"...
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] Link: CLOSE event
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: Close event
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: state change Opened --> Closing
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] Link: Leave bundle "opt2"
Apr 10 15:03:48 	ppp 	44970 	[opt2] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: Close event
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: Down event
Apr 10 15:03:48 	ppp 	44970 	[opt2] IPCP: state change Closed --> Initial
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: SendTerminateReq #2
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: LayerDown
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: rec'd Terminate Ack #3 (Closing)
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: state change Closing --> Closed
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: LayerFinish
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] L2TP: Call #4850000 terminated locally
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] Link: DOWN event
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] Link: giving up after 0 reconnection attempts
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: Close event
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: Down event
Apr 10 15:03:48 	ppp 	44970 	[opt2_link0] LCP: state change Closed --> Initial
Apr 10 15:03:50 	ppp 	44970 	[opt2] Bundle: Shutdown
Apr 10 15:03:50 	ppp 	44970 	[opt2_link0] Link: Shutdown
Apr 10 15:03:50 	ppp 	44970 	process 44970 terminated
Apr 10 15:03:59 	ppp 	4978 	Multi-link PPP daemon for FreeBSD
Apr 10 15:03:59 	ppp 	4978 	process 4978 started, version 5.9
Apr 10 15:03:59 	ppp 	4978 	web: web is not running
Apr 10 15:03:59 	ppp 	4978 	[opt2] Bundle: Interface ng0 created
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] Link: OPEN event
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: Open event
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: state change Initial --> Starting
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: LayerStart
Apr 10 15:03:59 	ppp 	4978 	L2TP: Initiating control connection 0x5b2035073310 172.21.16.148 0 <-> 172.21.16.11 1701
Apr 10 15:03:59 	ppp 	4978 	L2TP: Control connection 0x5b2035073310 172.21.16.148 56015 <-> 172.21.16.11 1701 connected
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] L2TP: Incoming call #5160000 via control connection 0x5b2035073310 initiated
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] L2TP: Call #5160000 connected
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] Link: UP event
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: Up event
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: state change Starting --> Req-Sent
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: SendConfigReq #1
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MAGICNUM 0xd223aa28
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: rec'd Configure Request #1 (Req-Sent)
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MAGICNUM 0x1fadd1b1
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] AUTHPROTO CHAP MSOFTv2
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MP MRRU 2048
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MP SHORTSEQ
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] ENDPOINTDISC [802.1] 00 08 a2 12 ec d6
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: SendConfigRej #1
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MP MRRU 2048
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MP SHORTSEQ
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: rec'd Configure Request #2 (Req-Sent)
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MAGICNUM 0x1fadd1b1
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] AUTHPROTO CHAP MSOFTv2
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: SendConfigAck #2
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] MAGICNUM 0x1fadd1b1
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] AUTHPROTO CHAP MSOFTv2
Apr 10 15:03:59 	ppp 	4978 	[opt2_link0] LCP: state change Req-Sent --> Ack-Sent
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: rec'd Configure Request #3 (Ack-Sent)
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MAGICNUM 0x1fadd1b1
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] AUTHPROTO CHAP MSOFTv2
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: SendConfigAck #3
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MAGICNUM 0x1fadd1b1
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] AUTHPROTO CHAP MSOFTv2
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: SendConfigReq #2
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MAGICNUM 0xd223aa28
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: rec'd Configure Ack #2 (Ack-Sent)
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] ACFCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] PROTOCOMP
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MRU 1500
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MAGICNUM 0xd223aa28
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: state change Ack-Sent --> Opened
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: auth: peer wants CHAP, I want nothing
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: LayerUp
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] CHAP: rec'd CHALLENGE #1 len: 21
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] Name: ""
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] CHAP: Using authname "Test"
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] CHAP: sending RESPONSE #1 len: 58
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] CHAP: rec'd SUCCESS #1 len: 46
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] MESG: S=9A4EA31A6E9753BBE2B615678AB749C72C14053F
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] LCP: authorization successful
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] Link: Matched action 'bundle "opt2" ""'
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] Link: Join bundle "opt2"
Apr 10 15:04:01 	ppp 	4978 	[opt2] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: Open event
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: state change Initial --> Starting
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: LayerStart
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: Up event
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: state change Starting --> Req-Sent
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: SendConfigReq #1
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 0.0.0.0
Apr 10 15:04:01 	ppp 	4978 	[opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Apr 10 15:04:01 	ppp 	4978 	[opt2] PRIDNS 0.0.0.0
Apr 10 15:04:01 	ppp 	4978 	[opt2] SECDNS 0.0.0.0
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: rec'd Configure Request #1 (Req-Sent)
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 10.56.56.254
Apr 10 15:04:01 	ppp 	4978 	[opt2] 10.56.56.254 is OK
Apr 10 15:04:01 	ppp 	4978 	[opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: SendConfigAck #1
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 10.56.56.254
Apr 10 15:04:01 	ppp 	4978 	[opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: state change Req-Sent --> Ack-Sent
Apr 10 15:04:01 	ppp 	4978 	[opt2_link0] rec'd unexpected protocol CCP, rejecting
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: rec'd Configure Nak #1 (Ack-Sent)
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 10.56.56.10
Apr 10 15:04:01 	ppp 	4978 	[opt2] 10.56.56.10 is OK
Apr 10 15:04:01 	ppp 	4978 	[opt2] PRIDNS 192.168.135.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] SECDNS 172.21.16.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: SendConfigReq #2
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 10.56.56.10
Apr 10 15:04:01 	ppp 	4978 	[opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Apr 10 15:04:01 	ppp 	4978 	[opt2] PRIDNS 192.168.135.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] SECDNS 172.21.16.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: rec'd Configure Ack #2 (Ack-Sent)
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPADDR 10.56.56.10
Apr 10 15:04:01 	ppp 	4978 	[opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Apr 10 15:04:01 	ppp 	4978 	[opt2] PRIDNS 192.168.135.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] SECDNS 172.21.16.1
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: state change Ack-Sent --> Opened
Apr 10 15:04:01 	ppp 	4978 	[opt2] IPCP: LayerUp
Apr 10 15:04:01 	ppp 	4978 	[opt2] 10.56.56.10 -> 10.56.56.254
Apr 10 15:04:02 	ppp 	4978 	[opt2] IFACE: Up event
Apr 10 15:04:02 	ppp 	4978 	[opt2] IFACE: Rename interface ng0 to l2tp0
Apr 10 15:04:02 	ppp 	4978 	[opt2] IFACE: Add description "L2TP0"
                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.