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

    Cannot NAT trough OPT1 interface on multiwan

    Scheduled Pinned Locked Moved 2.2 Snapshot Feedback and Problems - RETIRED
    49 Posts 18 Posters 16.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.
    • E
      eri--
      last edited by

      Actually seems that the one that have posted here have some issues in their configuration.

      They have set a generic policy routing rule on their lan which overrides the reply-to(NAT of their OPTx) tha would make things work.

      1 Reply Last reply Reply Quote 0
      • E
        eSpezi
        last edited by

        Hi Ermal,

        on my Dual WAN (WAN1 = Cable Router, WAN2 = PPPoE Modem) installation I successfully can ping each WAN IF.
        But I only can reach pfSenses WebGui or anything else on the current Default Gateway.
        By current I mean, that if the default Default Gateway (WAN1) is marked as down (unfortunately still way too often false alarm by apinger) then I am able to reach the WebGui via WAN2.

        I followed your suggestions, switched to manual outbound and added the propsed rule on top of everything, but that doesn't change anything.

        Has anybody had success with this workaround?
        Any other suggestions to make it work?

        Thanks,
        Harry

        Edit:
        Ermal in my case, you're right. I've policy routing on lan to a failover gateway group. That same scenario used to work fine with 2.15

        1 Reply Last reply Reply Quote 0
        • M
          mattbunce
          last edited by

          Excuse my ignorance, but I can't quite figure out if there is a resolution to this yet? I see from Gloom this should be working if you set manual NAT rules on the OPT1 interface (not sure exactly how to, or what this means?).

          Also, ermal suggests that the problem is that we're using a "generic policy routing rule" - and this is overriding the reply-to. Again, I'm not exactly sure what is meant by "generic policy routing rule" and if there's anything we can do to work around this?

          I have run Wireshark on the NAT target machine, and whilst I don't understand what I'm looking at, you can clearly see that the http request I am making to the NAT forwarded port (from an external network) is hitting the target machine, so it does seem to be the reply that is getting lost somewhere.

          My setup

          WAN = DHCP client
          OPT1 = PIA VPN

          I have set-up forwarding via Firewall > NAT and manually created a floating rule for TCP/UDP traffic on OPT1 coming in the my target IP.

          I have two LAN rules, the first is for target machine and sets the default gateway as OPT1. The second is for all devices and has the default gateway as the router default (which would be WAN).

          The floating rule seems to make no difference, I see the traffic within Wireshark whether or not the floating rule is enabled.

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

            It's not working, none of the workarounds are worth trying (short of for experimentation purposes if you want). This is the bug:
            https://redmine.pfsense.org/issues/3760

            1 Reply Last reply Reply Quote 0
            • M
              mattbunce
              last edited by

              Thanks cmb - That saves me spending any more time on this for now!

              1 Reply Last reply Reply Quote 0
              • E
                eri--
                last edited by

                Please try a next coming snapshot it should be fixed.

                1 Reply Last reply Reply Quote 0
                • E
                  eSpezi
                  last edited by

                  Hi Ermal,

                  thanks a lot for addressing the issue!
                  Is the fix already in the Wed Oct 15 14:37:51 CDT 2014 Build?

                  Cheers,
                  Harry

                  1 Reply Last reply Reply Quote 0
                  • E
                    eri--
                    last edited by

                    Yeah it should be on that build or newer.

                    1 Reply Last reply Reply Quote 0
                    • M
                      mattbunce
                      last edited by

                      Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

                      Is there anything else I should be looking at?

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

                        @mattbunce:

                        Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

                        Is there anything else I should be looking at?

                        Follow the bug report also: https://redmine.pfsense.org/issues/3760
                        On that, cmb indicates he has done some testing and it is still not fixed.

                        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
                        • M
                          mattbunce
                          last edited by

                          Cheers Phil

                          I have already commented on the bug report too, I just didn't want to get too 'chatty' on there, because it seems the folks on there have done some pretty advanced diagnostics and I didn't want to distract from the good work they were doing :)

                          1 Reply Last reply Reply Quote 0
                          • E
                            eri--
                            last edited by

                            Another round of fixes.
                            Next snapshot should have the missing piece for fixing this.

                            1 Reply Last reply Reply Quote 0
                            • M
                              mattbunce
                              last edited by

                              I still can't seem to get this working on the 17th October, 11:27:45 version.

                              Have you had a chance to try it out ermal? Perhaps I am not configuring the Nat and Rules pages correctly?

                              M

                              1 Reply Last reply Reply Quote 0
                              • M
                                mikeisfly
                                last edited by

                                This is not working for me and I'm using 2.2-BETA (amd64) built on Fri Oct 17 20:02:23 CDT 2014 FreeBSD 10.1-RC2

                                I have attached my LAN, NAT (Port Forwrd), Manual Outbound NAT Rules.

                                I have also captured packets on both my WAN, WAN2 and LAN interfaces. On my WAN2 and LAN I can see the Syn, and the Syn Ack packets however I don't see the ack packet. Also there are some retransmissions. When I capture packets on my WAN and filter for port 32400 the capture is blank which tells me that the packet is not being sent out the default gateway. I have attached the .pcap files here in the form of a .txt file if you would like to look at them in wireshark the extension just needs to be changed back to .pcap . Hope this helps

                                Thanks,

                                P.S. Not sure why I was trying to embed these images from my onedrive folder but it didn't seem to work so I had to add attachments.

                                ![LAN Rule.png](/public/imported_attachments/1/LAN Rule.png)
                                ![LAN Rule.png_thumb](/public/imported_attachments/1/LAN Rule.png_thumb)
                                ![Nat Port forward.png](/public/imported_attachments/1/Nat Port forward.png)
                                ![Nat Port forward.png_thumb](/public/imported_attachments/1/Nat Port forward.png_thumb)
                                ![outbound Nat.png](/public/imported_attachments/1/outbound Nat.png)
                                ![outbound Nat.png_thumb](/public/imported_attachments/1/outbound Nat.png_thumb)
                                [capture on LAN.txt](/public/imported_attachments/1/capture on LAN.txt)
                                [capture on wan2.txt](/public/imported_attachments/1/capture on wan2.txt)

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

                                  I think my problem is the same.
                                  If someone has some spare time to read: https://forum.pfsense.org/index.php?topic=82944.0

                                  I am running:

                                  Version 2.2-BETA (amd64)
                                  built on Fri Oct 17 20:02:23 CDT 2014
                                  FreeBSD 10.1-RC2

                                  I am available to test any solution and report back.

                                  Modem Draytek Vigor 130
                                  pfSense 2.4 Supermicro A1SRi-2558 - 8GB ECC RAM - Intel S3500 SSD 80GB - M350 Case
                                  Switch Cisco SG350-10
                                  AP Netgear R7000 (Stock FW)
                                  HTPC Intel NUC5i3RYH
                                  NAS Synology DS1515+
                                  NAS Synology DS213+

                                  1 Reply Last reply Reply Quote 0
                                  • M
                                    mikeisfly
                                    last edited by

                                    It's a known bug and the developers are working on it. Until then if this is a deal breaker you can try going back to 2.1.5 until the issue is resolved. That is what I'm doing.

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      stewgoin
                                      last edited by

                                      I'm seeing the same issues on the current snapshot – I've worked around the issue with some sourcerouting and having an upstream system on one of the WAN links handle NATting for now. That works (firewall rules forcing a gateway, then having manual NAT rules disabling NAT).

                                      It looked like using firewall rules to force the alternate gateway would make the multiWAN NAT rules start working correctly, but I didn't test that yet. It definitely adds another layer of config management to do this, so I eagerly await having this one squished :)

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

                                        Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          stewgoin
                                          last edited by

                                          @cmb:

                                          Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

                                          It's just a little portion of the old home network, and thankfully the changes are easy backed out to test any fixes :)

                                          Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

                                          1 Reply Last reply Reply Quote 0
                                          • M
                                            mattbunce
                                            last edited by

                                            @stewgoin:

                                            Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

                                            Agreed - I'm new to pfSense, but I'm very impressed with the speed of development and the "get it right in the GUI" approach. I've been using OpenWRT for a few years and there is a real tendency to push any advanced configuration to the command line, leaving much of your intricate configuration hidden within the GUI. I think the approach pfSense takes seems much more sensible - right down for the meaningful descriptions of all parameters in within the GUI

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