freeBSD firewall/ipfw problems

[Gibble]

Aaargh...

I can ssh (and access http) to my server from the internet, but not from my internal network.

Here are my rules

# ipfw show
00050 732928 456908524 divert 8668 ip from any to any via rl0
00100  276  13800 allow ip from any to any via lo0
00200  0   0 deny ip from any to 127.0.0.0/8
00300  0   0 deny ip from 127.0.0.0/8 to any
65000 1433788 911946761 allow ip from any to any
65535  2  419 deny ip from any to any

Help!

If I ssh from an internal machine, I get the login prompt, but after typing a username, I am never asked for a password...

[py9jmas]

I usually stick to ipf rather than ipfw, but I'll give it a shot.

Lines 200 and 300 don't do anything. Any traffic bound to or from 127.0.0.0/8 HAS to go via the loopback interface (lo0). You have already allowed all traffic over lo0 on line 100.

I'm not sure what the divert action does, but it looks like you are diverting all IP traffic coming through the rl0 interface to a divert(4) socket bound to port 8668 (that's from reading the description in the manual).

Line 65000 allows all IP in any direction via any interface - therefore line 65535 which denies all traffic through all interfaces, will never be reached.

What is your network setup? What interfaces does you server have? Does it only have rl0 (Realtek NIC)?

[Gibble]

I have rl0 which is my connection to the internet, and I have vr0 which is my internal nic.

I never set those firewall rules, I just used the default rc.firewall script with firewall_type="OPEN" set in rc.conf...

[MattyMoose]

00050 divert 8668 ip from any to any via rl0
Telling from this, it must be a gateway for your whole network.

What are your NAT rules? Are you forwarding SSH to anything?

What does a tcpdump of your SSH traffic show when you try to connect, and what IP are you trying to connect to? Are you trying to connect to the external IP of the box, or the inside IP when you're ssh from your internal network?

For example:

your box network gateway (inside/outside)
192.168.3.50 -------------> 192.168.3.1/278.234.445.1

Are you trying to SSH to 278.234.445.1 or to 192.168.3.1? Or by hostname, maybe?

[py9jmas]

I've had a look in /etc/rc.firewall, and it looks like line 50 is used for NAT/Internet connection sharing and line 65000 is set to overule the default deny stance in 65535.

Try connecting with

ssh -v [i]hostname[/i]

and see where it hangs. Replace -v with -vv or -vvv if you want lots of detail.

[Gibble]

Yes, it's a gateway for my network.

I've tried to connect through both the internal and external IP addresses.

The only things I have in natd.conf are the following to route ports to the appropriate jails
redirect_port tcp 192.168.0.2:80 80
redirect_port tcp 192.168.0.3:3306 3306

[Gibble]

py9jmas,
I'm connecting through putty from a win2k box...

I don't have another linux box running that I can test that with.

[MattyMoose]

Try adding a hosts entry on your server for your client. I've found that having no DNS resolution for a connecting client can stop SSH cold.

[Gibble]

Ok, i tried adding an entry in the hosts file for the local machine. That didn't help.

I did some reading and added the IPFIREWALL_DEFAULT_TO_ACCEPT option to my kernel config and recompiled. That didn't help.

I did a port scan of the firewall from an internal machine, and it shows only port 22 as being open. (odd that ssh is giving problems.

I did a port scan from an external machine, and it shows ports 22 and 80 as being open. (as it should)

I whittled my firewall rules down to the most insecure I could...

00050 divert 8668 ip from any to any via rl0
65535 allow ip from any to any

And yet, I still can't connect, nor access the webserver from an internal machine.

My guess is it's something to do with the nat divert line in the firewall...but I don't know.

I don't know what to change it to, or what else to try!

[MattyMoose]

Hmmm, I'm not sure where to go from here... The only thing I can suggest is mayb to change the logging levels of sshd in /etc/ssh/sshd_config. Set it to a debug level, and see if SSHD is telling you anything...

Also, do you have access to the console of the machine? If so, do a

tcpdump

for me, and maybe PM the data to me. It may be useful for seeing what it's doing. I've seen this before, or at least very similar problems, but they were all DNS problems.

Is name resolution OK on that server? ie

host google.com

comes up ok?

[Sharper]

Some quick additional questions:

1. Have you tried shutting down ipfw temporarily and seeing if you can connect to confirm that the firewall is actually causing your problem?

2. Is SSH (probably) and httpd (maybe?) configured to listen on your internal IP address and not just the outward facing one? (Check netstat -a ¦ grep LISTEN, also.)

3. Since it sounds like you can't connect to the box at all from your internal network, have you considered routing issues? In other words, could the server be sending it's responses to your internal network requests out through it's external nic?

So, first thing you might try is shutting down ipfw and then seeing if you can even ping the box internally, then connect to a service, etc...

[smithi]

Gibble,

if you've not resolved this yet, I suggest posting to
[e-mail] (you'll most likely want
to subscribe to see responses; start at www.freebsd.org
and follow the link to Mailing Lists). The search
facility is pretty good too, look for 'NAT and SSH'
perhaps, on -questions and maybe freebsd-net.

Provide what you have already, and your freebsd version
(uname -a), your natd.conf, relevant rc.conf options to
IPFW and NAT, and any options that may affect SSH.
`netstat -finet -ran` (routing table) and `ifconfig -a`
may be helpful too.

I'm not doing NAT here, but run a freebsd system with
an extensive firewall, but suspect maybe NAT setup is
more the problem, or PAM. Can you 'ssh localhost' ok?

Anyway, freebsd-questions is your best shot, if you're
not shy about giving plenty of info straight up.

Cheers, Ian

PS take no notice of the suggestion to remove rules
200 and 300 .. you'll get spoofed packets claiming to
be from 127.0.0.1 (mostly on port 80) from your outside
interface with boring regularity.

[Gibble]

Ok, here's what I've done.

I turned the default to accept option on in the kernel (I'll probably turn that back off though)

And I added rule 55.

00050 divert 8668 ip from any to any via rl0
00055 divert 8668 ip from 192.0.0.0/8 to any via vr0
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 allow ip from any to any

Now, I can access the webserver from the internal machine, but my SSH issue still exists. I get a login prompt, and no password prompt.

And yes, I can ssh localhost.

[smithi]

> I turned the default to accept option on in the kernel (I'll probably turn
> that back off though)

Much safer idea, but it's not affecting this. As soon as you've got this
sorted I suggest configuring the 'simple' firewall section ASAP, it's mean
out there and you're wide open, esp with clients in jails and all ..

> And I added rule 55.

> 00050 divert 8668 ip from any to any via rl0
> 00055 divert 8668 ip from 192.0.0.0/8 to any via vr0

No, you don't want translation again on your inside interface ..
and don't you mean 192.168.0.0/16 (RFC 1918 addresses)?

> Now, I can access the webserver from the internal machine, but my SSH issue
> still exists. I get a login prompt, and no password prompt.

> And yes, I can ssh localhost.

Ok, I just noticed something else from an earlier message:

> I'm connecting through putty from a win2k box...

You haven't said whether you're using FreeBSD 4.x or 5.x; if the latter I noticed
something the other day (in freebsd-questions, where I'm sure you'd get this fixed
fast!) about problems with putty and the (new) default SSH settings that required
some reconfiguration of sshd .. off hunting for some details ..

Ok, two partial quotes, out of context, from -questions to give flavour and maybe help:

"There are know issues with ssh2 on earlier versions of Putty.
Try Putty Release 0.56"

and

"Similiar problems have been noted on this list before with putty, the
solution was to set PasswordAuthentication to yes in your sshd_config
which is disabled by default in 5.3"

The first may apply whatever (recent) version of freebsd you're running.

If that doesn't help, consolidate all the info you've given to questions by others
here and take it to where there are scores of people who can help. I suggest:

http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions

try the search facility (say for 'putty sshd' in -questions), it's really quite
good, and you might not even need to subscribe if you're reluctant.

(I just tried exactly that search from http://lists.freebsd.org/pipermail/freebsd-questions/
and got plenty of hits, headed up by the two I quoted bits from)

You might also check natd(8) again and enable -verbose and whatever other switches
will give you some more detailed syslogging of what's going on ..

As I said, I'm not running NAT here, so value my advice for what it cost you :)

cheers, Ian

[Gibble]

Well, I still haven't got it sorted out, I'm using Putty v.56 and FreeBSD 4.11

[smithi]

Well, sorry, but you still haven't asked [e-mail]

Go to the source. It's always worked for me. URLs above.

Best of luck,

Ian

[bcc1234]

If it never asks for a password, it's most likely a DNS problem. Run tcpdump for port 53 while try ing to log in and check if some queries remain unanswered.

Also,

Lines 200 and 300 don't do anything. Any traffic bound to or from 127.0.0.0/8 HAS to go via the loopback interface (lo0). You have already allowed all traffic over lo0 on line 100.

That's the reason why lines 200 and 300 SHOULD BE THERE!
To make sure that only traffic going through the local loop uses that range and that you don't accept any spoofed packets with that range from the outside world.

[Gibble]

I had done a search and this guy had a similar problem...which solved itself ... so didn't help any ...

[lists.freebsd.org...]

It's odd that I can ssh from the local machine, from an external machine, just not a different internal machine.

[Gibble]

Interesting...

I don't know when, or how, but it's fixed and working perfectly.

Très particulier.