dynamic iptables by hostname -- Possible?

[skisteven1]

Hey there.

I'm somewhat new to the whole iptables thing (and linux), so bear with me. I've got a router running dd-wrt custom firmware, which is a minidistro of linux. I'd like to forward a port from external to my server.

When I use the built in GUI interface and add the forward, it just (seems to) add a rule from "anywhere" to 192.168.1.100 dest port 80 on the FORWARD chain.

That works when I do it by hand too. However, if I do something like:
iptables -I FORWARD 8 -p tcp -d ODIN --dport 80 -j ACCEPT

it produces the same rule (even with iptables -L -v) as far as I can tell, but doesn't work. Is it possible to do something like this? I feel like as long as a computer is listed in the /etc/hosts file, it shoudn't be a problem -- and yet it doesn't seem to work.

Thanks

 

[Nothinman]

I don't think so because netfilter is in the kernel so it has no way to resolve hostnames.

 

[Atheus]

Originally posted by: Nothinman
I don't think so because netfilter is in the kernel so it has no way to resolve hostnames.

The iptables command is a userspace program, so it should be able to... not sure though.

skisteven: I assume you're using NAT? If so you need a nat rule as well as the forward accept. Something like:

IPTABLES -A PREROUTING -t nat -i $EXTERNAL_IF -p tcp -d $EXTERNAL_IP --dport 25 -j DNAT --to $INTERNAL_IP:25

 

[Nothinman]

The iptables command is a userspace program, so it should be able to... not sure though.

But the packet filter itself is in the kernel, yes when you run iptables it will resolve hostnames and add the rules with the IPs instead but that's not what he wants.

 

[skisteven1]

Originally posted by: Atheus

Originally posted by: Nothinman
I don't think so because netfilter is in the kernel so it has no way to resolve hostnames.

The iptables command is a userspace program, so it should be able to... not sure though.

skisteven: I assume you're using NAT? If so you need a nat rule as well as the forward accept. Something like:

IPTABLES -A PREROUTING -t nat -i $EXTERNAL_IF -p tcp -d $EXTERNAL_IP --dport 25 -j DNAT --to $INTERNAL_IP:25

I don't think I do. Not for this distro at least. Keep in mind its designed for a router.

Here's the output before I add a rule:

~ # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:1723
ACCEPT gre -- anywhere anywhere
DROP udp -- anywhere anywhere udp dpt:route
DROP udp -- anywhere anywhere udp dpt:route
ACCEPT udp -- anywhere anywhere udp dpt:route
DROP icmp -- anywhere anywhere
DROP igmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
logaccept all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT gre -- 192.168.1.0/24 anywhere
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:1723
ACCEPT all -- anywhere anywhere
logdrop all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
lan2wan all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
TRIGGER all -- anywhere anywhere TRIGGER type:in match:0 relate:0
trigger_out all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere

and here's after i add a rule using the web interface. keep in mind i added it using the IP, not the hostname (odin):

~ # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:1723
ACCEPT gre -- anywhere anywhere
DROP udp -- anywhere anywhere udp dpt:route
DROP udp -- anywhere anywhere udp dpt:route
ACCEPT udp -- anywhere anywhere udp dpt:route
DROP icmp -- anywhere anywhere
DROP igmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
logaccept all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT gre -- 192.168.1.0/24 anywhere
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:1723
ACCEPT all -- anywhere anywhere
logdrop all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
lan2wan all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere ODIN tcp dpt:tproxy
TRIGGER all -- anywhere anywhere TRIGGER type:in match:0 relate:0
trigger_out all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere

So the general consensus is that when I type an IP, it works, but a hostname can't be looked up because it runs in kernel-space? Is there any other way I could set up some sort of alias? I'm even ok with doing static IP's -- I'd just like to be able to refer to them by name instead of number in iptables.

 

[Nothinman]

Is there any other way I could set up some sort of alias? I'm even ok with doing static IP's -- I'd just like to be able to refer to them by name instead of number in iptables.

Just setup a reservation on the DHCP server so that the same IP is always given to that host and ss long as DNS works you can refer to it by name.

 

[skisteven1]

Originally posted by: Nothinman

Is there any other way I could set up some sort of alias? I'm even ok with doing static IP's -- I'd just like to be able to refer to them by name instead of number in iptables.

Just setup a reservation on the DHCP server so that the same IP is always given to that host and ss long as DNS works you can refer to it by name.

I've been trying to do that -- but I'm talking about VPN clients here, who get their IP's directly from pptpd. Sorry if I didn't mention that before.

My eventual goal is to be able to have clients from all over the building VPN into this router, and have ports forwarded to them (for AIM file transfers to the outside world, as an example). I just figure that it's a complete PITA to have to look up the IP for whichever client I want to add a rule for each time. Though, I have noticed that even if I build the rule using the IP, if the hostname is in /etc/hosts, iptables -L will spit out the hostname, for easy reading.

 

[Nothinman]

I would just tell them not to use AIM, you have a central server they can use to share/distribute files, right? Where I work we activally block all IM anyway, we probably don't catch 100% of them but it's against the security policy and most people know better than to distribute corporate files via AOL's network. I mean, what if AOL caches those files and one of their AIM developers or network people goes through your stuff?

 

[skisteven1]

Originally posted by: Nothinman
I would just tell them not to use AIM, you have a central server they can use to share/distribute files, right? Where I work we activally block all IM anyway, we probably don't catch 100% of them but it's against the security policy and most people know better than to distribute corporate files via AOL's network. I mean, what if AOL caches those files and one of their AIM developers or network people goes through your stuff?

Well this is just for my personal use -- but to respond to your point anyway... So far as I know, an AIM file transfer doesn't send any data through an aol server, except to find the other person's IP and nat situation.

Also, AIM was just an example. There's other stuff I'd like to forward around (remote control for winamp, webserver, etc).

Anyway, I guess we've strayed from the original topic, but it seems that it just can't be done. Oh well.

 

[Nothinman]

Well this is just for my personal use -- but to respond to your point anyway... So far as I know, an AIM file transfer doesn't send any data through an aol server, except to find the other person's IP and nat situation.

You're right, I don't know why I was thinking that last night. But the conversations do go through AOL's servers and those can be just as important.

Anyway, I guess we've strayed from the original topic, but it seems that it just can't be done. Oh well.

It can be done, but all of the other solutions are a lot more work than you'd like to invest.