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

    Communication between LANs does not work

    Scheduled Pinned Locked Moved Firewalling
    14 Posts 5 Posters 1.3k Views 7 Watching
    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.
    • obonesO Offline
      obones
      last edited by

      Well, that's what I thought too, here are the screencaps:

      LAN11
      3095d4ca-38bb-4c60-b7ed-cfc6094ef17f-image.png

      LAN18
      230c8f60-c9eb-4da1-bf72-d6d1e80d2d06-image.png

      I don't see what's wrong with the rules here.

      One thing though, is that both LAN11 and LAN18 are VLAN tagged interfaces (vmx0.11 and vmx0.18) on the same physical interface (vmx0) which is plugged on the trunk port of the switch.
      But I'm not sure this would have any interference as both LANs are capable of going to the outside world.

      1 Reply Last reply Reply Quote 0
      • KOMK Offline
        KOM
        last edited by

        Yes, those rules look good. I'm weak on VLANs so I can't really help you there but I wouldn't be surprised if it's some weird VLAN thing. Otherwise, there isn't much left other than local client firewalls.

        1 Reply Last reply Reply Quote 0
        • obonesO Offline
          obones
          last edited by

          Local client firewalls are off the picture, all machines on the same LAN can ping and connect to each other just fine.

          1 Reply Last reply Reply Quote 0
          • johnpozJ Offline
            johnpoz LAYER 8 Global Moderator
            last edited by johnpoz

            @obones said in Communication between LANs does not work:

            Local client firewalls are off the picture, all machines on the same LAN can ping and connect to each other just fine.

            You understand for example that windows will allow ping on same sub, but other sub block - this is almost always a local clients host firewall issue.

            Why would pfsense nat traffic between 2 local rfc1918 networks? Sniff on pfsense lan11 interface for example, then ping something on the lan11 from 18, do you see pfsense end the ping request out? But no answer?

            Can your 18 client for example ping the IP of pfsense lan11 interface?

            Other common mistakes are policy routing out some vpn or something on pfsense without allowing for intervlan traffic - this is not the case from your screenshots. Other common issue is device on vlans not even using pfsense as their gateway, etc.

            Other common issue is wrong mask setup either on client or pfsense.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 25.07 | Lab VMs 2.8, 25.07

            obonesO 1 Reply Last reply Reply Quote 0
            • obonesO Offline
              obones @johnpoz
              last edited by

              @johnpoz said in Communication between LANs does not work:

              You understand for example that windows will allow ping on same sub, but other sub block - this is almost always a local clients host firewall issue.

              The firewall are turned off for the time being so that I'm sure they do not interfere.

              Why would pfsense nat traffic between 2 local rfc1918 networks?

              Well, that would allow me to segregate traffic from one LAN to the other. Granted, this is not what I'm doing at the moment, but I'm starting with a simple "all in" rule set to see how it goes. Then, later on, I will restrict what is allowed based on actual needs.

              Sniff on pfsense lan11 interface for example, then ping something on the lan11 from 18, do you see pfsense end the ping request out? But no answer?

              Sniffing on LAN11, I see only those packets:

              17:31:42.009100 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 7, length 40
              17:31:46.800152 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 8, length 40
              17:31:51.800144 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 9, length 40
              17:31:56.800140 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 10, length 40
              

              If I sniff on LAN18, I get this:

              17:34:51.730084 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 14, length 40
              17:34:56.300474 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 15, length 40
              17:35:01.300554 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 16, length 40
              17:35:06.300584 IP 10.10.11.20 > 10.10.18.253: ICMP echo request, id 1, seq 17, length 40
              

              So it seems 18.253 does not send anything back...

              Can your 18 client for example ping the IP of pfsense lan11 interface?

              No, 10.10.18.253 cannot ping 10.10.11.254 (pfSense)
              However, 10.10.11.20 can ping 10.10.18.254 (pfSense)

              Other common issue is device on vlans not even using pfsense as their gateway, etc.

              They all are, if they would not they wouldn't be able to reach the Internet via pfSense.

              Other common issue is wrong mask setup either on client or pfsense.

              Just checked, it's /24 on all LAN interfaces inside pfSense.
              However, you hit the nail on the head, the mask was right on DHCP based clients, but for some idiotic reason, I set it to /16 on the static IPs that all happen to be in the LAN18 network.
              So obviously, those thought that 10.10.11.0/24 was within their reach.

              Sorry for wasting your time you with something so obvious.

              1 Reply Last reply Reply Quote 1
              • johnpozJ Offline
                johnpoz LAYER 8 Global Moderator
                last edited by johnpoz

                @obones said in Communication between LANs does not work:

                Sorry for wasting your time you with something so obvious.

                Not a waste of time - actually turned out to be a good run through of all the different common things.. Thanks for doing the sniff and showing pfsense was sending out the traffic.

                And then reporting back that problem with mask on client.

                This for sure could help the next guy!!

                As to nat and this response?

                Well, that would allow me to segregate traffic from one LAN to the other

                Huh??? not understand your thought process here.. They are segmented already, you have a firewall between them, etc. What would be the purpose of natting??

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 25.07 | Lab VMs 2.8, 25.07

                obonesO 1 Reply Last reply Reply Quote 0
                • KOMK Offline
                  KOM
                  last edited by

                  I think he's confusing NAT with general access.

                  1 Reply Last reply Reply Quote 0
                  • KOMK Offline
                    KOM @Guest
                    last edited by

                    @scottsmith101 Read the thread. His problem is already solved.

                    1 Reply Last reply Reply Quote 0
                    • obonesO Offline
                      obones @johnpoz
                      last edited by

                      @johnpoz said in Communication between LANs does not work:

                      @obones said in Communication between LANs does not work:

                      Sorry for wasting your time you with something so obvious.

                      Not a waste of time - actually turned out to be a good run through of all the different common things.. Thanks for doing the sniff and showing pfsense was sending out the traffic.

                      And then reporting back that problem with mask on client.

                      I wrote the post as I tested the various things, so it felt as a waste of time to discard all I already had typed.

                      Well, that would allow me to segregate traffic from one LAN to the other

                      Huh??? not understand your thought process here.. They are segmented already, you have a firewall between them, etc. What would be the purpose of natting??

                      Maybe I did not make myself clear enough, but I have two LAN interfaces (LAN11 and LAN18) and I will be adding more interfaces in the future, all with their own 10.10.x.0/24 subnet.
                      So, to me, this means there is some sort of address translation when a packet goes from LAN11 to LAN18 and back. Pretty much the same when a packet goes from LAN11 to the Internet and back.
                      As it turns out, this works out of the box, so there is nothing to configure on pfSense for this to happen.

                      In the end, what I want is that all LANs can go to LAN18 or the outside world, but cannot send packets to each other. But that, I will manage with some firewall rules.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD Offline
                        Derelict LAYER 8 Netgate
                        last edited by

                        So, to me, this means there is some sort of address translation when a packet goes from LAN11 to LAN18 and back. Pretty much the same when a packet goes from LAN11 to the Internet and back.

                        There is no translation there. Only routing.

                        When the LAN11 host sends traffic to a LAN18 host it sees the destination host is not on its local network so it consults its routing table and probably sends the traffic to its default gateway.

                        The router receives the traffic and consults its routing table and sees the LAN18 network matches, ARPs for the destination host if necessary and sends the traffic out that interface.

                        When the LAN18 host receives the traffic and has to reply, it sees the destination host is not on its local network so it consults its routing table and probably sends the traffic to its default gateway.

                        The router receives the traffic and consults its routing table and sees the LAN11 network matches, ARPs for the destination host if necessary and sends the traffic out that interface.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        1 Reply Last reply Reply Quote 0
                        • obonesO Offline
                          obones
                          last edited by

                          Of course !

                          I'm so used to the fact that "private" IPs need to be translated before going to the outside world that I forgot about basic routing.

                          Thanks for the reminder.

                          1 Reply Last reply Reply Quote 0
                          • M Offline
                            morghan0321 Banned
                            last edited by

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