Friendly bump here... anyone have any idea as to what would lead to the odd on-the-hour occurrence of these log entries? Thank you

@viragomann Thanks for your response, to be honest I haven't played with the firewall rules yet. In the coming week Ill see what I can figure out with the help of your reply.

@gertjan The suggested system patch fixed the issue. Thank you!

@steveits Seems like my problem is on the Cube part, but I don t get why. I have created a new interface for the cube, nothing special here with DHCP. The interface show up. [image: 1647328853819-4456166c-8929-459f-a368-b9b8e004b376-image.png] When I try to use Gateway groups or policy routing, Internet is not working anymore because of this: [image: 1647328931384-955b7b1e-7d2a-4dc4-9bb3-872f2bba3f32-image.png] OK, but when I do the same test with the IPv6 link local it works: [image: 1647328987666-4076efaf-f50c-4c19-87f9-54398e0834b8-image.png] Why is it with the link local working? And what is on my configuaration wrong? I can only select the ipv4 for v4 traffic and v6 for v6 traffic on the Gateway. And this does not work

@viragomann said in Multi IP Public adress: ‎No, la red específica no se puede seleccionar. Tienes que tomar "red" e ingresar la dirección de red y seleccionar la máscara.‎ thanks for you support and help, tomorrow i will test onsite this configuration,

@stephenw10 Oh yeah, I just omitted that portion of it. I'll look into if there are errors from that point about dpinger. After I restarted dpinger I am seeing that the route uses for the 8.8.8.8 to that Interface are going up when refreshing so that's a good sign at least. I did some digging in the logs, turns out I upgraded it earlier than I thought(Feb 21st) so dpinger was working for a while up until the 7th of March. So I'll just have to dig around in the logs to see if I can find any sort of reason why it would have stopped functioning despite it showing as up and running. This is definitely something that we can't have happening on a normal basis if it's a reoccurring issue as before 2.6 we ran without reboot for over a year with no issues, so I'm hoping I can find something in the logs that will help figure out why.

Enabled log for PBR rule from PF2, and rule is not matched (which should be) First rule under LAN rules is this PBR rule. Anyway, thanks for all help, I will try with upgrade to current version of Pfsense first...... BR

tcpdump from the local server with filter of port 6053 tcpdump.pcap

@johnpoz In my case switching my WiFi router to an AP forced all of my WiFi devices to change subnet at the same time. I was concerned that some might not make the transition smoothly. I had to reboot a couple of my IoT devices to get them to request a new IP, but the impact was minimal. I was concerned that behavior might be more widespread.

@ph0t0g said in Routing Between Virtual Switches: The problem is that devices on the switches can only talk to other devices on the same switch, not devices on different switches. Hi, Based on your drawing, this is perfectly normal. @ph0t0g "All devices on all switches can talk to each other on all ports." The rest I don't understand, why segment your network if you then want to create an any - any rule in the end? Put it all on "one" vSwitch and you get what you want BTW: routing between networks should also work, because that's pfSense's job, so you're configuring something wrong, more info needed...

@kom Hey I just wanted to follow up and let you know for posterity that I discovered the solution. Simply setting each subnet/interface's allowed gateway on the firewall wasn't enough. The traffic MUST BE TAGGED in a floating rule. So basically here is a summary for anyone who might be searching for this: Goal: Route different traffic to specific gateways, only allowing in/out on specific interfaces or subnets. I have one WAN interface and two LAN interfaces: one of which should ONLY be to VPN (can be single gateway or gateway group), and the other should ONLY be through ISP. Add firewall allow rules on each interface. LAN to ISP only [image: 1647034649245-45624255-c3b2-4e88-b5de-0670de19f825-image.png] LAN to VPN gateways only [image: 1647034679734-4e7095d3-3ae7-4768-abae-33aee2e46f3b-image.png] In each rule, tag the traffic with a name you choose: [image: 1647034816651-1bbbdcd6-e3ef-4738-a9a6-7c89ae21ac2f-image.png] [image: 1647034840409-7757ab98-6727-4c3a-9385-e434b2a85d82-image.png] Add two floating BLOCK rules. [image: 1647034942574-bb7d5327-6a24-47c2-9d1d-f5c5866008c7-image.png] When you set the block rules for each inbound interface (WAN and VPN), set the opposite tag in the "tagged" field. This will refuse any packets that have matching tags. This is what finally stopped any detection of incorrect traffic on either gateway. Thanks for your help though.

@serbus That seems to have fixed it. Thanks!!!

@beartm yeah sorry to bring this thread back to life but it was exactly what i'm trying to do! so how do you route certain traffic through pfsense or does all your traffic go through it? i was trying to setup socks5 proxy so i can configure it in certain applications and then i know all traffic from that application is using it and then going through the VPN (i've forced all traffic via the VPN on my pfsense box).