No internal working pinholes after .194? rebuild to 195 hasn't fixed either?

Networking
1

Hi Guys,

My IPFire is configured like:

IPFproblem1
IPFproblem1252Ă—185 9.13 KB

Since the .194 upgrade it is behaving very strangely!

For many months, I have simply upgraded IPfire from the gui,
all has been ok , there have been no changes to the rulesets.

since .194:

North to South Port forwards work 100%
East to South pinholes do not work at all
East to West pinholes do not work at all
Open vpn to green works, as does openvpn to orange.
But unfortunately services running in orange rely on a NAS
located south (in green) and dedicated CIFS rules are simply being ignored
.
I took a backup before the 193-194 upgrade and have reloaded it to rule out a potential config corruption - no change.

I have rebooted several times in my testing…no change

I have disabled the rules, applied the changes, re-applied the rules , applied the changes. STILL not fixed

So I have taken a further backup and will swap out the disks, reburn a fresh iso to CD, and reload the config file.

However, i would prefer not to if anyone has any suggestions? but for me, I am out of ideas!

Additionally (and I suspect its not related but in the name of completeness) I have a P2P openVPN connection with a client that has 2 subnets at the far end (Subnet 2 is an unused fixed WAN that I recycled as a hardwired Client side DMZ)

I couldn’t route from anywhere inside to the client DMZ until I added a static route into the GUI. (perfectly reasonable!) and now I can manage the client side DMZ from green or blue with no issues.

However, why, when I access the shell as root and perform netstat -rn, is there no sign of that static route in the routing table ? nor is there anything that points the client DMZ subnet as reachable via TUN1?

Grateful for any help as I have reached the “stuff it! rebuild this pig from scratch!” point

regards

BB

2

so this evening I installed 2 new blank HDDS, built .195 from the ISO configured the NICS and reloaded the configuration from 194…and…it has not worked :face_vomiting:

Still no east to west / west to east pinhole traffic

I know it HAS to be the firewall as its not only affecting CIFS traffic but sources streaming to an icecast2 server in orange from clients in green (they cannot connect either)

so it could be that I have reloaded a crappy config but other than wipe it out completely and rebuild the entire rule base from scratch I am at a loss again - really hoped this would solve it.

I do see lots of contrack error logs (drop_CTINVALID) reflecting the firewall is doing something but still trying to drill down through them (theres a LOT of traffic)

regards

BB

3

Two little questions

  • could you explain your system more in detail, please?
  • why do you want to install CU149? This version is years old.!
4

My sincere apologies Bernhard!

148 should have read 194, and 149 should have read 195.

I have gone up through the previous messages and made the appropriate corrections (Hope I haven’t missed any ?) .

No Idea how that happened (!) - I can only blame my Neurodiversity! :blush:

for absolute clarity (!) I am currently at:

IPFire version IPFire 2.29 (x86_64) - core195
Pakfire version 2.29-x86_64
Kernel version Linux 6.12.23-ipfire #1 SMP PREEMPT_DYNAMIC Mon Jun 16 13:54:53 GMT 2025 x86_64 GNU/Linux

My system is presently an HP DL360 G5, dual xeon with 14gb of RAM

The IPFIRE ruleset config has not changed between .192 and .195

I have a small VM farm on orange running audio / telephony services and a webserver.

On green, I have a NAS

I have created services and 2 service groups (one ROIP group for ICECAST2 one CIFS group encompassing 137-139 and 445). All have been running flawlessly since before .192

The web server on orange has a read only account on the NAS to pick up its content via CIFS. Similarly, the media server too runs on orange and uses CIFS to access its content.

I noticed that the webserver was running but was serving me “404s” , when I checked the mounted folder for the content, it was not there.

I performed the usual “mount everything in fstab” command and was told “host was down” …well…the host is very much up! and I can access the CIFS service from green with no issue.

I then noticed that my internal media streaming server was also running on an adjacent VM in orange , but it too could not access its mounted share on the NAS.

At this point I went down the rabbit hole of looking at CIFS issues.. but in all honesty nothing has changed.

It was then I noticed that my other audio sources in green (Icecast clients) were not connecting to my icecast2 server in orange. this was a completely different server and service group. I was no longer looking at just a CIFS issue - this was a wider Orange <> Green / blue< >orange issue.

This evening, as I said above, I took two new blank disks and reloaded ipfire using the .195 iso. I configured the NICs, then reloaded the .194 config hoping this would fix the issue. It did not.

I still see lots of conn-track related errors in the logs when viewed from the shell like:

[ 4108.991893] DROP_CTINVALID IN=green0 OUT=orange0 MAC=: SRC= DST= LEN=40

but am only now slowly working my way though the “pile of data” generated, but since nothing has actually changed since .192, I am at a loss as to why this issue has arisen.

I’m going to do another 45 minutes on it all tonight , but then I must be up for work in 6 hours so sleep is needed!

Apologies once again for the confusion I generated !

regards

BB

5

Morning all

In the very small hours of this morning, I looked again at the rule the icecast clients used for green to orange transitions to the icecast2 server. as these seemed to be the main events in the log throwing up conntrack events in the logs due to their traffic flows

its a very simple rule:

from group [Icecast Client PCs]
to host [streaming box]
protocol tcp
port 8000
allow

Syn flood protection was turned on.

Seeing nothing wrong, I made one change , I turned off syn flood protection (which is on for every TCP rule in my firewall and has been since day 1)

As soon as I clicked apply, all 4 icecast clients immediately connected! as soon as their 10 second retry timer kicked in.

Somewhat puzzled by this, but intrigued, I repeated the process for each of the CIFS rules in turn and applied the changes to each one.

No sign of CIFS availability initially, but I then went into each CIFS client host in turn . and did a further sudo mount -a or a systemctl daemon-reload (according to the needs of the OS)

and everything CIFS mounted immediately

By then it was way too late to be focussed so I left it.

And this morning everything still appears to be working?!

I am composing this reply in a text file en route to work , streaming media over OpenVPN from the servers, which are pulling content from green via CIFS so its still working.

Tonight I will re-apply the syn flood protection to each rule in turn and see if this re-creates the problem.

To reiterate - Syn flood protection has been enabled on EVERY TCP rule since I migrated from IPCOP back in the day! and nothing changed between .192 and .195 in the firewall config.

The only configuration that changed in the .191 era was adding a P2P OpenVPN connection. so everything has been in place for a VERY long time.

So…I am relieved to have an apparent resolution, but cannot yet confirm the root cause.

regards

the tired, frustrated but relieved

BB

6

Synflood protection was only added to IPFire in CU187.

However the issue you are describing has been identified in this forum posting.
https://community.ipfire.org/t/syn-flood-protection-activates-automatically/13295

It means that somewhere along the way you created a rule with synflood protection enabled (maybe for a test) as the default setting is disabled. If the rule that was created or edited was not at the end of the rule list but part way along, then if that rule was then deleted the last rule in the list gets the synflood protection turned on. One of the posters in the forum thread link above also ended up with all or most of his rules with synflood protection turned on.

There is also a workaround description in the post thread for how to clear out all the synflood protections.

A bug report has been raised on this.
https://bugzilla.ipfire.org/show_bug.cgi?id=13854

2 Likes