I have just replaced my failing firewall hardware with a HP t620 thin client box loaded with the restore ISO from my previous firewall, so it’s at IPFire 2.29 (x86_64) - Core-Update 184 with all the previous rules and configuration of the old one. But what doesn’t work now is the hairpin;
previously I could interrogate my internal email server and webserver, by addressing the external interface and the correct ports.
All IPv4s are the same and correct. Other machines on the internet can reach my internal webserver/email, just not me…
None technical possibility.
Go to firewall rule page etc.
Click save and reboot?
Thanks, have done so three times. Have tried deleting/rebuilding one of the rules (port 80) to see if I can get just that one to work. All the same.
It’s like when I originally installed the IPFire 6 years ago there was something different about it’s config, that doesn’t get transferred.
Next I plan to to a Meld directory comparison of the /etc of both boxes, see if there is such a difference.
No, there is not any substantial difference. The difference between old and new is the style and substance of the comments heading each file. I am baffled.
Hi @onyxnz.
One question, Do requests reach IPFire? Hasn’t the ISP Operator put you in a CGNAT?
A simple test. Do you have the old IPFire? If so, try putting it back in to see if it works. (removes suspicions from the ISP).
Health.
1 Like
Yes, the requests are logged in the firewall. eg
Which shows my laptop trying to send packets to my email server.
The ISP has given us a static dedicated IPv4 address, which is also Reverse DNS locked to our home domain.
The old IPfire has stopped working as it was a crusty old i7 laptop, but it’s fan died. I can however interrogate it’s OS harddisk, and access the system that way. Using that I have checked the /etc config files.
I’ve checked again the docs : www.ipfire.org - Creating a Port-Forward Rule
To which network do belong 10.0.2.36 and 10.0.2.19?
For connections on green0 you do not need a port forward rule.
To the LAN (green) where the laptops and server reside. Yes, I realise that I don’t need to have the port forward in that instance. But the fact is that they are laptops that frequently leave home, and need to retrieve email when outside the network, without having to alter Thunderbird in order to fix the couple of dozen accounts; particularly on my wife’s machine.
So I am going to try a DNS fudge next; rewrite the domains when inside GREEN so that they get the internal server(s) (3 proxmox vms) rather than resolving to our external (RED) interface.
Perhaps silly, but did you update the MAC address entries as you changed hardware?
1 Like
From outside 10.0.2.19 isn’t reachable. To fetch your mail you must connect to REDIP:110. The port forward transfer the request to the mail server on 10.0.2.19.
1 Like
Nothing’s silly…except me… but no, I’ve not played with MAC addressing; didn’t even realise I could until now.
I checked my own hairpin and the IPFire NIC’s are not really involved there, so perhaps not very relevant, but then again, I have learned that there seems to be not only one way to do things.
1 Like
Ok, as @sec-con alludes to; more than one way to skin this puddy-tat.
By adding my domains as hosts, and then forcing my network connection to use DNS of the ipfire first, I have forced the resolution of the domains to be the local 10.0.2.x range and this works; bypassing the hair-pinning altogether.
I just need to then alter the wifey’s laptop to replicate that singular network connection change, and all will be well in the world again.
Thanks for humouring me, guys.
2 Likes
UPDATE:
Thunderbird has been having sync issues with some accounts, randomly retrieving 1100+ emails again after each connect with this method of swapping to the lan IP internally. Very frustrating for the Mrs, who was facing this every day.
This morning I saw a new version in Pakfire, 185. So applied it, and had to SSH in to reboot, otherwise the web interface wasn’t available. No biggie.
Then, for giggles, I turned off the hosts that controlled the internal lan redirections, to see if anything had suddenly come in to line with hairpinning. LO AND BEHOLD! Hairpinning now works, the same way that it used to on the old hardware. And Tbird is not getting confused either!