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

    PfSense blocks traffic coming from SubnetA to SubnetB

    Scheduled Pinned Locked Moved Firewalling
    25 Posts 4 Posters 1.0k 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.
    • S
      skenigma @yquirion
      last edited by skenigma

      @yquirion
      if you are wanting Site B to access the internet through Site A, you will need a rule allowing 192.168.88.0/24 to ANY

      then you would need to make sure the routes ate site B are set to the default route to Site A

      Y 1 Reply Last reply Reply Quote 0
      • Y
        yquirion @skenigma
        last edited by

        @skenigma said in PfSense blocks traffic coming from SubnetA to SubnetB:

        @yquirion
        if you are wanting Site B to access the internet through Site A, you will need a rule allowing 192.168.88.0/24 to ANY

        then you would need to make sure the routes ate site B are set to the default route to Site A

        Hi @skenigma!

        Thanks again I appreciate your help.

        Before I saw your reply, I did create this rule on SITEB interface in the PfSense firewall:
        f0278eeb-ba64-40fb-8c7a-eb8e3613b6fe-image.png

        Now, from the firewall logs, I see this:
        b5e8d9c1-d553-4764-b9e0-06050c933694-image.png

        From the SITEB Mikrotik router, I have those route defined:
        87fbdf8d-2a37-486c-bf72-48e75e375694-image.png

        If the traffic goes through SiteA to access the Internet, do I need an outbound NAT for 192.168.88.0/24? I already created it, but even if the firewall logs tells the ICMP pass, it is now working.

        Thanks!
        Yanick

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

          @yquirion
          So probably you pointed the default route on B to A.

          If the traffic goes through SiteA to access the Internet, do I need an outbound NAT for 192.168.88.0/24?

          Exactly.

          I already created

          Did you also enable the Hybrid mode?

          If still no joy restart the firewall at A.

          Y 2 Replies Last reply Reply Quote 0
          • Y
            yquirion @viragomann
            last edited by

            Hi @viragomann,

            Thanks for your reply!

            Did you also enable the Hybrid mode?
            Well I will have to search what is Hybrid mode. I don't think this is enable.

            Here are an output of pfTop. The first one is when I ping 8.8.8.8 from a host at SiteA:
            c8b4ea4e-206a-40c7-bb37-f7c662da37ba-image.png

            Then this second one, is when I ping 8.8.8.8 from a host in siteB:
            a788bc61-7689-428a-8daf-f32252d1f5ec-image.png

            We can see on the sfirst on the connection goes to my WAN IP address, while the In and Out are the same on SiteB...

            Thanks!
            Yanick

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

              Hi @viragomann!

              Here is the answer to your previous question.

              Did you also enable the Hybrid mode?

              3afa9158-b4e7-415c-b2d6-b963e9d8f336-image.png

              I set it to Manual. Should I change it to the second one (Hybrid Outbound NAT rule generation.
              (Automatic Outbound NAT + rules below) or the first one (Automatic outbound NAT rule generation.
              (IPsec passthrough included))?

              Thanks,
              Yanick

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

                @yquirion
                So the packets from B go out on A WAN, but are not natted.

                So presumably there is something wrong with the outbound NAT. Can you show it, please?

                Y 1 Reply Last reply Reply Quote 0
                • Y
                  yquirion @viragomann
                  last edited by

                  Hi @viragomann,

                  Here is almost all of it:
                  30fb3115-a31c-4516-8829-74c66b972a91-image.png

                  I'm using some VLANs as well as a VPN connection, but do not bother with those.

                  Thanks
                  Yanick

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

                    @yquirion
                    Yeah, you're missing the rule for the B LAN.
                    Maybe you've chosen the wrong interface by mistake.

                    ad4be265-87bd-40bb-b4b7-a348bb03fa90-image.png

                    Y 1 Reply Last reply Reply Quote 0
                    • Y
                      yquirion @viragomann
                      last edited by

                      Hi @viragomann,

                      You're right. I change that to see what it will do, but it was WAN before. I will put it back, but unfortunately it won't solve the issue...

                      Here it is:

                      8e14e47e-c764-43a7-a0ed-9132a1c4e7cf-image.png

                      ping 8.8.8.8
                      
                      Pinging 8.8.8.8 with 32 bytes of data:
                      Request timed out.
                      Request timed out.
                      Request timed out.
                      Request timed out.
                      

                      Thanks
                      Yanick

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

                        @yquirion
                        Should work, since the packets are directed out on WAN.

                        As suggested before, reboot the box. Or at least flush the states.

                        Y 1 Reply Last reply Reply Quote 0
                        • Y
                          yquirion @viragomann
                          last edited by

                          Hi @viragomann,

                          I just rebooted and it doesn't solve the issue.

                          I really don't understand this one!

                          Thank you so much for your help!

                          Regards,
                          Yanick

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

                            @yquirion
                            Search the state table on A for the source IP.

                            Use packet capture to see, what's going on there.

                            Y 1 Reply Last reply Reply Quote 0
                            • Y
                              yquirion @viragomann
                              last edited by yquirion

                              Hi @viragomann,

                              Here are some tests I've done.

                              From SiteB, when I ping anything on the Internet, let's take one more time Google DNS 8.8.8.8, I will have this result for command tcpdump -nni igb2 icmp and host 8.8.8.8 I execute on my PFSense. Interface igb2 is the physical interface used by SITEB in pfsense:

                              22:27:29.720748 IP 192.168.88.10 > 8.8.8.8: ICMP echo request, id 7, seq 48849, length 40
                              22:27:34.632365 IP 192.168.88.10 > 8.8.8.8: ICMP echo request, id 7, seq 48850, length 40
                              22:27:39.639399 IP 192.168.88.10 > 8.8.8.8: ICMP echo request, id 7, seq 48851, length 40
                              22:27:44.644884 IP 192.168.88.10 > 8.8.8.8: ICMP echo request, id 7, seq 48852, length 40
                              

                              In the meantime, running tcpdump on WAN interface igb0, will not produce any output:

                              tcpdump -nni igb0 icmp and host 8.8.8.8
                              tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
                              listening on igb0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
                              

                              So it means the traffic from SiteB never redirected to the SiteA WAN's interface.

                              When doing that ping test from the SiteB's Mikrotik Router, the tcpdump running on interface igb2 on the pfsense router will show this:

                              22:33:36.921387 IP 10.0.0.4 > 8.8.8.8: ICMP echo request, id 1711, seq 0, length 36
                              22:33:37.924867 IP 10.0.0.4 > 8.8.8.8: ICMP echo request, id 1711, seq 1, length 36
                              22:33:38.928295 IP 10.0.0.4 > 8.8.8.8: ICMP echo request, id 1711, seq 2, length 36
                              22:33:39.931764 IP 10.0.0.4 > 8.8.8.8: ICMP echo request, id 1711, seq 3, length 36
                              22:33:40.934412 IP 10.0.0.4 > 8.8.8.8: ICMP echo request, id 1711, seq 4, length 36
                              

                              10.0.0.0/29 IPs from the router are normal because the P2P link between the two site is using this subnet.

                              When I ping 8.8.8.8 from SiteA computer (192.168.2.35), I will see that on the states page:
                              7762ff41-d0ae-4984-bd28-16ab7cb40b2f-image.png

                              But when doing this from SiteB, I don't see any "icmp" traffic going through.

                              Correction: After looking again, I can see the state of ICMP from SiteB:
                              13a56251-4d4d-4c13-9119-a5e477ef7372-image.png

                              But still "Request timed out".

                              Will continue investigating!

                              Thanks again for your help!

                              Yanick

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

                                @yquirion said in PfSense blocks traffic coming from SubnetA to SubnetB:

                                In the meantime, running tcpdump on WAN interface igb0, will not produce any output:

                                Did you change the firewall rules?
                                What rules to you have at A on SITEB interface?

                                @yquirion said in PfSense blocks traffic coming from SubnetA to SubnetB:

                                When I ping 8.8.8.8 from SiteA computer (192.168.2.35), I will see that on the states page:

                                Don't filter the interface, only the destination IP.
                                If the ping works I'd expect to see two states for this. One on the incoming interface (e.g. VLAN2) and one on the outgoing (WAN).

                                I assume, if you try to access the internet from B the WAN state is missing.

                                Y 2 Replies Last reply Reply Quote 0
                                • Y
                                  yquirion @viragomann
                                  last edited by

                                  Hi @viragomann,

                                  I've made an error. Here are the new result from a fresh test

                                  From SiteA - Interface VLAN2
                                  a486ca40-fa02-4077-86f0-a8db66da8133-image.png

                                  From SiteB - Interface SITEB
                                  55d953ad-ac96-4be0-a9b0-6c1daa95d3ff-image.png

                                  So we can see that nothing from Interface SITEB in going to the WAN Interface.

                                  Here are the rules on the WAN interface:
                                  e777752e-1215-4dd5-b35d-1894ac97b209-image.png

                                  And the rules on the SITEB Interface:
                                  35778608-0052-4d39-adb4-36a01105f4ad-image.png

                                  Here are the interface configuration:
                                  d5d76d22-9fc4-4d2a-91f8-64512e5338c2-image.png

                                  All those 3 interfaces are physical interfaces on my PfSense router.

                                  Outbound rules:
                                  d6a7a064-3f68-4f20-9eed-5b2e79b129f1-image.png

                                  I really don't understand why nothing is going to the WAN interface from SITEB interface.

                                  Thanks again!

                                  Yanick

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

                                    Hi @viragomann,

                                    I found something.

                                    Just after sending the reply, I did change this:

                                    476713cd-6760-452b-a8af-32f740c8092b-image.png

                                    Those two options were selected on the WAN interface.

                                    After that I see I could ping 8.8.8.8, but nothing else... Then if I stop the ping to 8.8.8.8, it won't restarts until I play again with those parameter (re-enable them).

                                    I reset all states; no luck, I rebooted the pfsense, same thing...

                                    At this moment I have a running ping from SITEB to 8.8.8.8. It works. I see the corresponding traffic on the igb0 (WAN) interface using tcpdump.

                                    Now, if I stop that ping, then wait for the states being cleared, then restart it, it is no longer working.

                                    Maybe I am running into a bug with pfsense, but all of this has no sense at all.

                                    Thanks
                                    Yanick

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

                                      @yquirion
                                      WTF! Just noticed, that you have "static port" checked in the outbound NAT rule.
                                      It wasn't checked before!

                                      2d51888f-98e1-49be-85c7-e48e7d96cfe1-image.png

                                      Why did you change things, you're not advised to change? You needed just to edit the rule and change the interface to WAN.
                                      This makes it hard to help you with your issues.

                                      Those two options were selected on the WAN interface.

                                      At A WAN this setting should be checked. At B not, mentioned in my very first post.
                                      At A VLAN2 it has to be unchecked. But this might have been the case before, otherwise you were not able to access A from B at all.

                                      Y 2 Replies Last reply Reply Quote 0
                                      • Y
                                        yquirion @viragomann
                                        last edited by yquirion

                                        Hi @viragomann,

                                        That is very odd. I never notice it. Sorry about that. However, I just look at it and since that post, it has been corrected.

                                        16c74789-4cf5-4a76-872c-ea038bb98432-image.png

                                        Regarding the 2 options, I don't have those on siteB because siteB is using a Mikrotik router. From the pfsense router on sitea, those options are disabled on all interface (was only enable on the WAN before).

                                        I'm not home for the weekend so I cannot make any other test on this.. But that os very strange that, while pfsense is applying the change of the Block private networks and loopback addresses, for a second the ping will work until I cancel it and the connection is being cleared of the state table...

                                        Thanks again, and I'm really sorry having made that mistake. I'm just testing stuff between replies!

                                        Yanick

                                        1 Reply Last reply Reply Quote 0
                                        • Y
                                          yquirion @viragomann
                                          last edited by

                                          Hi @viragomann,

                                          I found it!

                                          It was because of a miss configuration into my client OpenVPN connection.

                                          Here is a post that explain what was my problem:

                                          https://www.reddit.com/r/PFSENSE/comments/i125ig/default_route_now_set_to_vpn_client_instead_of/

                                          I was looking into this because of this:

                                          # route get 1.1.1.1
                                             route to: one.one.one.one
                                          destination: default
                                                 mask: 128.0.0.0
                                              gateway: 10.4.112.1
                                                  fib: 0
                                            interface: ovpnc1
                                                flags: <UP,GATEWAY,DONE,STATIC>
                                           recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
                                                 0         0         0         0      1500         1         0 
                                          

                                          That gateway of 10.4.112.1 was the gateway of my OpenVPN client connection. When I stop the service for that VPN connection, that was the result of the same command:

                                          /root: route get 8.8.8.8
                                             route to: dns.google
                                          destination: default
                                                 mask: default
                                              gateway: modemcable001.40-53-24.mc.videotron.ca
                                                  fib: 0
                                            interface: igb0
                                                flags: <UP,GATEWAY,DONE,STATIC>
                                           recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
                                                 0         0         0         0      1500         1         0 
                                          

                                          So I made search on why the OpenVPN client was adding that route to the routing table:

                                          0.0.0.0/1	<<VPN Interface Gateway IP>>
                                          

                                          And I found the post tjhat somve my issue.

                                          I would like to thank you very much as well as @skenigma for your time helping me solving the issue.

                                          Best Regards,
                                          Yanick

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