@floydque

You could assign that URL to an Alias.
And then policy route packages that have that alias as destination , out of the desired gateway.

/Bingo

@shepherdkai said in Dual WAN at home? Anyone have stories on their experience?:

I have a Ubiquiti EdgeRouter Lite sitting in a box that I plan to break out for this use case.

Just curious... If you're going to use that box as your main router/firewall, why are you asking these questions on a pfsense forum?

Solved my own problem. Forgot to put additional static routes on my home router for the additional networks.... Silly me...

@jimp thanks for all the help. And the description you wrote when creating the issue was pretty accurate.

@Gertjan thankfully a solution was found. All I can ask for :)

@helviojr
Ensure that there is no rule on an interface group or floating tab matching to that concerned traffic.

@akirasensei said in 4G internet on 2nd WAN giving awful speeds and can't do local network between devices! Help!:

but the NAS is on under the main WAN network)

Well if your routing traffic to your gateway - no you can not get to network that are locally attached.. Same as on your other network..

@lak
pfSense can do it, but I don't know any way with IPSec.

Are link 1 and 2 sharing the same ISP gateway IP ?
Check https://docs.netgate.com/pfsense/en/latest/multiwan/considerations.html

-Rico

@hsv said in Is there a way to add many static routes:

I need to add about 100 static routes.

Just my curiosity cat meowing at me - why? Can you not just summarize the routes?

For example route to 192.168.0/24 and 192.168.1/24 could be routed as just 192.168.0/23

If you have a lot of routes - I would try and summarize as much as possible.. Shoot you could sometimes route 100 with 1 statement, ie 192.168/16 for example..

Or run a routing protocol? So the routes are exchanged?

OK, I worked it out!

I had the following Firewall rule for LAN:

Screen Shot 2021-04-06 at 8.17.46 pm.png

But of course, the 10.8.0.0/23 and 10.9.0.0/23 (I changed them to /23 instead of /24) are not in the "LAN Net", so I had to add extra rules to allow that traffic out:

baecb64d-b9fb-4d84-b216-035dbd903399-image.png
That as well as the static routes fixed it!

Dude I don't know what else to tell you.. Its BORKED!

Fix your setup.. There is nothing for pfsense to do here.. what you are trying to do is wrong - no matter how you look at it, or want to think you should be able to do it..

Even the most basic grasp of how networking works tells you how you have it setup is just plain borked..

edit:

When a client wants to talk to an IP.. Is that IP suppose to be on my network.. Does it fall inside the IP space of my address and mask. Oh its on my network - ARP!! for it.. Ok device with mac address abc, answered for IP 123.. Send the traffic to that mac..

In no scenario does the client say - oh no answer for arp, send it to my gateway... The only scenario where it "could" work is if the gateway (pfsense) was doing proxy arp and answer for any IP that doesn't answer arp.. Which there is no such thing - there is a way to do proxy arp for VIPs..

So if you have some device on your /16, and it wants to talk to a an IP that is on one of your vlans that falls under this /16 block.. How would it know where to send the traffic.. So either your L2 are not actually isolated. Or you have pfsense doing proxy arp for every single IP under the /16 that is not actually on the /16 L2..

You can not expect your setup to ever function correctly.. Pfsense will clearly warn you - as it did that what your trying to do is wrong, ie the overlapping networks warning. But how can it warn you from a cmd line setup? Pfsense can try and keep users from shooting themselves in the foot.. But it can not protect you from every scenario of shooting yourself.

Setup your networks on pfsense be them native or vlans so they do not overlap..

@viktor_g Thank you very much!

normal it will not give you problems restoring it, interface settings looks ok

OK, I implemented a workaround for this problem.

I wrote this little script:

<?php require_once("interfaces.inc"); $cached_def_gw_if_file = '/tmp/cached_def_gw_if'; $current_gw_ip = route_get_default('inet'); $current_gw_if = get_gateway_interface($current_gw_ip); $old_gw_if = file_get_contents($cached_def_gw_if_file); if ($old_gw_if === false) { file_put_contents($cached_def_gw_if_file, $current_gw_if); exit; } // Just in case the file was edited manually for test purposes and contains some whitespace $old_gw_if = trim($old_gw_if); if ($current_gw_if != $old_gw_if) { log_error("Default gateway interface changed from $old_gw_if to $current_gw_if, killing old states..."); mwexec("/sbin/pfctl -F states"); file_put_contents($cached_def_gw_if_file, $current_gw_if); } function get_gateway_interface($gateway_ip) { $interfaces = get_interfaces_with_gateway(); foreach ($interfaces as $interface) { $interface_gw = get_interface_gateway($interface); if ($gateway_ip == $interface_gw) { $real_interface = get_real_interface($interface); return $real_interface; } } } ?>

and created a cron task which executes this script every minute.

I am not sure how reliable this "solution" will be, but a dozen of gateway switchover has shown that everything works as expected, the Wireguard connection is routed over Tier 1 gateway after it recovers.

During my little research, I also found this post, but unfortunately samtoopid's script didn't work for me - it only kills states on WAN interface, and in my case it's not enough, only flushing all states makes Wireguard connection switch to new Tier 1 gateway.

@jimp Thanks for posting this. This is exactly my problem with my pfSense Plus. I have two WANs with my default one being GCNAT. My secondary WAN has a static IP which is used for inbound connections which need entry to my network.

I didn't have any problems with 2.4.5p1. I can only make it work now if I change my default gateway to my static IP WAN. This connection is very slow compared to my other WAN. Hopefully they come up with a workaround soon.

@johnpoz said in Force traffic trough a getaway with specific mac address:

If so then really all you need to do is fudge the last 3 numbers... Ie the device ID, the block ID or OUI the 1st 3 numbers could be left alone, this only identifies the vendor that made the device. Not the actual device.

I am very pleased with this model USB-to-LAN. I have previously tried up to 9-10 USB2LAN adapters, pfSense (and probably FreeBSD) had no drivers for some or others had large load losses. But only this model surprisingly endured tests with high loads on the net without loss.

@steveits said in dpinger shows 100% loss after gateway recovers:

If you view the gateways page does it recover?

No, the Status -> Gateways page shows 100% loss.

As I said, if I run dpinger in shell manually, it shows the same behavior - the output shows 100% loss even after 10 minutes passed since physical link recovery, but if I restart dpinger, it shows 0% loss as it should.

@louis2 said in Identical!! access and filtering towards a local server, for internet located clients as for local clients:

is handled "exactly" like a call coming from the internet.

The most simple solution is probably : Not inviting the Internet in your own local infrastructure.
Use a VPS (or cloud thing, whatever they call it these days), somewhere in a data center. The cost will close to nothing these days.
Internet clients -and your access, will be guaranteed treated equally. You'll have nothing to do to enforce this.

Another solution : use a second ISP, so your local servers have their own WAN IP, and you access them just like the other clients.

Both propositions don't need any fancy setup.

Solved this -- kinda. I disabled CoDeL and everything went back to normal. Maybe I'll try setting it up again once 2.5.1 comes out.

@viragomann Well that's great. Thank you so much

Well, I figured out the issue, so thought I should post what I found, even though I feel a bit stupid now. Seems the main problem was a lack of knowledge on my part and that of Comcast Tier 1 support. Basically I had my gateway IP and static IP reversed.

Turns out that since we were originally using the Comcast CM as a modem/gateway without a firewall behind it, and then later set up the firewall in the CM's DMZ, the gateway IP was functioning as our public static IP. It didn't help that the person who set up the network had documented the gateway IP as our static and vice versa. And Tier 1 support apparently had no clue. It took Tier 2 support to point out my mistake and of course it seems fairly obvious to me now. I suppose my one remaining question is whether this is typical behavior of static IP implementations or specific to Comcast and/or other ISPs? Either way, lesson learned.

I should note one thing. I am 99% sure I did try reversing the gateway/public IPs when I first failed in configuring the static WAN interface, and that it did not work. What I did differently this time, however, was power cycle both the CM and FW, as opposed to just rebooting each; a simple step, mentioned by others in various posts, that might have helped me solve this sooner. Another lesson learned. 🙂

@viragomann

I give it a try tomorrow, thanks !

@incognito Were u able to make this work? Since WG has been disabled in 2.5

@luckyh_de said in Multi-WAN with Backup down:

So i have to prevent any Packet to the LTE-router AS Long as primary ist okay

Hi,

The failover mechanism does not allow this, you definitely need something that, which tells the firewall that the connections are alive
(minimum GW pinger ICMP traffic)

It turns out that I have to set up a bridge in Interfaces→Bridges. For mDNS bridging I also set up Avahi between the different subnets.

@cool_corona Yes I know it looks so - but that's not the case.

@ofloo This is not limited to IPsec this happens in wireguard also. Not sure why but sometimes reloading some settings makes it not filter maybe it's I'm just imaging it but it comes and goes and it's not limited to just IPsec.

I have do not filter traffic on same interfaces, I have just allow all traffic on the interface so no any firewall rule is there just allow any from any to any and yet !!! It filters.

Lately it happens to happen more on WIREGUARD Interface then it does on IPSec.

Also there is nothing in filtering rules to deny anything all the interfaces are allowed to pass through the traffic. Neither its showing anything on the system logs as well

I put my camera on the same subnet, but I am not very happy with that.
My MQTT devices did work cross VLAN, but I had a lot of errors telling me the packet was too short, shorter than expected. I moved these too to the same subnet and the errors are gone.

There seems to be a layer 3 routing issue in pfsense.

Can anyone who understands what is happing comment on this?

Thanks, Sebastian