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

    Multi Wan to Lan Port Forwarding Problem (SOLVED)

    Scheduled Pinned Locked Moved NAT
    4 Posts 2 Posters 6.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.
    • J
      johann.fenech
      last edited by

      Here is the scenario :-

      PfSense 2 : 2.0.1-RELEASE (i386)  built on Mon Dec 12 17:53:52 EST 2011 FreeBSD 8.1-RELEASE-p6

      The system is running as a guest to Vmware Esxi V 5.0 (100Gb hdd, 2Gb Ram, 2 cpu cores, with 4 nics). 1 Lan, 3 Wan.

      Lan is 10.201.100.10 / 22
      Wan-1 is PPPoE (Fixed IP)

      Wan-2 is DHCP (Modem is Adsl with fixed ip (same ISP as above),  Internal modem ip is 192.168.1.254, PfSense Ip is 192.168.1.66). Modem has port forwarding to 192.168.1.66 enabled for 80, 443, 25, 110, 455, 995.   192.168.1.66 is tied to the mac of Wan-2 in the DHCP server of the modem.

      Wan-3 is Cable modem Fixed IP (different ISP)

      Internet access from inside worked like a charm, took only a few minutes to configure, and am very very happy with the features and the interface.  PPTP Vpn server was next. Running in under 2 minutes … Very impressive.

      But After that I hit a snag.

      My port forwarding requirements are as follows :-

      Port 21, 80 from ANY interface to 10.201.101.10 (Web / Ftp)
      Port 25, 110, 455, 995  from ANY interface to 10.201.101.5 (Zimbra Mail Server)

      From Firewall –> Nat--> Port Forwarding

      I entered the following rules :-

      If Proto Src. addr       Src. ports Dest. Addr Dest. ports NAT IP NAT Ports
      Wan_1 TCP * * Wan_1 address 443       10.201.101.5             443
      Wan_1 TCP * * Wan_1 address 80         10.201.100.10            80

      And so on and so forth. So far so good, if I go on the internet (from outside) and type h_ttp://my.wan1.ip, I get my http server page, while h_ttps:// my.wan1.ip it takes me to my Zimbra login page. The problems begin when I add the same rules to another Wan interface.

      If Proto Src. addr       Src. ports Dest. Addr Dest. ports NAT IP NAT Ports
      Wan_1 TCP * * Wan_1 address 443       10.201.101.5             443
      Wan_1 TCP * * Wan_1 address 80         10.201.100.10            80
      Wan_2 TCP * * Wan_2 address 443       10.201.101.5             443
      Wan_2 TCP * * Wan_2 address 80         10.201.100.10            80

      This time the first two rules are still obeyed, but if I go outside and type http or https   ://my.wan_2.ip, I get an error loading page or a timeout.

      Same thing with Wan_3 (the cable modem).

      To debug further, I plugged in a laptop directly to the “lan” side of the Wan 2 modem, gave it an IP of 192.168.1.50. Now if I type h_ttp://192.168.1.66 (the wan I.P. Address of Wan 2 on pf sense) I get the web page, and also if I do https://192.168.1.66 I get the zimbra login page, which seems to point to the modem not natting properly…. However, if I set the laptop to 192.168.1.66, remove Wan-2 from the switch, and run a web server on the laptop I can access it from h_ttp://Wan2.ip !!! Which got me totally confused.

      Same exact thing happens with the cable modem, if I plug it in to the laptop, and run a web server on the laptop, I can access it from outside, but I cannot get it to work with pf sense’s forward rules.

      I am sorry about writing so long, but could not summarise any further. Thank you for reading and  would really appreciate any help

      Johann

      1 Reply Last reply Reply Quote 0
      • J
        johann.fenech
        last edited by

        I  managed to sort it  out ;D ;D ;D

        The issue, for anyone else who encounters this was that I was setting the "Filter Rule to "PASS", while apparently is should be set to "create new associated filter rule"

        This software really rocks Guys … a very BIG WELL DONE

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

          Ah, yeah in that particular case, you need the associated firewall rule because it has reply-to set to route the traffic back out the correct path. Just "pass" on the rdr doesn't have proper return routing except on the interface where the default gateway resides.

          1 Reply Last reply Reply Quote 0
          • J
            johann.fenech
            last edited by

            @cmb:

            Ah, yeah in that particular case, you need the associated firewall rule because it has reply-to set to route the traffic back out the correct path. Just "pass" on the rdr doesn't have proper return routing except on the interface where the default gateway resides.

            Thank you very much for your reply and clarification, was wondering in fact if the route back was the issue, now I know. Am really impressed with the features and overall ease of use of the product. Keep up the good work everyone.

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