Her Most Regal Majesty, the Queen of Snark

If it's not accepting incoming traffic, and not logging the rejections, are you actually sure it's receiving traffic at all? (No traffic would certainly explain the symptoms you're describing!)

From:

ssh to my IP address gets "connection refused". Since I have outgoing connectivity I pretty much have to assume the external interface is receiving inbound traffic. Debugging is complicated by the fact I'm using FireHol to abstract the interface to iptables. Manual inspection of the firewall shows nothing I'm not expecting. However I must be missing something.

From:

1) iptables or ipchains?

2) start by logging everything, if you still don't get any log output then either no packets are reaching you or you got the logging rule wrong.

From:

See above. In particular I have:

interface ppp+ internet src not "${UNROUTABLE_IPS}"

        policy drop
        protection strong

        server ident reject with tcp-reset
        server ICMP accept
        server custom cvpn-ka udp/21212 default accept
        server ssh accept

        client all accept

With policy drop, I'd expect "connection timed out" rather than connection refused. So I can only assume that this section isn't being considered applicable for some reason.

From:

Use "watch -n1 iptables -L -n -v" (or something similar) and watch the counters.

From:

OK - now there's something weird. These packets are being trapped by the synflood protection rule.

I never knew about watch. What a phenominally useful command.

From:

I lie. Red herring.

From:

I'd actually prevented ssh from listening on the external interface, so the firewall was functioning fine. *sigh* All of this still fails to explain why the VPN isn't working.

From:

Is that ipfilter? Oooh, don't know that one. :(

I'll second

ewx's suggestion: log everything. Even the packets you're already accepting (ie. the packets that are returned from your outgoing connections). It might show that they're weird in some way, which then affects the stuff that's causing difficulty.

eg. if your upstream hardware is NATting incoming traffic so your machines think it's coming from an unroutable address, you'd probably drop it before anything else (Remember: I don't read ipfilter, so I'm guessing at what the rules mean). Of course, such hardware will cause further problems. But by logging everything you should get some clues.

From:

That's FireHOL, which is converted to iptables rules by a bash shell script. On the plus side, it's easier to read, write, and all the malformed packet attacks are handled automatically. On the minus side, the table rules aren't editted directly. I've been using iptables -vL to follow what rules it's set, but they all look sensible.

Your idea about weird NAT may have something to it, vis.

ppp0      Link encap:Point-to-Point Protocol
          inet addr:213.78.120.250  P-t-P:172.26.131.160  Mask:255.255.255.255

which appears to imply the remote end has NAT weirdness going on, even though my actual IP address is a public IP. TBH, I have no idea what the ISP are up to there.

FireHOL logs packets that don't match any of its rules by default. However, I may be able to set up even more logging, but then I suspect I'll be swamped by info and unable to find the specific bit I need.

From:

If you post up the output of:

ipconfig eth0
iptables -L -nv
iptables -t nat -L -nv
iptables -t mangle -L -nv

I'll have a look through them.

From:

The output of iptables is LOOOOONG (circa 1000 rules). I really don't think you want to do that.

From:

Does your configuration really justify all those rules? Using iptables directly might lead to something that you stand a chance of debugging...

From:

I have been pondering that question myself.

From:

Mine (I've just checked with wc) are 377, 28, 34 lines respectively.
That includes the blank lines between chains (all 50 of them in the first case).

I'm using shorewall to create them.

That covers...
General policy rules: allow outgoing, block incoming etc. (I've actually got three zones, including the firewall as one. So there are 7 policies in total)
Specific overrides: redirect incoming SSH, DNS, SMTP.

And a whole load of "generic" modules that Shorewall creates, to control assorted "standard" options, such as SSH, DNS, SMB, etc. (So the DNS rule mentioned above actually just calls the generic DNS one. Which is two lines long).

1000 lines, for home use, seems excessive!

But possibly the best way to debug it is for somebody to walk through them by hand.

From:

The problem is that I don't trust myself to write good firewall rules. I'm not a firewalling expert and it makes my brain hurt. I can cope with things on the level of "block this port" but I've never been 100% happy with any iptables firewall I've created, because I've never understood iptables well enough to be certain I was blocking what I ought to.

It hasn't helped that I've spend most of yesterday and today chasing a red herring that was nothing to do with the firewalling. I'm not even sure that the problem with the vpn software I use is firewall related either (it's just the most obvious thing that's changed since it stopped working). The vpn software is hand-rolled by technogods, and is thus a complete black box to me, and I have no real clue when it comes to debugging problems with it. All I can do is sit here rather lamely and go "but it doesn't work", and thus earn the derision of said techogod, which I'm not really up to coping with in my current ill state.

From:

Which is not to say I'm ungrateful for the help you and Richard have offered here. On the contrary, I'd have had great difficulty eliminating the firewall as a cause of my oddness without it. Just that I'm somewhat at a loss, since I seem to have no options that don't involve a large amount of work for possibly no benefit and I'm ill dammit, and am therefore having a grump. I honestly hope it doesn't seem like the grump is targetted at you two and apologise if it came over that way.

From:

Nah, it didn't come over as being directed at us :)

Given that I don't use FireHOL, I'm unable to debug it directly. OTOH, I can (or could: I'm rusty) write IPtables directly, so I might be able to tell you what's wrong, if I had the whole set of rules. And then we'd have to work out what FireHOL config was setting that up. Can't think of anything else to usefully suggest without access to the machine :)

From:

timeplease.livejournal.com

The vpn software is hand-rolled by technogods, and is thus a complete black box to me, and I have no real clue when it comes to debugging problems with it.

It's probably a bad idea at this point (as in, don't change things at random until you know what went wrong), but you could try the other hand-rolled vpn software...

In protocol terms it places fewer requirements on a firewall than udptunnel; it only requires UDP connectivity on one fixed (incoming) port and doesn't need ssh, an account on the firewall machine for peer sites, etc.

I believe it's easier to get working than udptunnel, but I expect I'm very biased. Other users might give you a more useful opinion.

From:

That's just the ISP using RFC1918 addresses internally - it doesn't have to imply NAT.

From:

My suggestion about it being NAT was a complete stab in the dark: it would explain why packets were being dropped before being logged. But I suspect it would also stop almost all outgoing connections, as you wouldn't be able to specify the IP address you wanted to target. Sooo broken.

From: