@ahole4sure
Maybe the routing table brings dissociation.

However, I'm not familiar with Tailscale. Don't know, what it does.

@Gertjan said in pfSense 2.8.0 - Routing stops intermittently after update from 2.7.2:

[...]matches your usage case ?

You have Static routes, multiple sub nets ?

Yes, the remote location has its own subnet and connects via a static route to the network in the main office. The default route of the remote location is set to the router that provides internet access in the remote location.

@carrzkiss why is that? HA proxy can listen can send stuff based on the uri to different machines.

something.domainX.tld goes to your IIS IP
otherthing.domainX.tld goes to your linux box.
etc..

@NVDude said in Firewall Aliases IP Addresses with Port Forwarding:

By default this creates the rule with source "Any"

Be default, any rule has any in it, regardless. You are able to change the source in the NAT-rule too. So everyone is wondering why you didn't do that and fiddle around with the linked rule instead.
But I also did this in some cases, for better visibility, especially with different aliases which I didn't wanted to combine, so I created the same firewall-rule but with different sources three times or whatever.
But for best efficiency you do it right in the NAT-rule because then the not-matching traffic doesn't get NATed in the first place, I guess.

@johnpoz
Thank you for the clarifications
I finally opted to route everything on pfsense and remove SVIs on switch. It's so much easier than to manage the ACLs on switch

If I end up needing more L3 switching throughoutput on some vlans, I can always try a hybrid setup with static routes on pfsense and running the dhcp server on the switch for those vlans

@AndyRH Hi, I managed to access the 192.168.11.1 Web Gui with the changes you've shared https://forum.netgate.com/topic/197766/how-to-connect-to-xgs-pon-controller/15?_=1751026822174
This access ( NAT OutBound ) to 192.168.11.1 Web Gui succeeded after i did a Power On Reset to the Netgate 4100 after making the NAT Outbound changes. It hence seems that NAT changes did not take effect after I "Save" and "Apply Changes" and only became effective after I did a Power On Reset. Also another point to note was this Web Access to 192.168.11.1. was successful when my WAN is on DHCP and without a Vlan assignment. I may have to open another thread for assistance as I need to access 192.168.11.1 with WAN on DHCP and with a VLAN for the WAN. Thanks to you, at least I have a window into the WAS-110 albeit when the WAN is not configured with a VLAN. On your temperature for the WAS-110 its 50/48/46 Celsius with ambient temperature at 30 degrees Celsius and with a cooling fan in place. Have a a good one.

@thomaspsimon
I guess, you're using a policy-based IPSec tunnel.
If so this is not going to work, unless you route the whole upstream traffic from the branch over the VPN, which might not be desirable.

It would be doable with any other VPN solution, however, which gives you real routing capability.

Big thanks @viragomann Your BINAT insight was the missing puzzle piece, tunnel’s up, traffic’s flowing, and packets are happy. Much appreciated!

@enthu19 thank you so much, that worked!

I learnt something new :)

Thank you again enthu19!!!

@Bob-Dig
if I use cloudflared docker container then I can get to the sites no issue so not sure why it isn't working normally okay thanks will poke around more

@Gertjan said in PORT FORWARDING NOT WORKING AFTER UPGRADE TO BETA 25.03:

Anyway, very soon we can ditch IPv4 and Natting and things become easy for everybody

Yeah soon ;) they have been saying that for 20+ years already.. Soon ;)

@SteveITS

Yes, by "lockout" I mean exactly that. Couldn't access the web interface, connect through SSH or even ping the machine until packet filtering was manually disabled.

At that time there weren't any firewall rules except for the anti-lockout rule which is present on the LAN interface by default if I remember correctly.

It was only after everything finally worked as intended that I started creating my own firewall rules, and from then onwards everything's been working fine. :-)

My best (and honestly a little uneducated...) guess would be that my self created interface mismatch prevented me from connecting to the pfSense machine.

I suppose the lesson here is that taking shortcuts such as the one described here can't be relied on. No more trying to rename interfaces on pfSense / FreeBSD. 😬

On the bright side, no interfaces have gone down since performing a fresh installation and I sure gave it something to chew on.
That's with the default RealTek kernel driver, by the way, the same one that kept acting up in the past and which prompted me to try the alternative v1.98 driver.

For lack of a logical explanation I suppose we can call that a lucky coincidence.

@viragomann thanks a lot. From lan to wan works right.
I must test how it works for some internal exposed services.