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

    Inter-VLAN Communication and WAN Connectivity Issues After Switching from PPPoE to DHCP/Static

    Scheduled Pinned Locked Moved General pfSense Questions
    19 Posts 3 Posters 702 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.
    • F
      fxpro
      last edited by

      Hi, I'm encountering significant issues with my pfSense setup after switching from a PPPoE WAN connection to a DHCP/Static WAN configuration. Here's a detailed breakdown of the problem and setup:

      Setup Overview:
      GPON Modem Configuration:
      The GPON is in bridge mode and provides a public IP address directly to the pfSense WAN interface.
      There is only one device connected to the GPON modem: the pfSense's ETH0 port, configured as the WAN interface.
      The ISP initially provided a dynamic public IP address but has since assigned me a static public IP (e.g., 144.x.x.x with gateway 144.6.188.1 and subnet mask /16).

      pfSense Configuration:
      WAN Interface: Configured with both DHCP and Static WAN settings (there are actually 2 WAN settings):

      • The primary WAN interface (DHCP) receives a public IP address, subnet mask, and ISP gateway but does not provide public internet access.
      • To establish internet connectivity, I have to manually add a second Static WAN interface with the same public IP and gateway configuration.
        Outbound NAT Mode: Set to Hybrid.
        VLANs: There are 20+ VLANs (e.g., VLAN2: 172.x.x.0/24, VLAN3: 10.x.x.0/24, etc.) configured with specific IP ranges. Each VLAN is served by pfSense's DHCP server.
        VPN: Configured to activate only when the WAN gateway (WANGW) is online.
        There is a kill switch that blocks traffic for VPN-connected VLANs if the VPN fails.

      Firewall Rules:
      All VLANs previously worked perfectly with inter-VLAN communication allowed via rules.
      Each VLAN has explicit "allow all" bidirectional rules for testing inter-VLAN traffic during troubleshooting.
      Gateway Configuration:

      There are three gateways:
      WANGW (Default): Public gateway (provided via DHCP or manually as Static).
      WAN_DHCP: Automatically obtained from GPON.
      VPN_INTERFACE_VPNV4: VPN gateway.

      The Problems:
      WAN Connectivity Issues:
      When the WAN interface is configured as DHCP, pfSense receives the correct public IP (144.x.x.x), gateway (144.6.188.1), and subnet mask (/16), but there is no public internet access.
      To establish internet access however, I have to manually add a Static WAN interface using the same IP, gateway, and subnet mask details.
      *** However, after rebooting pfSense, WAN connectivity becomes unreliable. Sometimes it works automatically; other times, I must delete and re-add the static WAN configuration to restore connectivity.

      Inter-VLAN Communication:
      Previously, inter-VLAN traffic worked flawlessly with my PPPoE WAN configuration.
      After switching to DHCP/Static WAN, inter-VLAN communication has stopped working.
      Example: Devices in VLAN2 (172.x.x.0/24) cannot ping devices in VLAN3 (10.x.x.0/24), even with "allow all" rules for both VLANs.
      I have also added configs in the NAT Outbound section to 'No NAT' between VLANs, this has no effect at all, the same problem exists, no inter-VLAN comms.
      Using Packet Capture, I see ICMP packets leaving VLAN2 client but not reaching VLAN3 client. The destination VLAN shows no trace of the packets. I can see other packets that are reaching the client target from the WAN interface itself, but I cannot see any packets originating from VLAN2 (for example)

      Potential Double NAT Issue:
      Although the GPON modem is in bridge mode and provides a public IP to pfSense, could there still be a hidden NAT issue causing these symptoms?

      Diagnostics Attempted:
      I can Verify that the GPON is in bridge mode and provides a public IP address directly to pfSense.

      Checked Status > Interfaces:
      WAN interface shows no errors or collisions when configured as DHCP or Static.
      Received public IP, subnet mask, and gateway match ISP's configuration.
      Disabled IPv6 on the WAN interface to rule out conflicts.
      Added and removed Static Routes, but no improvement.

      Tested NAT rules:
      Set Hybrid Outbound NAT and added "No NAT" rules for inter-VLAN traffic.
      Verified that VPN only activates when the WAN gateway is online. This works as expected when WAN connectivity is functional.

      Ran ping and traceroute:
      Inter-VLAN traffic fails despite "allow all" rules.
      Traffic to the public internet succeeds only when the WAN is set to Static.

      Rebooted pfSense multiple times:
      WAN Static gateway connectivity is inconsistent after reboots.
      Removing the DHCP/Static WAN configuration restores inter-VLAN traffic but disconnects internet access.

      Questions:

      • Why does the WAN DHCP configuration fail to provide internet access despite obtaining correct public IP, gateway, and subnet mask details?
      • Why does adding a Static WAN interface resolve internet access but block inter-VLAN communication?
      • Could there be a hidden double NAT issue despite the GPON being in bridge mode?
      • How can I ensure WAN connectivity and inter-VLAN communication are both stable and functional, even after reboots?

      I've now been working on this for 3 days straight and without any joy and plenty of stress... I'm getting desperate now.

      Any assistance or guidance would be greatly appreciated. Please let me know if additional details or logs are required.

      Thank you!

      stephenw10S 1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator @fxpro
        last edited by

        @fxpro said in Inter-VLAN Communication and WAN Connectivity Issues After Switching from PPPoE to DHCP/Static:

        Why does the WAN DHCP configuration fail to provide internet access despite obtaining correct public IP, gateway, and subnet mask details?
        Why does adding a Static WAN interface resolve internet access but block inter-VLAN communication?

        I would forget everything else until you've answered those questions because that's completely unexpected and likely caused by whatever issue is causing all the problems.

        So it absolutely should work with WAN set to DHCP. What exactly fails when you only have that? Can pfSense itself still connect out? By IP directly?

        Having two WAN interfaces in the same subnet wouldn't normally be allowed but can be if one is DHCP so not defined in the config. But it's still a conflict which is probably why you see connection issues after reboot. You can only have one WAN interface there.

        Steve

        F 1 Reply Last reply Reply Quote 0
        • F
          fxpro @stephenw10
          last edited by fxpro

          @stephenw10 thanks for the reply I appreciate it.

          When I set the WAN to DHCP, the connection shows as online, but there is no internet access. I added two DNS IP addresses in System > General Setup and linked them to the WAN DHCP interface, but still no internet connectivity.

          It seems like the issue could be one of the following:

          • The GPON/ONT (Dasan H64OGR) is not forwarding all necessary data to the WAN DHCP interface; OR
          • There’s an issue with my version of pfSense; OR
          • I’ve made a configuration mistake somewhere, although I’m not sure where.

          Currently, I only have one active interface, as expected. The second gateway is listed as "pending" in the dashboard and isn’t active. I suspect this might be due to a manually configured static gateway. While this setup allows internet connectivity, it blocks inter-VLAN communication. If I remove the static gateway, inter-VLAN communication works fine, but internet connectivity is lost, indicating a conflict.

          When pfSense attempts to connect to an IP address like the ISP’s DNS or 8.8.8.8, the results are inconsistent, it sometimes connects but not always. This leads me to think there might be a DNS configuration issue. However, since the WAN is set to DHCP, this information should already be handled automatically.

          Could this be a misconfiguration on my part?

          Any guidance would be greatly appreciated.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Can you ping 8.8.8.8 directly from pfSense? Either in Diag > Ping or from the CLI. That doesn't require DNS and should be working unless there is no default route.

            Check Status > Interfaces. The WAN should show the gateway and any DNS servers it's receiving from the DHCP server.

            Check Diag > Routes. There should be a default gateway and it should be the WAN_DHCP gateway received from the server.

            Check Firewall > NAT > Outbound. It should be set to automatic or hybrid and you should see auto rules on the WAN for each of your internal subnets.
            If you followed some VPN guide that said to set that to manual that's almost certainly what has broken it.

            F 2 Replies Last reply Reply Quote 0
            • F
              fxpro @stephenw10
              last edited by fxpro

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • F
                fxpro @stephenw10
                last edited by fxpro

                @stephenw10 Okay so here is what I did to respond to all of your points:

                1. I removed the Static gateway setting and left the DHCP to the original state.

                2. I added the static gateway route in System > General Setup for 202.142.142.142 and linked it to the WAN_DHCP

                3. I rebooted the pfSense and when it came backup I could ping:

                • Successfully pinged VLAN3 devices from VLAN2 device.
                • Could NOT ping 8.8.8.8 from the pfSense WAN interface (done through Diagnostics > Ping)
                --- 8.8.8.8 ping statistics ---
                3 packets transmitted, 0 packets received, 100.0% packet loss
                
                • Could NOT ping google.com the pfSense WAN interface (done through Diagnostics > Ping)
                --- google.com ping statistics ---
                3 packets transmitted, 0 packets received, 100.0% packet loss
                
                1. Then I removed the DNS route 202.142.142.142 from the System > General Setup and set the link to 'none' and applied settings.
                F 1 Reply Last reply Reply Quote 0
                • F
                  fxpro @fxpro
                  last edited by

                  1. In relation to the WAN interface on 'Check Status' on the Status > Dashboard, it shows it as 'Online'.

                  2. From the Status > Interfaces, The following is output for the WAN interface:

                  WAN Interface (wan, igc0)
                  Status = up 
                  DHCP = up
                  MAC Address = 60:xx:xx:xx:xx:xx (address not shown here for security reasons)
                  IPv4 Address = 144.x.x.x (address not shown here for security reasons)
                  Subnet mask IPv4 = 255.255.252.0 
                  Gateway IPv4 = 144.6.188.1 
                  IPv6 Link Local = fe80::xxxx:xxxx:xxxx:xxxx%igc0 (address not shown here for security reasons)
                  MTU = 1500 
                  Media = 1000baseT <full-duplex> 
                  In/out packets = 2460/2711 (372 KiB/236 KiB) 
                  In/out packets (pass) = 2460/2711 (372 KiB/236 KiB) 
                  In/out packets (block) = 86/0 (4 KiB/0 B) 
                  In/out errors = 0/0 
                  Collisions = 0 
                  Interrupts = 5314 (7/s)
                  

                  Note: As you can see, the details for the connection are there, even the gateway itself is listed.

                  1. The VPN status is down (correctly) because the WAN isn't properly translating DNS at this point in time.

                  2. In Diagnostics > Routes there is the following routes:

                  IPv4 Routes
                      127.0.0.1	link#6	UH	2	16384	lo0	
                      144.6.188.0/22	link#1	U	42	1500	igc0	
                      144.x.x.x	link#6	UHS	43	16384	lo0
                  

                  All other routes pertain to the VLANs configured.
                  Note Public IP address not shown here for security reasons

                  1. In the Mappings for Firewall > NAT > Outbound I have the following:
                  WAN >>> VLAN2 Source >> Source Port * >> VLAN3 Destination >> Destination Port * >> NAT Address (NO NAT) >> NAT Port *
                  WAN >>> VLAN3 Source >> Source Port * >> VLAN2 Destination >> Destination Port * >> NAT Address (NO NAT) >> NAT Port *
                  WAN >>> * Source >> Source Port * >> * Destination >> Destination Port * >> WAN Address >> NAT Port *
                  WAN >>> * Source >> Source Port * >> * Destination >> Destination Port 500 (ISAKMP) >> WAN Address >> NAT Port *
                  

                  The rest are all for my internal subnets, not needed to be listed here.

                  1. In the Automatic Rules for Firewall > NAT > Outbound there are NO automatically generated rules and the Outbound NAT Mode is set to Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below)

                  2. In relation to the guides followed, Primarily I've followed a simple guide made by Lawrence Systems on youtube.
                    However I have configured the rest of the pfSense myself

                  3. I then setup the Static WAN again by adding WAN interface in Interfaces > WAN (igc0)
                    using IPv4 Configuration Type > Static IPv4.
                    Then the internet connection came back up, and I was able to ping google.com AND 8.8.8.8.
                    I was NOT able to ping the devices in VLAN3 from VLAN2 which I was able to do prior to adding the WAN Static interface.

                  4. However after around 20 minutes uptime... the connection drops for no apparent reason.
                    I checked the GPON/ONT and it is still online and there is no connection issue with the ISP.
                    I then removed both DHCP connection and the static connection, and re-added them,by first adding the WAN connection as DHCP like one would normally do.

                  5. Then I added the Gateway setting via System > Routing > Gateways, through adding a Static IPv4 Gateway, then connectivity to the public internet was returned but then the inter-VLAN communications no longer functioned.

                  6. I also had an idea to try another config after removing the Statically set Gateway, and just leaving the DHCP WAN, and I entered System > General Setup, in the DNS Server Settings, I modified the two DNS name servers of the ISP to link to WAN, rather than NONE which was previously set.

                  When that happened I Also had connectivity to the internet AND Inter-VLAN comms worked, however when I did a dnsleaktest I found that the VPN was no longer the only DNS servers that was used but also now the ISP DNS which is not good. I then modified back to link the ISP DNS IP Addresses to NONE and whilst the pfsense retained connectivity to the internet, I lost again inter-VLAN connectivity and within about 20 minutes, connectivity to the internet was lost.

                  Therefore as you can see, this is quite a perplexing problem and I do not understand why this is happening.

                  Previous to this current ISP that I am using, they used a PPPoE connection which worked flawlessly in the entire pfSense configuration, its never skipped a beat not once, pure solid setup. Yet I just change ONLY the WAN interface settings from PPPoE to DHCP with the new ISP and voila, I have no internet and I need to add the static WAN to get the internet up, but then I lose inter-VLAN communications.

                  Literally the only thing that creates this problem is by using the DHCP in the WAN connection together with the additional WAN Static IP setup. Somewhere somehow there is a conflict, I just don't know how to resolve it.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Ok the fact you have no auto rules added means pfSense doesn't see it as a WAN, no gateway on it, but it should have because you see it in the dhcp status.

                    You should not need to add a gateway at all and doing so is probably causing a problem.

                    You probably lose connectivity between the VLANs when the gateway comes up because the firewall rules on those VLANs have policy routes, gateways defined? Presumably the WAN_GW?
                    If so need bypass rules without a gateway defined to allow direct routing.

                    @fxpro said in Inter-VLAN Communication and WAN Connectivity Issues After Switching from PPPoE to DHCP/Static:

                    WAN >>> VLAN2 Source >> Source Port * >> VLAN3 Destination >> Destination Port * >> NAT Address (NO NAT) >> NAT Port *
                    WAN >>> VLAN3 Source >> Source Port * >> VLAN2 Destination >> Destination Port * >> NAT Address (NO NAT) >> NAT Port *

                    Those OBN rules do nothing. Traffic leaving the WAN can never have those VLAN subnets as a destination. They can be removed/disabled.

                    F 1 Reply Last reply Reply Quote 0
                    • F
                      fxpro @stephenw10
                      last edited by

                      @stephenw10 right... so I've removed those rules you've suggested, nothing changes as a result.

                      Additionally if I don't add the gateway, there is no connectivity !
                      This is what is really puzzling me because without the additional gateway, it won't get public internet access.

                      I also tried removing the gateway, now it only has DHCP WAN, but I had to First add the link to the WAN in DNS Server Settings... I then get DNS leak... so I set it then to NONE and now the wan port can see public internet, but I still have the inter-VLAN connectivity issue.

                      Please note that previous to this, whilst on my previous ISP, I NEVER had this problem at all, it was working solid as a rock with no dns leaks or any connectivity problems. The only time this problem has arisen is when I changed the WAN to DHCP.

                      With regards to the policy routes for each VLAN, yes they are defined to go through the VPN connection, they don't go through the WAN_GW. I've never had any problems with them in the past either.

                      The setup is typically the following:

                      WAN Interface >> vlanaddress >> * Source >> * Source Port >> * Destination >> * Port >> VPN_INTERFACE NAT Address >> * Port

                      This is a configuration that is widely used by many online, however I am wondering if this config is incorrect?

                      In any case, I still cannot resolve the connectivity issues and instability of the public internet connectivity... none are resolved permanently. Any other ideas?

                      stephenw10S 1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator @fxpro
                        last edited by

                        @fxpro said in Inter-VLAN Communication and WAN Connectivity Issues After Switching from PPPoE to DHCP/Static:

                        WAN Interface >> vlanaddress >> * Source >> * Source Port >> * Destination >> * Port >> VPN_INTERFACE NAT Address >> * Port

                        Um, that doesn't make any sense. Can you give a screenshot of the rules on one of the VLANs.

                        Basically if the only passrule you have defined on there has a gateway set then all traffic will be forced via that gateway unless the gateway is down. Hence you would normally have bypass rules for locally routed traffic.

                        @fxpro said in Inter-VLAN Communication and WAN Connectivity Issues After Switching from PPPoE to DHCP/Static:

                        Please note that previous to this, whilst on my previous ISP, I NEVER had this problem at all, it was working solid as a rock with no dns leaks or any connectivity problems.

                        I assume you didn't have the additional gateway added with the previous ISP though? The pppoe session, like dhcp, should dynamically add a gateway when it comes up.

                        The only real issue I have seen here is there you have no default route in some situations. So anything not specifically policy routed will fail. With just the dhcp WAN configured it should set the dynamic gateway to be the default route when it comes up. Are you still not seeing that? Are there any errors shown in the dhcp log when it connects?

                        F 1 Reply Last reply Reply Quote 0
                        • F
                          fxpro @stephenw10
                          last edited by fxpro

                          @stephenw10 thanks for the reply.

                          I think I've found out the reason for the issue, and so this 'could' be either the way I've configured the router or there must be some kind of bug in the pfSense firmware due to the routing. I shall explain here:

                          1. On the previous ISP I was using a PPPoE connection/configuration on the WAN. This worked perfectly and I never had any issues whatsoever. However there is one single configuration that is different on this connection compared to the DHCP connection/configuration.
                            Note: The config was as follows:
                            SYSTEM > ROUTING > GATEWAYS
                            Gateways:
                            PPPoE (Default IPv4) Interface WAN Gateway ###########
                            *** Default Gateway > Default gateway IPv4 was set to 'NONE'

                          2. On the current ISP that requires the DHCP connection/configuration on the WAN, this is where the problems started and after 2 weeks of trying every single combination I could imagine, even using GPT to assist, I finally found a half solution, but it only solves 1 of 2 problems.

                          The configuration that now allows me to correctly connect to the public internet, and even after reboot it will return to normal public internet connectivity is as follows:
                          SYSTEM > ROUTING > GATEWAYS
                          Gateways:
                          WAN_DHCP (Default IPv4) Interface WAN Gateway ###########
                          *** Default Gateway > Default gateway IPv4 was set to 'WAN_DHCP'

                          1. As you can see the difference, on the PPPoE connection the default gateway was selected to NONE and you might say that was already incorrect, I disagree because my Public Internet Access was flawless as well as the inter-VLAN connectivity through the PPPoE connection. Yet now when the default gateway is set to WAN_DHCP I get the public internet access but I lose inter-VLAN connectivity. It has nothing to do with firewall rules either, as you will see below.

                          2. This problem strongly suggests that the pfSense’s routing (and possibly NAT) behaviour is “pulling” my LOCALLY sourced packets toward the WAN rather than routing them internally. In other words, when the WAN interface is active and its default gateway is set, pfSense ends up sending (or “reply‐to’ing”) even local traffic out via the WAN instead of handling it directly between its local interfaces.

                          3. In order to test this, I disabled the WAN_DHCP from SYSTEM > ROUTING > GATEWAYS and the VPN was still connected at this point in time, it didn't drop, which is weird. I could ping google.com. I could not ping 10.3.3.2 in VLAN2. I then rebooted the pfSense.

                          4. On boot up, I could ping 10.3.3.2 in VLAN2 but I had no access to the public Internet, I could not ping google.com, obviously because I had disabled the WAN_DHCP. I then enabled the WAN_DHCP, and that didn't result in connecting to the public internet, but I could still ping 10.3.3.2. I then rebooted the pfSense.

                          5. On boot up, I could no longer ping 10.3.3.2 in VLAN2, but I had public internet access !

                          You can try this yourself, I've repeated this process more than 6 times and every single time it did the same thing happened, the same exact results occurred.

                          Therefore either there is some crazy mis-configuration on my part, or there is a major bug in the pfSense firmware that has something to do with DHCP connectivity and NAT routing when the DHCP is enabled, as described above.

                          As far as answering your question about the additional gateway not being added with my previous ISP... yeah I never added it, it was already given by the PPPoE connection. The strange thing is, the DHCP connection obtains the same information, its not like there is something missing. This is what makes it so strange and makes me think its a bug in the firmware.
                          By the way, I'm running the latest firmware 2.7.2-RELEASE (amd64) built on Tue Mar 5 6:53:00 AEDT 2024 FreeBSD 14.0-CURRENT

                          I'd love to be wrong, I hope I've been a dill and configured something incorrectly, but as far as I can see, this is a bug with the pfSense regarding the routing. Somehow it appears that the presence of the default route installed by the WAN’s DHCP lease is “stealing” or overriding the local (directly connected) routing for inter‑VLAN traffic. In other words, when WAN_DHCP is enabled, even though the local routes are correctly present, pfSense’s routing (or its state reply‑to logic) is forcing return traffic out via the WAN interface rather than through the directly connected interfaces.

                          Any ideas on how to resolve this problem?

                          At this point, I'm completely out of ideas which means I'll be tossing the pfSense if I can't resolve this problem. I'm unable to do any work on this network at all. It shouldn't be this hard.
                          Please help.

                          Heres the image you wanted... although it doesn't prove much because I haven' proven it works when the WAN_DHCP isn't connectetd, you can see I've opened it right up and yet still the packets aren't routed where they should be:

                          vlan3_image.png

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            There is no rule there allowing a host on VLAN3 to ping a host on VLAN2. Or rather the only rule that would allow it is disabled.

                            How exactly are you testing? What IP are you trying to ping from?

                            F 1 Reply Last reply Reply Quote 0
                            • F
                              fxpro @stephenw10
                              last edited by

                              @stephenw10 how is there no rule to ping to VLAN3?

                              look here:
                              4800998d-76fd-43ed-a4bf-dc03c275a479-image.png
                              How is this not a rule?

                              And if it was incorrect, how come it works when I remove the WAN_DHCP? Doesn't make sense.

                              In relation to your question about the rules and where I'm pinging from...
                              I'm pinging from (VLAN2) 172.16.2.150 to (VLAN3) 10.3.3.2
                              Thats exactly what the rule above does.
                              I can even make it specific using the actual IP Addresses, it makes no difference, the same result occurs.

                              Additionally, I have made a rule also where ALLOW ALL/ANY and I still get the same result, I cannot ping whilst WAN_DHCP is enabled. The moment I disable the WAN_DHCP and reboot the pfSense, when its booted up again, I can ping between the VLANs as correctly specified in the image.

                              The rule you see disabled is on purpose, but even with it on doesn't change anything. That rule is for VLAN3 to ping VLAN2 which is not what I'm doing as mentioned above. Either way, with it enabled, changes nothing because I ping from VLAN2 172.16.2.150 to VLAN3 10.3.3.2.

                              I don't know what else to do, I'm completely at a stand still. Please help.

                              Any idea why its doing this?
                              do you want to see more config?
                              I can also show you logs if you need?

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                If you are pinging from VLAN2 to VLAN3 then the rules governing that are on VLAN2. Your screenshot above shows the rules on VLAN3 so none of those apply.

                                What rules do you have on VLAN2?

                                F 1 Reply Last reply Reply Quote 0
                                • F
                                  fxpro @stephenw10
                                  last edited by fxpro

                                  @stephenw10 here are the VLAN2 rules:

                                  d83ff241-7288-4de6-afb6-17600e92afa3-image.png

                                  As you can see, VLAN2 allows traffic to VLAN3
                                  Thus:
                                  VLAN2 ---> VLAN3 is here:
                                  678b7ce3-5ac9-46be-9d58-9f3e1c4cf0f3-image.png

                                  and on VLAN3, allows traffic from VLAN2 to VLAN3 here:
                                  86f7bc36-1fa4-491e-949b-27d04d29852b-image.png

                                  Again, this has nothing to do with the problem.

                                  As I've shown previously, this was working when I was on the PPPoE connection.
                                  In fact, I can also get this working if I Disable WAN_DHCP !!!

                                  But the moment I Enable WAN_DHCP, I lose inter-VLAN connectivity !
                                  This has absolutely NOTHING to do with firewall rules and from what I can see, everything to do with Routing to 'a' gateway. The problem is WHY do the packets route to the WAN gateway for internal inter-VLAN traffic when it should be routing to the local network gateway/s, when I have enabled WAN_DHCP ?

                                  When WAN_DHCP is disabled, I will get the correct routing to the local gateway for inter-VLAN traffic. Why is this occurring? Maybe there is a section in the GUI where I can force this?

                                  If I can find the reason why this is happening, I can solve the problem, because to me it is clear this is a Routing to gateway problem and I can prove it repeatedly, if I disable WAN_DHCP because I will regain inter-VLAN connectivity.

                                  • Surely this is a bug?
                                  • Is there a work around?
                                  • Can I make a bug report to Netgate? if so where?

                                  Please help, getting desperate now.

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    Ok so that top rule will catch all traffic from anything is VLAN2 and force it via the VPN gateway. The only time that doesn't happen is if the VPN is down.

                                    You need a rule above that to pass traffic from VLAN2 to VLAN3. And if you want that to allow pings it must be either 'any' protocol or ICMP.

                                    Firewall rules (on any tab except floating) are applied to traffic coming into that interface.
                                    So the rule you have with source VLAN3 subnets there can never match any traffic. All traffic on the VLAN2 tab will have source VLAN2 subnets. The same is true for some rules you have on the VLAN3 tab.

                                    So it looks like this explains what you are seeing with regards to the gateway. When the system has a default gateway the VPN connects that then the top rule forces all traffic via that preventing pings between VLAN2 and VLAN3. Without a default gateway set the VPN cannot connect so the VPN gateway is invalid. The default behaviour is for the rule to be applied without a gateway set so that then allows pings. That can be changed.

                                    But adding a rule to by-poass policy routing for local traffic on VLAN2 will correct this.

                                    F 1 Reply Last reply Reply Quote 0
                                    • F
                                      fxpro @stephenw10
                                      last edited by fxpro

                                      @stephenw10 Thanks mate, you've just proven I'm a complete dill 😊

                                      I modified the rules to allow ANY and then move the rules to the top and voila' I get the Inter-VLAN connectivity.

                                      I don't know how to say thank you, You've really made my day.
                                      Thank you so very much.

                                      Problem solved. I can now ping/access all VLANs (after adjusting the order of the rule accordingly to the top). It seems that for there not to be problems, the inter-VLAN configs need to be above any WAN/VPN connections. I hope this helps anyone else that is a dill like me 🤦

                                      G 1 Reply Last reply Reply Quote 1
                                      • G
                                        Gblenn @fxpro
                                        last edited by

                                        @fxpro It certainly helps to know, as @stephenw10 said, that rules work from the top to bottom. But the key here is the moment a rule catches some form of traffic, no further rules below will apply to that traffic.

                                        Also, check the numbers in the states column, where 0/0 indicates the rule has not been used at all.

                                        Also good to know, when you created your VLAN, you already have one invisible rule in place, the default deny all. So nothing goes out anywhere until you allow it to.

                                        Typically the first rule to add, is that "default" allow VLAN-X to any rule. This will give VLAN IP's internet access, as well as access to any other subnets in your setup.

                                        However, one key reason for VLANs is to isolate different types of traffic or users from each other. So most commonly you would add deny rules to block inter VLAN access, above that all to any rule. Something like what I have for my GuestVLAN used on wifi, allowing internet access but nothing else.

                                        37d2b5bb-84fa-4ca0-b362-5dadef33f3f5-image.png

                                        If you then want to add some policy that allows some IPs to access another subnet, you start adding those rules above the block rules. Perhaps you have a PiHole on LAN that you want to use also for VLAN2 and VLAN3, so then you create allow rules from VLAN2 and VLAN3 respectively with Destination PiHoleIP, and so on.

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          Glad you were able to get it sorted. 👍

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