@network-stack-445 said in Does pfSense support sub domain policy based routing: IPS signature updates That is something is outside pfsense/netgate - depending on what signatures your using, there well could be a cost associated with those..

You are aware the issue linked upthread has a committed fix already which addresses the problem? We didn't have any problem solving it, there just hasn't been a release including the fix yet. https://redmine.pfsense.org/issues/11806 You can apply the commit there with the system patches package if you need to use IPv4 link local gateways.

@evosnipe You should not need to configure a bridge to get this working. I would advise you to do a factory restore of your unit to undo everything you did and go through the initial setup wizard again. When doing the startup wizard, don't give it any upstream DNS for now, just let Resolver do its job. Once you have that working, plug your AP into LAN and make sure devices on it work. Then decide if you want to use OPT1 or do it with a vlan to get the router working.

@gertjan thanks a lot Sir. This is more clear. @KOM thank you for your comments.

I'm still having severe problems with routing. When I ping 1.1.1.1 or 1.0.0.1 from the pfSense shell, it goes into a routing loop and exhausts the TTL. When I ping 8.8.8.8 or 8.8.4.4, I often get "no route to host". Sometimes it works. But if I specify the source address, it works well: [2.4.5-RELEASE][root@pfSense.int]/root: ping -S 10.20.204.90 8.8.4.4 PING 8.8.4.4 (8.8.4.4) from 10.20.204.90: 56 data bytes 64 bytes from 8.8.4.4: icmp_seq=0 ttl=116 time=21.044 ms 64 bytes from 8.8.4.4: icmp_seq=1 ttl=116 time=20.887 ms 64 bytes from 8.8.4.4: icmp_seq=2 ttl=116 time=21.234 ms 64 bytes from 8.8.4.4: icmp_seq=3 ttl=116 time=21.606 ms [2.4.5-RELEASE][root@pfSense.int]/root: ping -S 10.20.204.90 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 10.20.204.90: 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=21.235 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=20.973 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=21.790 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=21.884 ms round-trip min/avg/max/stddev = 20.973/21.486/22.240/0.308 ms [2.4.5-RELEASE][root@pfSense.int]/root: ping -S 10.20.204.90 1.1.1.1 PING 1.1.1.1 (1.1.1.1) from 10.20.204.90: 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=58 time=15.984 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=15.907 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=15.715 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=15.637 ms [2.4.5-RELEASE][root@pfSense.int]/root: ping -S 10.20.204.90 1.0.0.1 PING 1.0.0.1 (1.0.0.1) from 10.20.204.90: 56 data bytes 64 bytes from 1.0.0.1: icmp_seq=0 ttl=58 time=15.852 ms 64 bytes from 1.0.0.1: icmp_seq=1 ttl=58 time=16.028 ms 64 bytes from 1.0.0.1: icmp_seq=2 ttl=58 time=16.030 ms 64 bytes from 1.0.0.1: icmp_seq=3 ttl=58 time=15.974 ms Here's the end of the output from pinging without the source address: 36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.20.204.90) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 77e2 0 0000 05 01 0000 127.0.0.1 1.1.1.1 36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.20.204.90) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 77e2 0 0000 04 01 0000 127.0.0.1 1.1.1.1 36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.20.204.90) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 77e2 0 0000 03 01 0000 127.0.0.1 1.1.1.1 36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.20.204.90) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 77e2 0 0000 02 01 0000 127.0.0.1 1.1.1.1 36 bytes from localhost (127.0.0.1): Time to live exceeded Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 77e2 0 0000 01 01 0000 127.0.0.1 1.1.1.1 What's going on!?

@612brokeaf said in 2.5.1: missing route to localhost (no joke): For completeness: I have another manual modification in place, in /etc/inc/config.lib.inc, and that is changing alias_make_table(); to alias_make_table($config);, because otherwise I kept getting crash reports / PHP errors complaining about alias_make_table being called with zero arguments and expecting one. This was being triggered from the ACME cert renewal cron job. There is also another bug in ACME, complaining about the function getarraybyref() not found. Even though all PHP include chains look fine, I can't find another way to fix this than pasting that function into the same scope in ACME. This is for another topic though - this issue looked fixed in 2.5.0, but maybe I fixed it by hand and forgot about it until 2.5.1. Please create a bugreport about this issue: https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html

@johnpoz Thank you for your swift replies. I was able to fix it the same day, even my reply is late. (Yes the switches are different. They are not connected to each other.) The problem was, as you mentioned, that the PLC gateway was not set. Thanks again.

@makq it will be fixed when they release next update.

@nickf1227 Wanted to give you an update. I was able to resolve the issue by hard coding the gateway IP monitor address to 8.8.8.8. Starlink is working great on my SG-1100 now.

@qwerty123 My generic understanding of it is: The WAN interface of pfSense is continuously pinging the device it is connected to (e.g. a modem, an ONT, etc...). If you open the advanced drop down you will see a bunch of settings that control this behavior. Essentially if the WAN interface does not get a response from the device it is connected to for a certain period of time it will treat the WAN interface as if "the gateway has gone down". When the WAN interface is down no external traffic can enter or leave the pfSense box. There are some additional settings under Settings > Advanced > Miscellaneous > Gateway Monitoring that are affected by the gateway "going down". This become particularly important when there are multiple WANs. When WAN#1 fails it may be desired to automatically switch over the WAN#2. This makes it possible for pfSense to know when to stop using WAN#1 and instead use WAN#2. When Gateway Action is selected the WAN interface(s) do not check if it has a connection. This means the WAN interface is treated as though it is always up. In the example I used above with x2 WANs; if WAN#1 is never marked as down then, WAN#2 is never utilized, and external bound traffic will not be able to enter or leave until WAN#1 is back up again or until manual intervention. For the majority of users, Gateway Action should stay un-selected. This will allow pfSense to automatically do its thing in the background.

@antionline Yes by adding some extra custom config to Resolver, but I don't remember the exact syntax. I had to do it once for my wife who was playing a mobile game that would slow down if it couldn't talk to its ad servers so I had to figure out a way around it. I no longer need it so I deleted the config months ago. Edit: Found it in an older backup config.xml. The address to bypass pfB was 192.168.88.110. server: access-control-view: 192.168.88.110/32 bypass access-control-view: 192.168.88.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes server:include: /var/unbound/pfb_dnsbl.*conf

@djinn1 I fixed the problem after 20 hours messing with settings. The problem was pfsense version 2.51. They fu**** it up with the latest version. I downgraded to 2.5 and everything works as it should be. I just backup all the setting before and restored same settings.

@viragomann It seems that the problem is only when i download torrents, even if i use a vpn server! need to find a solution