Block of 69.42.215.252 (freedns.afraid)

For about a week now, it seems that my IPFire has been blocking “69.42.215.252,” which seems to be the IP of my DDNS “https://freedns.afraid.org/.
And in fact the “afraid” service no longer works for me. I have disabled all “Blocklist” and “Location Block”, but IPFire keeps blocking that IP.
Has anyone had the same problem?
I thank you in advance.

Please try disabling IPS.
I encountered a similar problem
That I tracked down to the IPS.
It was blocking access to duckdns.org

1 Like

I thank you for the quick response. :blush:
I checked. It is deactivated. I’ll send a picture of the situation…

I’m sorry I had a second look at your
Picture and see that it is “drop hostile”
That is part of a different blocking system.
There is a check box for that.
It is odd that the port is 443 when dns is 53.

Yes. actually I have a ddns “casabenedetti…afraid.net” pointing to my dynamic public IP (ISP). Every now and then, via url “https…token=… afraid…” IPFire should update the “public IP/domain combination.”
It used to work, but now it seems that “afraid” is being recognized as hostile, despite the fact that I think I have disabled everything about blocklists and whatnot.

Look here firewall options
And location block as XD.

1 Like

@casabenedetti

You might want to raise a bug on this as the ip address you quote does not look to be covered by either the Spamhaus drop or edrop lists that I just checked so it looks like there might have been an error when creating the XD category of DROP HOSTILE from the spamhaus lists.

2 Likes

Thank you very much for the valuable answers.
In fact here is what was blocking:

If I disable it works.
How do I report the BUG? Never done it :blush:.
Can the rest of you guys do it?

https://www.ipfire.org/docs/devel/bugzilla

Your IPFire People email address and password credentials will work to login to the IPFire Bugzilla.

2 Likes

Okay, I’ll give it a try for the first time. I will try to study the steps well :blush: :blush: :blush:.

Here it is…
https://bugzilla.ipfire.org/show_bug.cgi?id=13628
Please correct or improve if necessary. And my first report. I hope I did everything right :blush: :blush: :blush: :sweat_smile:.

2 Likes

The IP 69.42.215.252 is assigned to AS17048 - Awknet Communications, LLC
which is listed on SPAMHAUS ASN-DROP list.
https://www.spamhaus.org/drop/asndrop.json

4 Likes

Before all the responses, I was going to post the following. I decided to post it now…

<<Why is “afraid” now being recognized as hostile?
I think there must be a reason. If “afraid” happens to be a “dangerous” service I will use duckdns.>>

This brings up the question if these IPs
are being blocked because they are being used for DDos attacks
by bad actors.
As with IPS blocking Duckdns…
What is interesting is IPFire updates my DuckDNS no problem.
But IPS blockes me from getting to web site.
Must be the order of the firewall.

1 Like

I can confirm that duckdns (IP update) works for me as well :blush:.

With “SPAMHAUS ASN-DROP” on.

I just started experiencing the same issue.

@arne_f - Is there a local IPFire whitelist that I can add/create for this?

I have a few home IPFire devices that all use freedns.afraid


EDIT - I want to whitelist the ASN or the domain or the IP. Whatever works.

1 Like

I was thinking about this myself. At worst even an iptables rule :wink:.
I tried to create the rule with ChatGPT, but IPFire tells me it exists and won’t let me add it. Here it is:

iptables -A OUTPUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables -I OUTPUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT

Neither of the 2 works :unamused:

I believe that the rules already set up in IPFire do not allow this new rule to be inserted. But I don’t know which rules to delete (and how).

iptables -I HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT

This rule seems to unlock on exit. But I have blocking inbound this time. But we may be close to a solution. I hope.

iptables -I HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables -I HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT

This accepts traffic only on port 443 inbound. I think it’s better.

-NO - iptables -I HOSTILE_DROP -p tcp -s 69.42.215.252 -j ACCEPT

With these 2 rules everything works for me!!! :+1: :+1: :+1: :+1: :+1:
But I don’t know if at the security level it is the top. I am waiting for suggestions.

The web page opens and my DDNS is updated from the url as before (With “SPAMHAUS ASN-DROP” on.).

If it is of interest, I post here the configuration I set up on “/etc/sysconfig/firewall.local”.
I am waiting for suggestions for any corrections and/or improvements to the code.

#!/bin/sh
# Used for private firewall rules

# See how we were called.
case "$1" in
  start)
        ## add your 'start' rules here


	iptables -C HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
	if [ $? -eq 1 ]
	then
		iptables -I HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
	fi



	iptables -C HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
	if [ $? -eq 1 ]
	then
		iptables -I HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
	fi


	;;
  stop)
        ## add your 'stop' rules here

	iptables -D HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
	iptables -D HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT

        ;;
  reload)
        $0 stop
        $0 start
        ## add your 'reload' rules here
        ;;
  *)
        echo "Usage: $0 {start|stop|reload}"
        ;;
esac

Basically, I made sure to check if the rule exists before entering it. If the rule exists, every time you run “start” from the terminal, the rule should replicate endlessly creating confusion. With the “iptables -C” check before insertion, this should not happen.

I don’t know whether it is important to do the check also for the elimination of the rule (stop/-D).

It has been way too long since I looked at iptables so I won’t be much help. One thing I do remember is there are CUSTOM areas for the IPFire iptables.

I may be sending you down the wrong path so make sure @arne_f (or someone) offers their 2 cents…


iptables chains for custom rules

Instead of altering the default iptables chains (which can be very dangerous when the firewall ruleset does not work as intended), there are extra chains that MUST be used for this. Packets pass these chains BEFORE they go through the rest of the ruleset.

For Filter table

Use CUSTOMINPUT, CUSTOMFORWARD and CUSTOMOUTPUT for the filter table.

For NAT table

Use CUSTOMPREROUTING, CUSTOMPOSTROUTING and CUSTOMOUTPUT for the nat table.


I found this here:

1 Like