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

    Different WANS for different LANS - how to force it?

    Scheduled Pinned Locked Moved Routing and Multi WAN
    14 Posts 3 Posters 3.4k 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
      rockbear
      last edited by

      I have a pfsense firewall setup primarily as a NAT box.

      I have this setup:

      1.0.0.1/24          2.0.0.1/24            3.0.0.1/24
      priv_outside      unpriv_outside      WLAN_outside
      (defgw)    |                |                |
                  –---------------------------
                  |            pfsense              |
                  -----------------------------
                    |                  |                |
      priv_inside            unpriv_inside    WLAN_inside
      11.0.0.1/24          12.0.0.1/24      13.0.0.1/24

      I NAT the users on priv_inside to 1.0.0.1
      I NAT the users on unpriv_inside to 2.0.0.1
      I NAT the users on WLAN_inside to 3.0.0.1

      I have set up rules on the _inside interfaces using the "gateway" adv. feature to force traffic to leave using the matching _outside interface. This works fine... most of the time.

      However, When a user on WLAN_inside (or unpriv_inside) wants to access a host on priv_outside (such as 1.0.0.5), they are routed through priv_outside. I don't want that. I want them to always be routed through the gateway I've set in the adv. feature.

      Any suggestions? Have I missed something?

      I run 2.0.1-release.

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        In your outbound rules you can setup "NOT" rules instead of "Any". Create 3 aliases. In them include 2 of the interface subnets. In the outbound rule for like priv_inside, set the destination to not the other 2 subnets. This way, if the destination is the other 2 networks it will not NAT, but for all other locations it will.

        On a side note, I am hoping those are not the IPs you are actually using.

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

          @podilarius:

          In your outbound rules you can setup "NOT" rules instead of "Any". Create 3 aliases. In them include 2 of the interface subnets. In the outbound rule for like priv_inside, set the destination to not the other 2 subnets. This way, if the destination is the other 2 networks it will not NAT, but for all other locations it will.

          hmmmm… I may have been unclear. It's not NAT I am concerned about, but routing. If a user on 12.0.0.5 wants to access a service on 1.0.0.8, today he is just forwarded to the 1.0.0.1 interface. I want him to be natted behind 2.0.0.1 and then routed across the internet (not shown).

          The advanced feature "gateway" allows me to set 2.0.0.1 as default gateway for all traffic from 12.0.0.5, but it appears the firewall prefers the more specific route 1.0.0.0/24 over the default route. This is completely correct in routing terms, but not what I need.

          @podilarius:

          On a side note, I am hoping those are not the IPs you are actually using.

          Heh. They are not. It's simplified for.. ehm.. simplicity :)

          1 Reply Last reply Reply Quote 0
          • P
            podilarius
            last edited by

            SO, if you set the gateway in the rules for the 12.0.0.1/24 and in the outbound NAT you set the correct interface, subnet and NAT address, it should work. Are you using any extra services like squid?

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

              @podilarius:

              SO, if you set the gateway in the rules for the 12.0.0.1/24 and in the outbound NAT you set the correct interface, subnet and NAT address, it should work.

              And it does work - as long as the destination is not a host on a network local to the pfsense unit. If it is, the gateway option is ignored, it seems.

              Are you using any extra services like squid?

              No.

              1 Reply Last reply Reply Quote 0
              • P
                podilarius
                last edited by

                What does your rule state and what do your NAT rules look like?

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

                  @podilarius:

                  What does your rule state and what do your NAT rules look like?

                  Rule on WLAN_inside:

                  Interface WLAN_inside
                  proto any
                  source WLAN_inside subnet
                  Gateway 3.0.0.2 [that is the router beyond WLAN_outside]

                  NAT on WLAN_outside:

                  interface WLAN_outside
                  Type Network 13.0.0.0/24
                  Translation 3.0.0.1

                  1 Reply Last reply Reply Quote 0
                  • P
                    podilarius
                    last edited by

                    So when you access something on 1.0.0.0/24 you want it to look like it is coming from 3.0.0.1 if you are accessing it from 13.0.0.1/24? Is the resource in line with the pfsense machine or a part of it? ( like in a DMZ or something ).

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

                      @podilarius:

                      So when you access something on 1.0.0.0/24 you want it to look like it is coming from 3.0.0.1 if you are accessing it from 13.0.0.1/24?

                      When I access something on 1.0.0.0/24 from 13.0.0.0/24 (3.0.0.1), I want it to be routed to 3.0.0.2.

                      (I believe that what is actually happening is quite in line with the general principles of routing, assuming that setting "gateway" means only default gateway. I just hoped it would be the gateway for everything.)

                      Is the resource in line with the pfsense machine or a part of it? ( like in a DMZ or something ).

                      I am not sure what you mean?

                      1 Reply Last reply Reply Quote 0
                      • P
                        podilarius
                        last edited by

                        Can you post a traceroute?

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

                          @podilarius:

                          Can you post a traceroute?

                          Hmm… That will be monday, when I'm back at the office. I can't connect to the client networks from here.

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

                            @podilarius:

                            Can you post a traceroute?

                            OK, I think now would be a good time to revisit the drawing and put the real IPs in there:

                            130.225.127.240/24    192.38.116.3/25    130.226.237.50/29
                            priv_outside                unpriv_outside      WLAN_outside
                            (defgw)    |                        |                |
                                        –--------------------------------
                                        |                pfsense                  |
                                        ----------------------------------
                                          |                  |                |
                            priv_inside            unpriv_inside    WLAN_inside
                            10.76.127.1/24    10.76.128.1/24  10.200.115.1/24

                            I NAT the users on priv_inside to 130.225.127.240
                            I NAT the users on unpriv_inside to 192.38.116.3
                            I NAT the users on WLAN_inside to 130.226.237.50

                            Also, these IP addresses are virtual IPs.

                            OK, now for the traceroutes. They're done on a host on 10.76.128.131. The unpriv_inside rule has a "permit unpriv_inside subnet to any" with a gateway of "192.38.116.1".

                            Traceroute to external site:

                            traceroute to www.funet.fi (81.90.77.32), 30 hops max, 60 byte packets
                            1  192.38.116.1  2.347 ms  2.474 ms  2.566 ms
                            2  130.225.204.6  1.619 ms  1.869 ms  1.959 ms
                            [..]
                            11  81.90.77.32  33.693 ms  33.801 ms  33.971 ms

                            Traceroute to local address:

                            traceroute to 130.225.127.1 (130.225.127.1), 30 hops max, 60 byte packets
                            1  10.76.128.2  0.299 ms  0.155 ms  0.225 ms
                            2  * * *
                            3  * * *
                            [..]
                            30  * * *

                            1 Reply Last reply Reply Quote 0
                            • P
                              phil.davis
                              last edited by

                              I think this would work. Add 6 rules, 2 on each inside LAN, to force traffic for the 2 other "local" outside subnets to the gateway you want.
                              Here are the 2 rules for WLAN_inside:
                              On WLAN_inside, pass all protocols, source 10.200.115.0/24, destination 130.225.127.0/24 and in Advanced Features, Gateway, select the WLAN_outside gateway address.
                              On WLAN_inside, pass all protocols, source 10.200.115.0/24, destination 192.38.116.0/25 and in Advanced Features, Gateway, select the WLAN_outside gateway address.

                              Do 2 rules for unpriv_inside and 2 for priv_inside to cover all the permutations.

                              Am I guessing that this configuration is good for testing. You can use a client in WLAN_inside to go out over the real internet and access a server that is available through unpriv_outside. That way you can test that the server really accessible from the internet and that the served web pages, applications etc actually work out in internet land.

                              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

                                @phil.davis:

                                I think this would work. Add 6 rules, 2 on each inside LAN, to force traffic for the 2 other "local" outside subnets to the gateway you want.
                                Here are the 2 rules for WLAN_inside:
                                On WLAN_inside, pass all protocols, source 10.200.115.0/24, destination 130.225.127.0/24 and in Advanced Features, Gateway, select the WLAN_outside gateway address.
                                On WLAN_inside, pass all protocols, source 10.200.115.0/24, destination 192.38.116.0/25 and in Advanced Features, Gateway, select the WLAN_outside gateway address.

                                Excellent idea - and it even works :)

                                Thanks.

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