@johnpoz Many thanks for the reply. I am pinging from the web interface of the pfSense itself so I expect the packet to be generated for the WAN interface directly, although I have also tried from a PC on the LAN interface, I wanted to simplify the issue as much as possible. As mentioned, this is a fresh install with as little as possible changed to demonstrate the problem. No WAN firewall rules, no NAT rules, only the default LAN firewall rules that are not policy routed as I did not change any of their configuration options. I will attach some screenshots with my routed network hidden although I guarantee it is not the same or overlapping with the WAN or LAN subnets. The Ping: [image: 1648030656750-pfsense_ping.png] The ARP table: [image: 1648030686699-pfsense_arp.png] The route table: [image: 1648030712469-pfsense_routes.png] The captured ping packet going to the default route MAC address rather than the OtherGW MAC address: [image: 1648030803004-pfsense_wireshark.png]

@crucialguy Thank you. That helps a bunch.

please see this post for way more information.

Hello, Did you get that to work? I'm also trying to advertise OpenVPN client static routes via BGP (FRR) but until now without success pfSense doesn't create a /32 route (client) in its routing table. [image: 1647969236388-image_2022-03-22_131355.png] My aim is: connect the road warrior to pfSense (WAN) using SSL/TLS + User Auth (LDAPS) mode (ok, working) advertise the static IP (10.10.10.22) assigned to the road warrior to PE2 (BGP neighbor) (not working) In my scenario: PE2 has a BGP session established to pfSense PE3 (10.200.200.50) has ACL control allowing the network 10.10.10.0/24 to get SSH access Thanks

@vitosmaldino re: point 2, that part is correct. You can use a web site, other DNS (1.1.1.1), basically anything that responds to pings.

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