I’m almost at the end of my tether on this, I have to be missing something obvious!
I need to make my FTP server available to the internet so I’m forwarding port 21 to my FTP server on my LAN as per the instructions Here and I’ve tried this over and over again hoping I did something wrong last time that I would correct this time and I only ever get failure. The log says DROP_INPUT for every attempt to connect. Scanning port 21 on the public IP address from outside shows it as closed. I’m starting to think that there must’ve been another setting when I originally installed IPFire that said something like “allow port forwarding” or something. I’m migrating from a very old IPCop box that has worked so well for many years so there are a few things that are entirely new to me in IPFire (and a fair bit more complicated).
So the question is, is there something obvious that would be making port forwarding not work?
I know I haven’t put in all the details of my setup but I thought I’d ask for obvious answers first as this is becoming such an epic PITA that if someone else encountered it, they’re sure to remember it.
Are you sure you’ve got an public ip that can be used to directly reach your modem. Also your modem/router or whatever is connected to your WAN/RED interface is listening to the ftp ports?
Did you apply the rule and do you find it in iptables?
Thanks for the quick response, I’m now thinking that the ISP has given me a router with restricted ports because I’ve just tried to redirect a port that I’m using for a VPN on the same connection and that’s not working either. I’ll have to call them in the morning. Thanks for the idea.
I didn’t look in the iptables, does it sometimes not appear there or is that just to check that it has been applied?
And maybe you have something like DSLite and won’t even be able to reach your router at all. Check your ISP IP. If it’s not an public IP you’re busted.
It will be just to check that the rules have been set.
It’s a 100Mb fibre line so I don’t think that’s a problem. When the router was installed it was named with another customer’s name so it was clearly a previously used one so there may be some non–standard settings on it.
One thing I thought of though, if the log is saying DROP_INPUT for the IP address that I’m attempting to connect using, then the IPFire box is seeing the attempt, so the router can’t be blocking it. Can it?
If you get DROP_INPUT Logs the Packets reach the firewall. So I don’t think its an Issue of your ISP. Could you post a screenshot of your rule?
Here are the screenshots:
A very stupid question i know but did you click the apply changes Button on the first screenshot?
Yes, I noticed that in the screenshot, but that was just because I’d changed the description, the rule had already been there.
Could you please post the log where the packets are dropped? Have you changed something in the “firewall options” (Firewall -> firewalloptons ) ?
Please excuse this, but are you sure about passiv and active FTP ??
Here’s the log entry and below it is the options page:
Hi, I’m not sure what you mean about passive and active FTP.
active FTP can only be used if the client (has an public IP and) is not firewalled. to get rid of this issue you can use passive FTP, but then your server must open the ports in the firewall for the client.
No. This is not correct. 37686 is the source port of the connection which is don’t care for this firewall rule. Please post a full log line from /var/log/messages. Maybee there is something that points why this was not redirected.
Please check the return in the terminal:
iptables -L | grep 192.168.1.49
If you get your rule.
ACCEPT tcp – anywhere 192.168.1.49 tcp dpt:http
ACCEPT tcp – anywhere 192.168.1.49 tcp dpt:ftp
OK, something’s changed, I’m now getting “DNAT IN” showing on the log. It’s not actually working though - still getting the same failure.
I changed something in the firewall rule settings to match what was working in the IPCop setup (I think it’s because I have multiple IP address aliases): I’ve added the alias that I want to use to the Firewall Interface option in the NAT section of the firewall rule.
This change appears to have got me beyond the original DROP_INPUT response, but not to something that’s working.
I’ve also set up a web server to point at the same place but I’m getting the same result, but I’ve put another rule in there for a Minecraft server (port 25565) and that’s working fine.
Here’s the iptables entry for that:
ACCEPT tcp – anywhere 192.168.1.9 tcp dpt:25565
The log entry for the FTP attempt is here:
Feb 4 16:21:59 PECS-FW1 kernel: DNAT IN=red0 OUT= MAC=8c:89:a5:20:b9:89:70:35:09:a8:dd:d0:08:00 SRC=188.8.131.52 DST=184.108.40.206 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=6021 DF PROTO=TCP SPT=36256 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
I was thinking that this may be something on the server itself that’s the problem, but I still have the IPCop firewall pointing at it (the same physical server’s NIC) with both ports 21 and 80 working fine.
Sorry about the wall of text and thanks for reading it (if you have, of course)
Now with the correct DNAT in log its time for more tests.
Try to disable the “ftp - Application Layer Gateway”. This in nornal for outgoing ftp connections but it may mess up the incoming packets.
I set the ftp option in Application Layer Gateway to off and tried again. I got pretty much the same log entry (although I just noticed that I sent the port 80 log entry last time):
Feb 8 11:53:06 PECS-FW1 kernel: DNAT IN=red0 OUT= MAC=8c:89:a5:20:b9:89:70:35:09:a8:dd:d0:08:00 SRC=220.127.116.11 DST=18.104.22.168 LEN=52 TOS=0x00 PREC=0x00 TTL=122 ID=23812 DF PROTO=TCP SPT=59391 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0