@Ascar
Then the rule might be wrong anyhow, so that it doesn't match.

@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful!

Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense.

Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified.

Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule.

Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule.

Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality?

edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule.

Thank you again for your time and great detailed answer above!

@viragomann & @Gertjan

Thanks for your help!

Managed to solve it with a floating firewall rule! I only tried to block it from the interface that I thought the traffic originated from first. But now I tried to add a floating rule that blocked the traffic from all interfaces that shouldn't have access to it, and it worked!

@ptt Gracias por tu respuesta, pero encontré esta solución: http://www.bellera.cat/josep/pfsense2/Redundancia_y_Balanceo_de_Carga_con_MultiWAN.pdf, y ya está resuelto.
Saludos.

Yes, that is possible.

@brightwolf You can set a custom MAC address after you enable an interface.

screenshot673423.png

5th line down, under the specific interface settings screen.

Jeff

@JeGr said in Multiple Gateways on same subnet:

Why not simply reconfigure those routers

Because some devices (not mine) directly connected to router 1 have in their routing table certain rules to redirect traffic through 10.1.0.4. Hence those routers need to be on the same subnet.

These routers are shared by around 20 people, in 4 rooms on single floor. Hence I cannot change settings on those routers.

Just try to resolve it somewhere. In Diag > DNS Lookup in pfSense for example.

If you use an IP address or something actually resolves it must match the actual address IPSec is using.

@SergeCaron This is the result of a configuration error. Mine, of course!

The "Disable Gateway Monitoring Action" option was checked on the Tier 1 Gateway on Box #1.

Clearing this option, everything is working as expected on both boxes.

Regards,

@SergeCaron (Sheepish grin) I figured out the "cannot uninstall cleanly" caution in Patch Manager. I installed the patch and Patch Manager happily reports it can be uninstalled cleanly.

Unfortunately, I can no longer reproduce the disapearing Gateway issue: even if I force a complete disconnect of Tier 1, the Gateway Group does not switch to Tier 2.

So, I will close this issue for now.

@jimp Thank you!

Works perfectly as you described.

Regards,

@plusbil merhaba
Denedim ama bu şekilde de erişim sağlanmadı.

1- Vá em System -> Routing
2- Clique para editar o Gateway
3- Altere o campo "Data Payload" de 0 para 1
4- Salve e aplique a modificação
5- Reinicie o dpinger

Em um caso parecido, comentaram sobre estarem usando apenas um DNS da emrpesa no 1º link, então quando saía pelo segundo dava erro, então o recomendado deve ser usar os dois DNS, um de cada empresa.

Esse não é o meu cenário, por isso não sei a vericidade, mas já vi as pessoas comentando isso e deixei essa solução salva no pc para quando precisar rsrs... Mas já me confirmaram que funcionou, mas cada cenário é cada um, espero que resolva o seu também.

Additional noteworthy observations.

There was one strange thing about GIF configuration on pfSense 2.4.3 (and before?). I had to disable Outer Source Filtering on gif0 for the traffic to flow — otherwise even gateway monitoring pings were discarded upon reception: that is, if I remember correctly, ping replies were received on parent interface but rejected at GIF level. Those ping replies had proper source and destination addresses for both IPv4 and IPv6 and came in via proper interface. Of course, the IPv6 network for GIF tunnel itself was not the same as for overlaid network — but that is the case for all tunnels of all brokers. In particular, gif2 to the same broker was functioning well with Outer Source Filtering enabled by default, as well as gif1 to another broker.

Right before upgrading from 2.4.3 to 2.4.4, I noticed that gif2 also needs disabling Outer Source Filtering. I had no idea on why this happened and how long ago — just switched the offending setting, and the tunnel became operational for about a couple of hours until the update took place. Same as earlier, however, gif1 to another broker was functioning with Outer Source Filtering enabled by default, and used proper parent interface even after upgrading to pfSense 2.4.4.

Now that pfSense 2.4.4 is installed, I tried switching Outer Source Filtering back on and then off again — just in case — but observed no effect. That was expected indeed, as the primary issue is not with ingress filtering on local side: outgoing traffic is filtered by remote end because of improper source addresses caused by improper parent interface being used.

I also tried Disable Gateway Monitoring for both gateways corresponding to gif0 and gif2. That allowed the traffic to flow out unconditionally, but only showed that any kind of traffic — not just ICMP pings — chose wrong parent interface. I once again tried changing default gateway settings, and the outcome was equally negligible. That is, sometimes I saw small bursts of legitimate traffic pass out and then in (such as my NTP server making a request and receiving a reply), but it is hard to correlate to settings change as those bursts stop soon. The other times I see legitimate inbound traffic entering proper parent interface, but somehow filtered on local side — such as incoming NTP and DNS requests with no reply from my home server [because pfSense filtered those requests out]. :puzzled:

Same problem led me here. Hard to believe this is still a hack!

The biggest factor there is how much of that traffic will be over OpenVPN. If the majority of it is and you want to get anywhere near 2Gbps you're going to need the fastest CPU you can get hold of. Each OpenVPN process is single threaded so less cores at higher speeds wins here if you have only a few tunnels.

Steve