Navigation

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

    Using 2 public addresses to hide a single internal IP and get replied from the correct one

    NAT
    nat port forward
    3
    41
    198
    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.
    • johnpoz
      johnpoz LAYER 8 Global Moderator @AdrianX last edited by

      So your goal is to send all traffic hitting your wan IP on port XYZ to nginx load balancer at .211.. which then sends this traffic to .213..

      And you want 213 to return traffic direct back to pfsense. But pfsense to continue to send all traffic that hits its wan on to .211?

      So asymmetrical traffic flow..

      hmmmm - yeah going to need more coffee, if not beers... Off the top of my head, I don't really think such a setup is possible??

      Once your return traffic is allowed from .213, not sure new traffic would even go to 211, because pfsense would keep track of the conversation.. Hmmmmm

      A 1 Reply Last reply Reply Quote 0
      • A
        AdrianX @johnpoz last edited by AdrianX

        @johnpoz I see so the reason I just receive the first packet in the load balancer and the next ones directly on the backends, it's because the state is already there and then NAT 1:1 is applied for my source IP? But for new IPs they will have to send also first a the first packet to the LB, right?

        Could I then remove the option to keep the state and keep the 1:1 on the backend, and that should deliver everything to the load balancer even if I already queried it?

        johnpoz V 2 Replies Last reply Reply Quote 0
        • johnpoz
          johnpoz LAYER 8 Global Moderator @AdrianX last edited by

          @adrianx said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:

          Could I then remove the option to keep the state and keep the 1:1 on the backend

          Not sure sure such a thing is possible??

          Why can you not just return traffic back to nginx? And let it send traffic back to source IP 1.2.3.4? That is normally how it would be setup.. And that would be just simple port forwards on pfsense.

          A 1 Reply Last reply Reply Quote 0
          • V
            viragomann @AdrianX last edited by

            @adrianx
            So how does the server responed? Check with packet capture.
            It should use the VIP as source address in respond packets. I suspect that is not the case.

            A 1 Reply Last reply Reply Quote 0
            • A
              AdrianX @johnpoz last edited by

              @johnpoz The reason is because I'm doing this to distribute the load of incoming UDP requests for a UDP flood attack with spoofed IPs, so I will get around 50000 requests from different IPs per second. This saturates the NGINX leaving it without ports to bind when communicating with the backends. That's why I want to delegate the reply to the backend. Do you see my point?

              johnpoz 1 Reply Last reply Reply Quote 0
              • johnpoz
                johnpoz LAYER 8 Global Moderator @AdrianX last edited by

                wouldn't you have the same problem with pfsense..

                Confused how that would solve the problem?

                1 Reply Last reply Reply Quote 0
                • A
                  AdrianX @viragomann last edited by

                  @viragomann So with packet capture on the LAN, I see that the backend replies this:

                  15:32:57.557414 IP 192.168.1.213.7777 > Client.Public.IP.60428: UDP, length 15

                  So not using the Virtual IP. Is there a way to make it use the public IP?

                  V 1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @AdrianX last edited by

                    @adrianx
                    So DSR is not configured correctly on the servers.

                    From the linked site above:

                    the service VIP must be configured on a loopback interface on each backend and must not answer to ARP requests

                    johnpoz 1 Reply Last reply Reply Quote 1
                    • johnpoz
                      johnpoz LAYER 8 Global Moderator @viragomann last edited by johnpoz

                      ^ exactly.

                      But I still don't see how that really solves a state exhaustion issue.. No matter how many IP you send to behind pfsense.. Pfsense is natting to its public IP, which has a limit of how many states it can have.

                      The way to solve state exhaustion issue would be to filter the traffic that is "bad" before a state is created..

                      V 1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @johnpoz last edited by

                        I'd suppose, if the backend servers are configured correctly for DSR (responding using the VIP and not responding to ARP requests) the states will be fine.
                        However, I've never set up something like that.

                        johnpoz 1 Reply Last reply Reply Quote 0
                        • johnpoz
                          johnpoz LAYER 8 Global Moderator @viragomann last edited by johnpoz

                          so I will get around 50000 requests from different IPs per second

                          He still have his public IP with states.. Doesn't matter how many IPs he sends to behind.. While sure the local boxes would have less states.. His public IP would still have the states.. at 50k a second that is going to burn through states like crazy..

                          I don't really see how doing something like this could solve a state exhaustion issue to be honest..

                          Well lets not really call them states if they are UDP... But pf tracks them like they were.. You can set an option in pf for how long these are tracked..

                          But yeah I believe using the VIP on these end boxes for the IP of the load balancer is how such a setup is to be done. To solve the asymmetrical flow problem.. Since pfsense will only send traffic to what it thinks is 1 IP.. And the return traffic to pfsense will be coming from that same IP. As far as pfsense knows, since its source would be the vip address.

                          V 1 Reply Last reply Reply Quote 1
                          • V
                            viragomann @johnpoz last edited by

                            @johnpoz said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:

                            so I will get around 50000 requests from different IPs per second

                            Yes, you're absolutly right. It didn't realize, that he is really having such high load and may exhausting the state table.
                            However, with enough memory and cpu power, increasing the state table size and shortening the state timeouts it may be doable.

                            A 1 Reply Last reply Reply Quote 0
                            • A
                              AdrianX @viragomann last edited by

                              @viragomann @johnpoz

                              Regarding the "states" for the public IP, I can modify the associated rule with the port forwarding and choose "State type" as "none", and that would solve it, no?

                              johnpoz 1 Reply Last reply Reply Quote 0
                              • johnpoz
                                johnpoz LAYER 8 Global Moderator @AdrianX last edited by

                                Hmmm?

                                https://docs.netgate.com/pfsense/en/latest/firewall/configure.html
                                notsure.png

                                A 1 Reply Last reply Reply Quote 0
                                • A
                                  AdrianX @johnpoz last edited by

                                  @johnpoz Yes, that, plus also not keeping it in the outbound, no?. And how to configure UDP state expiration?

                                  johnpoz 1 Reply Last reply Reply Quote 0
                                  • johnpoz
                                    johnpoz LAYER 8 Global Moderator @AdrianX last edited by

                                    Well if you don't keep any states for the rule - it shoudn't matter.. But in the advanced section of the rule you can set the timeout option for states.. Also would need to be done on a outbound rule that matches.

                                    I am not 100% sure if that would also pertain to what pf does for udp tracking - I would assume so..

                                    A 2 Replies Last reply Reply Quote 0
                                    • A
                                      AdrianX @johnpoz last edited by AdrianX

                                      @johnpoz So the Floating rule for the Outbound, should be something like:

                                      569c93416622a9770e8c83b734be99ed.png

                                      Direction: In. State type: none

                                      So traffic going into the LAN from the internal load balancer, intended to get towards the wan to the outside world... no? Or I'm getting it wrong?

                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        AdrianX @johnpoz last edited by AdrianX

                                        @johnpoz Also, any idea why it still creates states even if I have the port forward rule set to "state type: none"? See:

                                        799fe4ad21cac54773707442a05d146c.png

                                        (DELETED TO AVOID SHOWING PUBLIC IP)

                                        johnpoz 1 Reply Last reply Reply Quote 0
                                        • johnpoz
                                          johnpoz LAYER 8 Global Moderator @AdrianX last edited by johnpoz

                                          I just assumed that none would do that - but with udp they are not actually states.. They are just tracking. So its possible those settings do not apply??

                                          https://www.openbsd.org/faq/pf/filter.html
                                          Keeping State for UDP
                                          One will sometimes hear it said that "one cannot create state with UDP, as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the options section of the pf.conf file.

                                          edit: Looks like your public IP is exposed in your state table. Are you ok with that? If not I would edit your image to obfuscate your public IP. If you need help with that just, just ask.

                                          Are those maybe old, from before you set the none in the rule?

                                          A 1 Reply Last reply Reply Quote 0
                                          • A
                                            AdrianX @johnpoz last edited by

                                            @johnpoz I just deleted the image.

                                            So I did a Reset states several times, and states are created no matter what. I don't understand how to avoid that.

                                            johnpoz 1 Reply Last reply Reply Quote 0
                                            • johnpoz
                                              johnpoz LAYER 8 Global Moderator @AdrianX last edited by

                                              Not sure if possible with udp.. And have never tried it with tcp either.. It is listed as an option, but not sure on the details of that option.

                                              We can call in maybe @Derelict he would have better understanding here of these options. I would think ;)

                                              1 Reply Last reply Reply Quote 0
                                              • First post
                                                Last post

                                              Products

                                              • Platform Overview
                                              • TNSR
                                              • pfSense
                                              • Appliances

                                              Services

                                              • Training
                                              • Professional Services

                                              Support

                                              • Subscription Plans
                                              • Contact Support
                                              • Product Lifecycle
                                              • Documentation

                                              News

                                              • Media Coverage
                                              • Press
                                              • Events

                                              Resources

                                              • Blog
                                              • FAQ
                                              • Find a Partner
                                              • Resource Library
                                              • Security Information

                                              Company

                                              • About Us
                                              • Careers
                                              • Partners
                                              • Contact Us
                                              • Legal
                                              Our Mission

                                              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                              Subscribe to our Newsletter

                                              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                              © 2021 Rubicon Communications, LLC | Privacy Policy