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

    VPN routing broken afer upgrade to 23.01

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 5 Posters 1.5k 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
      bambam
      last edited by

      After the upgrade to 23.01 from 22.05 (SG-2440) it appears routing via site to site VPN is broken. Trying to access servers on the other site from a LAN computer doesn't work. I can however ping the same servers from the router via the Ping utility.

      If i use tracert for an IP address via a LAN computer, it shows it trying to use the default route GW listed in the Routing table instead of the VPN route GW.

      I will attempt to boot the previous version via Boot Environments.

      M 1 Reply Last reply Reply Quote 0
      • M
        michmoor LAYER 8 Rebel Alliance @bambam
        last edited by

        @bambam Not a lot of details here.
        What hardware is 23.01 running on?
        What VPN protocol?
        Are you using static routing?

        Firewall: NetGate,Palo Alto-VM,Juniper SRX
        Routing: Juniper, Arista, Cisco
        Switching: Juniper, Arista, Cisco
        Wireless: Unifi, Aruba IAP
        JNCIP,CCNP Enterprise

        B 1 Reply Last reply Reply Quote 0
        • B
          bambam @michmoor
          last edited by

          @michmoor It's running on a Netgate SG-2440. OpenVPN clients connecting to several different pfSense VMs (these haven't been upgraded). No static routing, OpenVPN creates the routing table entries. It's a multi-wan setup but in a Gateway group.

          DerelictD 1 Reply Last reply Reply Quote 0
          • F
            FSC830
            last edited by

            No issues here with site-to-site VPN, but I am using IPsec, not openVPN.
            Access to devices in remote network is possible.

            Regards

            B 1 Reply Last reply Reply Quote 0
            • B
              bambam @FSC830
              last edited by

              It seems to ignore the routing table entries and uses the default which is the wan.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate @bambam
                last edited by

                @bambam said in VPN routing broken afer upgrade to 23.01:

                @michmoor It's running on a Netgate SG-2440. OpenVPN clients connecting to several different pfSense VMs (these haven't been upgraded). No static routing, OpenVPN creates the routing table entries. It's a multi-wan setup but in a Gateway group.

                Sounds like it's matching policy routing.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                B 1 Reply Last reply Reply Quote 0
                • B
                  bambam @Derelict
                  last edited by

                  @derelict Thanks for the info - what does this mean though, and is there anyway i can fix this?

                  DerelictD 1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate @bambam
                    last edited by

                    @bambam You said multi-WAN. That means you are policy routing to gateway groups. Need to look at the routing rules on the interface you are trying to use for the VPN and see where the traffic is being directed.

                    https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    B 1 Reply Last reply Reply Quote 1
                    • E
                      edirob
                      last edited by

                      Thanks. I had the same issue and had to blow away an old multi-WAN configuration to make this work. I'm glad I found this message right away!

                      DerelictD 1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate @edirob
                        last edited by

                        @edirob

                        Multi-WAN is pretty simple. It's the introduction of policy routing that makes life difficult.

                        I haven't run policy routing (for Multi-WAN purposes) since the option was added to set a gateway group as the default route target. (System > Routing).

                        That's all I have done for years. Took out all the gateways on all the rules and I'm much happier for it.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        1 Reply Last reply Reply Quote 0
                        • B
                          bambam @Derelict
                          last edited by

                          @derelict Thanks for pointing this out - we hadn't had a rule on the previous version but added it in before the gateway rule and all is working OK again.

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