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

    Routing problem on Multi WAN configuration

    Scheduled Pinned Locked Moved 1.2.3-PRERELEASE-TESTING snapshots - RETIRED
    8 Posts 5 Posters 7.6k 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.
    • W
      wdavid
      last edited by

      I have a very strange problem with my firewall 1.2.3-RC3 built on Sun Oct 11 03:50:54 UTC 2009
      In general I can say that IP addresses that end with the number between 224 and 239 are always "routed" through WAN.
      I have a multi wan configuration where the WAN interface is my backup connection and the OPT1 is the main where I have 64 IP addresses NAT-ed to local servers (with CARP and Load balancing/failover)
      I have many LAN rules but in general all traffic is routed through a FailOver interface where the OPT1 has priority.
      But now when I’m trying to make tarceroute from any computer in the LAN to an IP that ends with 224-239 the route is always through the WAN interface. This makes impossible to access my server from outside for some clients.

      Let me repeat, the pattern of the IP is X.X.X.224 - X.X.X.239 where X can be almost anything.

      Will try to go back to a previous build, and see how it works. If someone know a stable build pleas drop me a line.

      Update 10/13/09 - I've tried to upgrade the firmware to the oldest, the newest and other random builds from http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2 and NONE of them are working correctly. Went back to 1.2.3-RC1 and now it's OK. Next step I will try to reproduce this behavior in a simplified virtual environment.

      David.

      1 Reply Last reply Reply Quote 0
      • W
        wdavid
        last edited by

        I’ve tried to reproduce the problem on a fresh virtual environment and I had the same behavior. I think this is a major issue that needs to be fixed ASAP.
        Here is the configuration:

        pfSense  1.2.3-RC3 built on Tue Oct 13 03:53:26 UTC 2009

        LAN interface (de0)
        IP address 192.168.1.1  
        Subnet mask 255.255.255.0

        WAN interface (de1)
        IP address 10.1.1.223  
        Subnet mask 255.255.0.0
        Gateway 10.1.2.1

        OPT1 interface (de2)
        IP address 10.0.0.201  
        Subnet mask 255.255.255.0
        Gateway 10.0.0.1

        All the rules and NAT settings of the firewall are the default of the initial setup wizard, except the rule on the LAN where I’m telling that everything from the LAN to be routed through 10.0.0.1 (OPT1 and NOT WAN).

        Not so important but both WAN and OPT1 networks are connected to the internet through 2 separate external firewalls.

        Client configuration – Windows XP
        LAN adapter
        IP 192.168.1.100
        Subnet mask 255.255.255.0
        Gateway 192.168.1.1

        Some traceroute examples form the client computer: (explains everything)

        C:>tracert 1.1.1.223

        Tracing route to 1.1.1.223 over a maximum of 30 hops

        1     2 ms     1 ms     1 ms  10.0.0.1
         2    20 ms    19 ms    19 ms  222.145.225.175
        ^C  
        C:>tracert 1.1.1.224

        Tracing route to 1.1.1.224 over a maximum of 30 hops

        1    <1 ms    <1 ms    <1 ms  192.168.1.1
         2    16 ms    19 ms    19 ms  85.139.62.193
        ^C  
        C:>tracert 1.1.1.239

        Tracing route to 1.1.1.239 over a maximum of 30 hops

        1    <1 ms    <1 ms    <1 ms  192.168.1.1
         2    17 ms    19 ms    19 ms  85.139.62.193
        ^C
        C:>tracert 1.1.1.240

        Tracing route to 1.1.1.240 over a maximum of 30 hops

        1     2 ms     1 ms     1 ms  10.0.0.1
         2    29 ms    17 ms    19 ms  222.145.225.175
        ^C  
        C:>tracert 54.54.54.223

        Tracing route to 54.54.54.223 over a maximum of 30 hops

        1     2 ms     1 ms     1 ms  10.0.0.1
         2     *       29 ms    19 ms  222.145.225.175
        ^C
        C:>tracert 54.54.54.224

        Tracing route to 54.54.54.224 over a maximum of 30 hops

        1    <1 ms    <1 ms    <1 ms  192.168.1.1
         2    14 ms    19 ms    20 ms  85.139.62.193
        ^C
        C:>tracert 154.154.154.223

        Tracing route to 154.154.154.223 over a maximum of 30 hops

        1     2 ms     1 ms     1 ms  10.0.0.1
        ^C
        C:>tracert 154.154.154.224

        Tracing route to 154.154.154.224 over a maximum of 30 hops

        1    <1 ms    <1 ms    <1 ms  192.168.1.1
        ^C
        C:>tracert 154.154.154.240

        Tracing route to 154.154.154.240 over a maximum of 30 hops

        1     2 ms     1 ms     1 ms  10.0.0.1
        ^C

        Conclusion: If the IP address ends with a number between 224 and 240, the LAN rule to route the packet through OPT1 interface is ignored.

        pfSenseRule.PNG
        pfSenseRule.PNG_thumb

        1 Reply Last reply Reply Quote 0
        • dotdashD
          dotdash
          last edited by

          Thanks for reporting this. I thought I had lost my mind. I was doing some tests with 1.2.3RC3 running dual-wan and CP with per-user bandwidth. It was going surprisingly well until I encountered this.
          I didn't see an issue filed for this, so I took the liberty of putting one in. (Bug 111)

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

            I'm having the same issue with .224-.240 addresses on my wan.  What's even more strange is it seems to route for me as long as the connecting ip isn't also in the .224-.240 range.

            Andy

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

              Confirmed issue, looks like our patch to bypass route-to for multicast traffic has the bits flipped (last octet rather than first). We're looking at a solution.

              1 Reply Last reply Reply Quote 0
              • A
                althornin
                last edited by

                I just got bit by this also.
                I could not figure out why sometimes, while using VZaccess (cellular broadband), I was unable to connect to anything on my network.
                I'm basically in the same boat as the OP - my OPT1 (WAN2) interface has much more bandwidth, and is the primary route on a failover loadbalancer pool.

                I'm in the process of replacing some linksys vpn routers with pfsense, and this is the last barrier in my way right now.

                Thanks for the prompt attention on this issue.

                1 Reply Last reply Reply Quote 0
                • A
                  althornin
                  last edited by

                  Just tested this in todays 2GB snapshot, and it works.
                  Looks like this issue has been resolved.  Thanks for the quick action guys!
                  Beyond the tracert testing which shows it is fixed, I went to the further step of playing with a laptop with vzaccess until is managed to get an IP ending in .235
                  That client is still able to correctly connect to the servers - so everything is working.

                  1 Reply Last reply Reply Quote 0
                  • W
                    wdavid
                    last edited by

                    I'm running with version 1.2.3-RC3 built on Sat Oct 17 21:42:17 UTC 2009 and everything seems fine now. Thank you quys for the fast answers and fix.

                    David.

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