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_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.
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:
955b7b1e-7d2a-4dc4-9bb3-872f2bba3f32-image.png

OK, but when I do the same test with the IPv6 link local it works:
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
45624255-c3b2-4e88-b5de-0670de19f825-image.png

LAN to VPN gateways only
4e7095d3-3ae7-4768-abae-33aee2e46f3b-image.png

In each rule, tag the traffic with a name you choose:

1bbbdcd6-e3ef-4738-a9a6-7c89ae21ac2f-image.png

7757ab98-6727-4c3a-9385-e434b2a85d82-image.png

Add two floating BLOCK rules.

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.