TR Forums

Well, I had to leave the office at noon and had to bring the old firewall back online since the new one was not fully unkinked.

notfred wrote:

From earlier in the thread

notfred wrote:

You also seem to be missing a "-A POSTROUTING -o eth1 -j MASQUERADE" line from the end of your NAT table.

Did you fix that?

Yes, I had that rule in place. Thanks for checking though.

So many thanks you you for sticking with me notfred. I would so, so, so love to buy you some beers for all your help and maybe one day I'll get to - who knows.

The only thing not working with the firewall at this point is masquerading. I'm not going to give up until it works. It's pretty weird, but this is both the most determined I've been with Linux and the most unsuccessful. I've thrown more time at this than seems reasonable, but if this knowledge and experience remains useful for the next 10 years then it will easily have been worth it. I'm also far more capable with Linux than ever before.

I've got a Dell Poweredge 310 on the way with a quad core Xeon - way, way, way overpowered for the job it's going to be doing but it was a necessary purchase. We have a 42U rack with all of our servers in it and a 180AS console switch. I was using an old spare Optiplex with pfSense for the firewall and another old spare Optiplex for FTP and yet another old spare optiplex for network backups and then an ANCIENT Buffalo terrastation as our NAS. The plan is for the new PowerEdge to take the place of all of those. The Optiplex boxes did not work with the 180AS and they also have some capacitors going bad. The PowerEdge servers are pretty darn well built - not a single one that we have is having any problem what so ever after years of service. So the PowerEdge 310 is going to consolidate several functions into one machine, work with the 180AS, be long term reliable, has 4 hot-swap drive bays.

So that's the plan. I figure that when the server arrives I'll do a fresh install and fresh configuration of iptables and hopefully everything will work. If not I'll be sweating bullets In the mean time, I'm going to continue battling this problem until I get it resolved. It's just masquerading. It has to be fixable. I'll be back at it again tomorrow morning.

Yeah, masquerading shouldn't be too hard to get to work. Thoughts on this:
1) It's not the client default gateway issue that you mentioned before is it?
2) If ping is working but http isn't, I wonder if it might be getting messed up by the port forwarding you have for the http from outside to inside - it shouldn't but it may be a misconfiguration somewhere. Have you tried other protocols that you don't have a port forward for and see if those work?

Take a look at my iptables.save that I posted on the previous page again - I set it up many years ago and it's been solid through OS upgrades ever since with just the occasional tweak for forwarding a new port. It might help if you also post your latest set of iptables.save. One thing I have used for debugging things in the past is the counters on the various sections of iptables. If you can quiesce the rest of the network traffic so those counters are not incrementing and then send the traffic of interest (e.g. try accessing a web page) and then dump the counters again and see which ones have changed then it can tell you a bit about where iptables is classifying your traffic.

Big, big progress.

Everything is working.

I think the thing that was holding up masquerading is this rule that I had in the nat PREROUTING chain - which gets processed first:
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination x.x.x.x

So, masquerading was working, but the http reply was getting caught by the prerouting. I think what I need to do to the above rule is add a --state NEW to it and then it should allow me to port forward NEW http connections while leaving unrelated packets alone - I think?

And I like - not quite EVERYTHING is working - FTP directory listing is not working. I can change FTP directories just fine, but cannot list any directory contents. That is particularly weird. I wonder if there is some kind of issue with Fire FTP and the firewall. Dunno. I'm planning on moving FTP service to the firewall/gateway machine anyway, but I'd really like to get this working.

Progress, progress, progress, but I've fought for every inch of it

FTP requires two independent connections: the control connection (by default, port 21) an the data connection (usually a random port in the high range). You have to let both through the firewall. The reason why you can ask for a directory listing but then get no response is because the control connection is being forwarded properly, but the data connection isn't.

morphine wrote:

FTP requires two independent connections: the control connection (by default, port 21) an the data connection (usually a random port in the high range). You have to let both through the firewall. The reason why you can ask for a directory listing but then get no response is because the control connection is being forwarded properly, but the data connection isn't.

Set your FTP client to passive mode and this should go away.

--SS

The FTP helper should help iptables understand the FTP protocol though and not require passive mode.

notfred wrote:

The FTP helper should help iptables understand the FTP protocol though and not require passive mode.

That's my understanding. However, I think I forgot to do "modprobe ip_conntrack_ftp". I was all set to do that this morning but I did a quick check again with an FTP client and now I'm getting directory listings! I haven't had much time to play with it yet today.

It depends on the client, some may default to passive.

FTP is working fine now. I added ip_conntrack_ftp and I also did:
-A INPUT -p tcp --dport 21 -j ACCEPT

and now all is well.

For some reason I thought the FTP helper was supposed to make opening port 21 input unnecessary, but apparently that is not true.

Apple Mail is fail without port 25. I had intended to leave 25 closed to inbound traffic and let email clients use 587 instead. I'm not sure if it really matters. The only thing I'm trying to do is force email clients coming from the outside to use SSL. Now, Thunderbird has absolutely no problem. Apple Mail gets messages but cannot seem to send them.

Here's the current version with IPs replaced by x.x.x.x:

Secure SMTP (SMTP+SSL) is port 465, not 25. Might want to try that.

morphine wrote:

Secure SMTP (SMTP+SSL) is port 465, not 25. Might want to try that.

That's was in there too. Apple Mail seems to strongly prefer port 25. A custom port can be set in the Apple Mail preferences and I tried that the other day but it did not work. And again, Thunderbird gets through without a single issue or complaint. This seems to be an Apple Mail issue.

Yeah, sorry, replied before really reading the info heh.