@mountainlion I disabled pf filter, now I cant get admin gui access.
From console, I was able to issue pfctl -e and the gui still didnt work.
I shutdown and started, still no go.

Any ideas how to re-enable the gui after issuing the "disable pf-filter"?

I seem to have resolved this issue by reinstalling an older version of pfSense v2.4.5. With that in mind, I believe this to be a bug with v2.5.1.

@marekandreansky said in Adding secondary WAN to existing network without completely changing topology:

Does seem a shame that they only have dual cores and 2GB of ram.

Why - do you need a Ferrari to drive to the corner store, or will that Sonata work?

Do you really need more horse power than needed to pull the plow, or do you need 8 Clydesdales?

This is an appliance this going to really do 1 thing.. Well actually a few things, but It will do it well, it will do it for a long time, and it will use very little power doing it.

The appliance update whenever a new version comes out - with appliance you get pfsense+ just use to be call FE vs CE..

@spacebass
You have to route SMTP traffic from public sources over from B to A. To send response packets back the correct path to B instead out to the default gateway, there is a special traffic marking required, called reply-to.
But as far as I know, this doesn’t work on IPSec interfaces and it doesn‘t work on CE 2.5.1.

@sgtkilgore406 said in pfSense Multi WAN Site-to-Site OpenVPN Tunnel Port Forward Routing Issue:

I have created a virtual interface for it and created rules but the RA VPN appears to be broken. I'll fool around with the RA VPN later and try to get it fixed.

It should work this way though. It doesn't matter if the rules resides on the interface tab or on OpenVPN. The OpenVPN is just an interface group including all OpenVPN instances running on the box and is added when the first one is set up.

Hello,

After months of work with @amassi, here is our feedback.

Multicast accross VLANs works with igmpproxy on pfSense <= 21.02.2-RELEASE but there are several cumulative constraints:

Only one upstream interface so only one VLAN can send multicast at once. In theory, pimd (available in additionnal package) permits several upstream interfaces but it's totally buggy (when we start it, it tries to bind() on each network interface so it exceeds MAXVIFS kernel value - 32 - so it crashes. Obviously, it ignores its configuration file in which we have disabled unwanted network interfaces and it still tries to bind() on all interfaces).

Only 32 VLANs with multicast enabled at the same time (upstream + downstreams). Cause: MAXVIFS = 32 in FreeBSD kernel. When we add CARP on each VLAN, the limit becomes 16 multicast-VLANs activable in igmpproxy. Cause: igmpproxy sees each VIP as a network interface so it tries to bind() on it and reaches MAXVIFS. The more VIP we add on multicast-enabled interfaces, the less number of multicast-available interfaces we have. Same cause.

A multicast-enabled interface can't have more than six VIPs on it. Otherwise igmpproxy refuses to start.

A multicast-enabled VLAN must be in the XX first VLANs listed in Interface > Assignments > VLANs (all our VLANs are configured on lagg0). Otherwise igmpproxy don't bind() on it (no log message "adding VIF, Ix XX Fl 0x0 IP 0xXXXXXXXX lagg0.XXX). On fresh install XX = 22. With CARP (for routing purpose) on all of our VLANs, XX = 21 (obviously, only VIPs on multicast-enabled VLANs are counted). With CARP for routing and destination NAT, XX = 20. If we add additionnal VIPs on these multicast-enabled VLANs, XX = 19. We have moved our VLANs with a lot of VIPs at the end of the list => they are not counted. We have added "parking" VLANs (unused VLAN IDs) in 17 th, 18 th, 19 th position in Interface > Assignments > VLANs. If we need to add VIPs on multicast-enabled VLANs, we will delete them. If we need to enable multicast on new VLAN, we will replace one ununsed VLAN ID by the new one and so VLAN will be in the 20 first multicast-activable VLANs.

In addition to these limits, we had an unknown problem with our FOG setup. We have installed a new storage node (in FOG terminology) and attached it to our existing FOG server => multicast works. New storage node has same OS and same FOG version (1.5.7) than the old one. For multicast, FOG uses the udpcast tool. sha256sum of updcast binaries are equal. So no idea of the root cause, but we now have a working inter-VLANs multicast FOG server with pfSense.

Finally, our XG-1541 reboot when we plug DAC cable in Chelsio's port and igmpproxy is enabled. At reboot, web gui prints core dump. Disable igmpproxy before plug DAC = no crash.

In summary: if you want to use inter-VLANs multicast with pfSense, you need to use igmpproxy + take previously-listed limits into account + maybe reinstalle your FOG storage node.

Bye

@webdawg
I suspect, you only need NAT. Maybe you can provide more details, what exactly you're trying to achieve.

Firewall rule have to be added to the interface the traffic is coming in for sure.

If the address is routed to the primary one there is also no need to assing the address as VIP, but may be done anyway.

@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.