?

Log in

No account? Create an account
Ill. Firewall steadfastly refusing to accept incoming connections,… - Her Most Regal Majesty, the Queen of Snark
void where prohibited, except by law
sesquipedality
sesquipedality
Ill. Firewall steadfastly refusing to accept incoming connections, even when told to. Since it's not logging the rejections, I can't even find out which part of the config is wrong. About to venture out of house in search of honey. Still hoping to be OK for cinema tonight. Illness has apparently caused highly terse writing style.
22 comments or Leave a comment
Comments
wimble From: wimble Date: February 2nd, 2005 04:02 am (UTC) (Link)
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!)
sesquipedality From: sesquipedality Date: February 2nd, 2005 04:23 am (UTC) (Link)
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.
ewx From: ewx Date: February 2nd, 2005 04:21 am (UTC) (Link)

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.


sesquipedality From: sesquipedality Date: February 2nd, 2005 04:27 am (UTC) (Link)
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.
ewx From: ewx Date: February 2nd, 2005 04:35 am (UTC) (Link)
Use "watch -n1 iptables -L -n -v" (or something similar) and watch the counters.
sesquipedality From: sesquipedality Date: February 2nd, 2005 04:55 am (UTC) (Link)
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.
sesquipedality From: sesquipedality Date: February 2nd, 2005 05:06 am (UTC) (Link)
I lie. Red herring.
sesquipedality From: sesquipedality Date: February 2nd, 2005 05:08 am (UTC) (Link)
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.
wimble From: wimble Date: February 2nd, 2005 04:40 am (UTC) (Link)
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.
sesquipedality From: sesquipedality Date: February 2nd, 2005 04:47 am (UTC) (Link)
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.
wimble From: wimble Date: February 2nd, 2005 04:58 am (UTC) (Link)

I'm going to regret this...

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.
sesquipedality From: sesquipedality Date: February 2nd, 2005 05:11 am (UTC) (Link)

Re: I'm going to regret this...

The output of iptables is LOOOOONG (circa 1000 rules). I really don't think you want to do that.
ewx From: ewx Date: February 2nd, 2005 05:15 am (UTC) (Link)

Re: I'm going to regret this...

Does your configuration really justify all those rules? Using iptables directly might lead to something that you stand a chance of debugging...
sesquipedality From: sesquipedality Date: February 2nd, 2005 05:23 am (UTC) (Link)

Re: I'm going to regret this...

I have been pondering that question myself.
wimble From: wimble Date: February 2nd, 2005 05:31 am (UTC) (Link)

Re: I'm going to regret this...

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.
sesquipedality From: sesquipedality Date: February 2nd, 2005 06:10 am (UTC) (Link)

Re: I'm going to regret this...

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.
sesquipedality From: sesquipedality Date: February 2nd, 2005 06:17 am (UTC) (Link)

Re: I'm going to regret this...

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.
wimble From: wimble Date: February 2nd, 2005 06:42 am (UTC) (Link)

Re: I'm going to regret this...

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 :)
timeplease From: timeplease Date: February 2nd, 2005 09:47 am (UTC) (Link)

Re: I'm going to regret this...

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.
ewx From: ewx Date: February 2nd, 2005 05:14 am (UTC) (Link)

P-t-P:172.26.131.160

That's just the ISP using RFC1918 addresses internally - it doesn't have to imply NAT.
wimble From: wimble Date: February 2nd, 2005 05:24 am (UTC) (Link)

Re: P-t-P:172.26.131.160

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.
ewx From: ewx Date: February 2nd, 2005 05:28 am (UTC) (Link)

Re: P-t-P:172.26.131.160

It's a point-to-point connection. There's only one possible next hop for any packet going down it.
22 comments or Leave a comment