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

    Routing/natting between local subnets (SOLVED)

    2.0-RC Snapshot Feedback and Problems - RETIRED
    2
    13
    4.6k
    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.
    • C
      cyberfinn
      last edited by

      Hey

      We are running pfSense as our routers. Currently we have the following networks:

      WAN (Running public IP)
      OFFICE-LAN (10.10.0.1/24)
      TEST-LAN (10.1.0.1/16)

      In both OFFICE-LAN and TEST-LAN we have added a allow-all rule.

      Im using a computer at the OFFICE-LAN (10.10.0.20) and trying to connect to test-webserver on the TEST-LAN (10.1.0.100) using port 80. And everything works fine.
      Then I try to connect to another webserver on the TEST-LAN (10.1.0.20) and i could't connect.

      Im running NATTING i advance-mode and have not made any NATTING between OFFICE-LAN and TEST-LAN. Is that correct? And why can i connect to the server at 10.1.0.100 and not 10.1.0.20?

      I can't ping the ip of the pfSense TEST-LAN interface (10.1.0.1), when connected to the OFFICE-LAN, but I can ping 10.1.0.100.

      If I connect my computer to the TEST-LAN and assign af IP-like 10.1.0.10, I can connect to both servers and the pfSense IP: 10.1.0.1

      In the real worl I also have a interface names SERVERS (192.168.1.1/24), where I again can connect/ping to a server at IP 192.168.1.150, but not one at 192.168.1.20.

      Can anyone explain why?

      We are running RC3 - x64.

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

        Do you happen to have firewalls in these servers which ones doesnt answer or is there configuration which are told to listen only their subnet

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

          Yes i'm sure.

          And I can't ping the pfSenses ip on the other Subnet (10.1.0.1). But I can ping the server at 10.1.0.10, thats what i find wierd

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

            Another test-result (From OFFICE SUBNET, 10.10.0.1/24 to SERVERS SUBNET 192.168.1.1/24)

            Pinging from 10.10.0.20 on OFFICE SUBNET (Windows machine):
            Pinging 192.168.1.100 with 32 bytes of data:
            Reply from 192.168.1.100: bytes=32 time<1ms TTL=127
            Reply from 192.168.1.100: bytes=32 time<1ms TTL=127
            Reply from 192.168.1.100: bytes=32 time<1ms TTL=127
            Reply from 192.168.1.100: bytes=32 time<1ms TTL=127

            Pinging 192.168.1.20 with 32 bytes of data:
            Request timed out.
            Request timed out.
            Request timed out.
            Request timed out.

            Pinging from 192.168.1.1 on SERVERS SUBNET (The pfSense server):
            PING 192.168.1.100 (192.168.1.100) from 192.168.1.2: 56 data bytes
            64 bytes from 192.168.1.100: icmp_seq=0 ttl=128 time=0.443 ms
            64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=0.240 ms
            64 bytes from 192.168.1.100: icmp_seq=2 ttl=128 time=0.225 ms

            PING 192.168.1.20 (192.168.1.20) from 192.168.1.2: 56 data bytes
            64 bytes from 192.168.1.20: icmp_seq=0 ttl=128 time=0.144 ms
            64 bytes from 192.168.1.20: icmp_seq=1 ttl=128 time=0.094 ms
            64 bytes from 192.168.1.20: icmp_seq=2 ttl=128 time=0.090 ms

            Both 192.168.1.20 and 192.168.1.100 are running Windows 2003 with disabled firewall

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

              Another tes:

              Now i added this Advanced Outbound NAT entry:
              Interface: SERVERS
              Source 10.10.0.0/24
              (See the screenshot)

              And now I can ping both 192.168.1.20 and 192.168.1.100 from the Office-Subnet.

              Can I maybe be a bug in pfSense?

              Capture.PNG
              Capture.PNG_thumb

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

                Based on screenshot you're using nat, try to make rules only to outside world and let pfsense do the routing. Or you can simply create outbound nat above existing outside world nat with the check box "Do Not NAT"

                Hope you can read this

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

                  If I enabled "Do not NAT" for the rule I just added, then I can't ping the host 192.168.1.20 agian.

                  But I can ping 192.168.1.100

                  I think there is a bug. Can anybody confirm that?

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

                    Are on latest snapshot?

                    Sorry i'm running 32-bit version and i have no such environment that i could confirm that error

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

                      No. Running the RC3 downloaded as ISO and installed

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

                        Hey again

                        I have done some more testing:

                        Installed Wireshark on the server 192.168.1.20, then monitored the packets received.

                        Pinging from the OFFICE-LAN subnet, with a windows workstation (10.10.0.20)

                        When having natting enabled i got:
                        4252 2391.798936 192.168.1.1 192.168.1.20 ICMP Echo (ping) request
                        4253 2391.798956 192.168.1.20 192.168.1.1 ICMP Echo (ping) reply

                        When removed the natting rule I got:
                        1731 905.736205 10.10.0.20 192.168.1.20 ICMP Echo (ping) request
                        It looks like the host not responding the request. Could it be a bug in the NIC-driver or Windows 2003?

                        I also have some problems connecting the webinterface at some switches, attached to the SERVERS-SUBNET. When NAT is disabled. I think it has to be the same issue.

                        Has anybody experienced something link this?

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

                          Has that server (and switches) correct gateway? that may cause the problem

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

                            Thanks. It was almost the problem.

                            The switches does not have a gateway at the config interface, but I made static route for the subnet and then everything works.

                            For the Windows server,the problem was that it has two network attached, and the gateway (It was anothyer gateway than the pfSense box) was configured for the other network. So I also added a static route for the Subnet and everyting works.

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

                              Good to hear. nice it's solved

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