PfSense 2.2.1 seems to have broken Aliases

[pwnell]

I have many aliases set up and for those aliases several NAT rules.  One specific NAT rule forwards 3389 to an internal server, with the source address pointing to one alias.  This alias has several IP addresses and one dyndns host name (xxx.dyndns.org).  The system worked perfectly in 2.2.  Yesterday I upgraded to 2.2.1 which went smoothly, no other changes were made.  I found myself unable to connect to 3389 (I am one of the IP's in the source address alias and this server is remote to me).

I tested and from another location which is also in the source address alias list, the connection failed.  I amended the alias, and saved it, and then applied the changes.  Once done I could connect to 3389 again.  Looking at the firewall logs, I can clearly see the firewall dropping the packets from these IPs in the alias list.  Why?  After a couple of hours the system again reverted to starting dropping these packets, until I saved / applied the alias again.

[doktornotor]

Pretty much doubt it has worked perfectly in 2.2. Stop mixing FQDNs and IPs in an alias.

https://redmine.pfsense.org/issues/4296
https://doc.pfsense.org/index.php?title=2.2.1_New_Features_and_Changes#Known_Issues

[pwnell]

Thanks, I will try that.  Instead of using one Alias with both FQDN and static IP entries, I'll split it in to two Aliases and then create two firewall rules - one for each alias - and one Alias only has the FQDN entries and the other only the static IP entries?

[phil.davis]

Yes, that is the workaround until the issue with mixed aliases is fixed.
But I am surprised it worked for you in 2.2  :-\

[johnpoz]

"One specific NAT rule forwards 3389 to an internal server"

why??  I never understand the fascination with unsecure setups.  Why would you not just vpn to this remote site and than access whatever resource you want.  If you want to restrict where a vpn client can go, then write those rules. For starters what are you doing with that rdp?  What if that box is down, what if you want to send it a wol?  How do you have remote access to this remote pfsense?

[jimp]

If you're running amd64 and want to test a workaround for that bug, give this a try:

fetch -qo /root/filterdns.fixed http://files.atx.pfsense.org/jimp/filterdns.fixed
chmod 555 /root/filterdns.fixed
cp /usr/local/sbin/filterdns /root/filterdns.orig
cp /root/filterdns.fixed /usr/local/sbin/filterdns
killall -9 filterdns

And then edit/save/apply an alias in the GUI to have it restart filterdns.

If it's worse, then just copy /root/filterdns.orig back over /usr/local/sbin/filterdns and kill/restart again.

Please note again that binary is for amd64 only.

[doktornotor]

@jimp:

If you're running amd64 and want to test a workaround for that bug, give this a try:

Is this in 2.2.2 snapshots?

[jimp]

I don't think so as it was a workaround that garga was testing, but ermal had a better long-term fix in mind. In my test VM that could replicate that bug 100% of the time, the "fixed" binary now works 100% of the time.

[ngreco90]

@jimp:

If you're running amd64 and want to test a workaround for that bug, give this a try:

fetch -qo /root/filterdns.fixed http://files.atx.pfsense.org/jimp/filterdns.fixed
chmod 555 /root/filterdns.fixed
cp /usr/local/sbin/filterdns /root/filterdns.orig
cp /root/filterdns.fixed /usr/local/sbin/filterdns
killall -9 filterdns

And then edit/save/apply an alias in the GUI to have it restart filterdns.

If it's worse, then just copy /root/filterdns.orig back over /usr/local/sbin/filterdns and kill/restart again.

Please note again that binary is for amd64 only.

Hi Jimp! I applied that fix in pfsense amd64 and works great! Thank you! I have an pfsense i368 with the same error. Can you fix filterdns to this arch??

Sorry for my English!

[jimp]

I didn't build that one, I was just passing it along as it was generated by another dev. The fix isn't "proper" per se, it has some issues yet. I'm not sure if getting one for i386 at this point is viable until a proper fix is committed.