Webserver / Email behind firewall, need Samba access from clients behind same. Eh.

June 30, 2006 10:55 PM

Home Network Madness - why doesn't this layout work? RRRRRGH. Thanks in advance.

Why doesn't this work?



The Linux server running SME 7.0rc3 (www.contribs.org) is set up as a gateway that thinks it's talking directly to the internet because I can't get port forwarding to work on the router, so I'm copping out to DMZ. OK, so that's my fault, and I'll keep trouble-shooting. In the meantime, I'd like to be able to set up Samba shares on the internal network for ease of uploading / file transfer / email checking from other clients on the 192.168.2.x subnet.

So. Why can't the internal and external NICs on the Linux box be on the same subnet? Anyone? All the internet traffic is pointed (by the router) to the .150 IP address, so external port 80 requests and such should go straight through to it. I can't get local Samba requests to point to the .160, and when I have them both plugged in the server stops serving traffic on either nic.

So, maybe I'm just a moron. What (apart from "learn to freaking port forward properly on your router and use a single NIC, loser") can I do to get this working? Or is that pretty much it?

Thanks.

-Zak-

posted by ZakDaddy to computers & internet (16 comments total)

Why does your Linux box have 2 NICs?
posted by Jairus at 10:59 PM on June 30, 2006

...or why don't you just plug the Linux box directly into the modem on NIC 1, and then plug the router onto NIC 2? Is there something I'm missing?
posted by Jairus at 11:03 PM on June 30, 2006

Dual NICs can work, but they won't buy you much performance in this setup, and they'll vastly complicate your routing issues, maybe beyond what your D-Link is capable of understanding. VLANs might be useful to help it, if it supports VLANs, and you are doing service isolation via port forwarding. Make sure you're flashed to latest firmware, but the software specs didn't specifically mention VLAN support. Also, be aware that most SOHO routers with a DMZ feature will only port forward to a single internal address, so if you run Web and mail servers on your box, you'll probably have to port forward these ports to the same NIC, anyway.

If your router is VLAN capable, and you want to use VLANs put your "external" NIC in something like 192.168.100.x VLAN, your "internal" NIC in 192.168.101.x VLAN, and your Wireless boxes in 192.168.102.x VLAN, and your router won't have problems with loops. Adjust entries for eth0 and eth1 on your Linux box accordingly. You may have to reboot router to rebuild routing tables after doing this. But if your router doesn't support VLANs, dump the dual NIC, to avoid loops.

Can you ping both Linux NICs from any of your wireless boxes? If not, can you ping either Linux NIC from the other, on the same box? How do you know the NICs are both bound and working?
posted by paulsc at 11:27 PM on June 30, 2006

the linux box has one nic set up as a gateway? is it trying to route traffic? if it is, it's confusing your d-link router and probably itself too. I think they should both be able to get network settings via dhcp and the DMZ you've got running should sort things out - no need to turn on ip forwarding or anything of that nature on the server box at all. then you just bind Samba to eth1 so that it's not exposed through the DMZ. I'd be curious to see why the port forwarding doesn't work too, just to make sure your router isn't too horribly braindead. (the last d-link I had was pretty braindead, and is the reason I won't buy any more d-link networking products.)
posted by mrg at 11:46 PM on June 30, 2006

Once you have port forwarding figured out, there will be no need for all of this, so I'm not sure what you're trying to accomplish

If you really want to have this work with DMZ, ditch the DHCP client on the server, and assign the card two seperate IP addresses, then bind samba to the not-DMZ'd IP address... no need for two ethernet cards.
posted by hatsix at 12:09 AM on July 1, 2006

"So. Why can't the internal and external NICs on the Linux box be on the same subnet?"

They can - but it's vastly easier on your brain if they're not ;-)

I'm not familiar with the particular router in question, but consumer routers usually require the DMZ to be a different subnet for just this reason - it makes routing a whole lot easier (for them).

Another clue : "... and when I have them both plugged in the server stops serving traffic on either nic". This suggests that the subnetting / routing tables on either your Linux box or the router are wrong - the netmask on the Linux box should be 255.255.0.0 for both NICs, and the same for the separate LAN & DMZ subnets on the router.

If this is the case, without any further routing tables or metrics, I suspect that neither the router or the Linux box know which interface to use for the packets (".160? .150? Oooh, my brain hurts!"). Either are just as likely to send on one and wait for the receive on the other. And, with both doing that ...
posted by Pinback at 12:10 AM on July 1, 2006

I will give you the same advice I give everybody who is having trouble getting IP networking to work. Install Ethereal on everything, do some packet traces, and find out which box is actually eating them. It just takes all the guesswork out of the job.

You show the 192.168.2.0/24 subnet being used for both wired and wireless; make sure your router can actually do that. You may need to use separate subnets for those - they are, after all, physically distinct networks.

Other than that: what Jairus said. Plug your modem into your Linux box's external NIC, leaving your router's WAN-side interface unused. Set up the Linux box's routing table to make everything for 192.168.2.0/24 (and 192.168.3.0/24, if wireless does in fact need its own subnet) go out via the internal NIC, and make the modem the default gateway.

Use iptables (or whatever GUI frontend you favour for iptables) to make the Linux box into your firewall and port forwarder; that way you don't have to deal with the typically-even-more-arcane router firmware. All you have to tell the router (which you can leave in charge of DHCP if you like) is that 192.168.2.160 is the default gateway.
posted by flabdablet at 12:10 AM on July 1, 2006

- the netmask on the Linux box should be 255.255.0.0 for both NICs, and the same for the separate LAN & DMZ subnets on the router.

Scratch that - my brain's not working properly! There's some truth in what I said there but, at the moment, I can't figure out what it is, or what I mean...
posted by Pinback at 12:18 AM on July 1, 2006

Is the goal here to have "trusted" traffic on .160 and "internet" traffic on .150? I think Jairus is on the right track. I would set up the Linux box to masquerade and arrange the network like:

Cable Modem --- ext Linux int --- Wireless Router === Other Machines

Then bind the webserver and mailserver to the external interface (and optionally the internal one), and Samba to only the internal one. Make sure that only the ports you want are open on the Linux box (nmap is your friend), and the Linux box will act as your firewall and NAT.

That's what I do on my home network
posted by aneel at 12:20 AM on July 1, 2006

I just wanted to add that a samba server running on a DMZ is 100% batshitinsane. That is, unless you want some stranger from the internet downloading all the files on all your shares.
posted by Rhomboid at 12:21 AM on July 1, 2006

...and, potentially, uploading god-knows-what to all your Windows folders...
posted by flabdablet at 12:43 AM on July 1, 2006

I think all you need to enable NAT would be:

net-facing interface: eth0
net-facing ip address: 70.86.84.162

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 70.86.84.162

maybe a modprobe or two is also necessary, I don't recall. Then your network looks like:

cable modem -> eth0 - linux server - eth1 -> router -> 192 net
posted by beerbajay at 2:01 AM on July 1, 2006

This is all great stuff; as soon as I get home tomorrow I'll start trying bits and pieces and let you know how it all works out.

Jairus:
Why not use the Linux box as my gateway? Because a memory leak of some sort causes the box to lock up every couple of days when I'm pushing Bittorrent packets through it. The D-Link handles that sort of traffic much better.

Paulsc:
VLANs would definitely simplify this. I'm pretty sure that option's not available to me from this hardware, more's the pity.

Pinback:
You may have it. Being the not-very-good-at-IP-stuff guy that I am, I don't understand what subnet mask does. So, everything's set to 255.255.255.0, because that usually works fine at my house. Looks like I have some reading to do.

Flabdablet:
OK, I'll be downloading that first thing to start sniffing stuff out. Thanks!

Everybody:

Let me make clear - the Samba server is only available from the internal NIC on the Linux box (.160, not in the DMZ). The external nic on the Linux box thinks it's connected directly to the internet, and all the firewalling stuff is active. Internal network services such as Samba etc. are not available on the external (.150) nic.

Thanks for taking the time to share your insight. I expect this all to be quite helpful. I'll follow up on this as soon as I have news.

-Zak-
posted by ZakDaddy at 9:21 AM on July 3, 2006

You definitely need to understand netmasks if you're going to have any hope of setting up an IP network.

Background

An IP address is actually two different things shoehorned into a convenient 32-bit package: a subnet address and a host address.

Network interfaces that can talk to each other directly (i.e. are wired such that interface A spits out a packet and interface B sees it, without the involvement of a router) share the same subnet address.

The host address is what distinguishes the different interfaces residing on a given subnet from each other.

When a router receives an IP packet, it compares the destination IP address with the IP address of the interface that the packet arrived on. If both of these addresses contain the same subnet address, the router assumes that the packet has also already been seen by its intended target, and simply discards it. If they don't, the router consults an internal table to find out which of its other interfaces to retransmit the packet on. If it doesn't have a specific table entry for that particular subnet, it will retransmit the packet on the interface connected to its default gateway, thereby making that packet some other router's problem. That's the essence of the Internet, right there.

Netmasks

What a netmask does is specify which bits within the IP address are subnet address bits, and which are host address bits. IP address bits whose corresponding netmask bits are 1 are part of the subnet address; those whose corresponding netmask bits are 0 are part of the host address.

In the conventional representation of IP addresses - four decimal numbers separated by dots - each of those numbers corresponds to one byte (8 bits) of the address. For example, here are some numbers in dotted-decimal notation converted to 32-bit binary values:

192.168.2.77  = 11000000 10101000 00000010 01001101
255.255.255.0 = 11111111 11111111 11111111 00000000
255.255.254.0 = 11111111 11111111 11111110 00000000
255.255.240.0 = 11111111 11111111 11110000 00000000

The last three of these are valid patterns for netmasks.

So if, for example, you're looking at an address of 192.168.2.77 with a subnet mask of 255.255.255.0, then the subnet address would be 192.168.2 and the host address would be 77.

Sometimes you'll see things that look like this: 192.168.2.0/24. The 24 in this case is a short-hand description of the netmask: it means that the mask consists of 24 1-bits followed by 8 0-bits, and is exactly equivalent to 255.255.255.0. This shorthand works because all netmasks consist of some number of 1-bits, padded to the right with zeroes.

Gotchas

There are some reserved subnet and host address codings. All-zeroes in either subfield means "any"; all-ones means "all" (broadcast). You should avoid assigning those codings to real devices.

There is no requirement for the ones-to-zeroes transition within a netmask to occur on an 8-bit boundary! So you'll see stuff like 10.129.176.0/20 - this means that the left-hand 20 bits of the IP address are subnet address bits, and the right-hand 12 are host address bits; there's room for 4094 hosts on this subnet (plus the reserved "any" and "all" host address codings).

In this case, the local broadcast address would not be 10.129.176.255, but 10.129.191.255. To see why, let's put those numbers back in binary, with the subnet address field highlighted:

10.129.176.0   = 00001010 10000001 10110000 00000000
10.129.176.255 = 00001010 10000001 10110000 11111111
10.129.191.255 = 00001010 10000001 10111111 11111111

All these IP addresses share the same subnet address; only in the last case does the host address have the all-ones coding that denotes a broadcast address.

Hope this helps.
posted by flabdablet at 5:10 PM on July 3, 2006

What might be happening on your network that stops it working is something like this:

1. Laptop sends SMB request to Linux box on 192.168.2.160.

2. Internal NIC or routing table or both on Linux box are misconfigured, so Linux box doesn't realize that it's supposed to handle that packet internally, and instead sends it off to the default gateway. This transmission goes out on the external NIC.

3. Because the two NICs are actually connected to each other via the switch in the D-Link box, the retransmitted packet arrives again on the internal NIC.

4. Steps 2 and 3 repeat until the hop count field in the packet runs out, at which point it's discarded.

The net effect is that nobody ever responds to packets sent to 192.168.2.160.

Anyway, Ethereal will definitely show you what's going on. Just make sure to install it everywhere you possibly can, and make sure everybody's real-time clocks are reasonably in sync so you can cross-correlate packet traces; the switch inside your router is going to do its best to confuse you by not delivering certain packets to certain ports.
posted by flabdablet at 5:26 PM on July 3, 2006

Step 3 is arse. The Linux box's packet to the default gateway would be directed to the router's MAC address, so it wouldn't be switched back to the Linux box's internal NIC. But it might be routed back there (because the destination subnet matches) or it might just be dropped (because it comes into the router from an interface with the same subnet as the destination).
posted by flabdablet at 6:58 PM on July 3, 2006