iptables: DNAT from port x to port y
Hi, my linux router is supposed to forward https requests to the http port on my webserver. Is this possible with iptables? I thought that these lines should do (there is more in my iptables script, but I think this is the interesting part): --snip-- $IPTABLES -t nat -A PREROUTING -i eth0 -p tcp -d $routerip --dport 443 -j DNAT --to-destination $webserverip:80 $IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp -d $webserverip --dport 80 -j ACCEPT $IPTABLES -A INPUT -i eth0 -p tcp -d $routerip --dport 443 -j ACCEPT --snip-- But apparently, clients still get forwarded to https, and as there is no https, they run into a timeout. Am I missing something or is this not possible? Regards, Dominik
On Wednesday 04 January 2006 10:59, Dominik Klein wrote:
my linux router is supposed to forward https requests to the http port on my webserver. Is this possible with iptables?
Certainly.
I thought that these lines should do (there is more in my iptables script, but I think this is the interesting part): --snip-- $IPTABLES -t nat -A PREROUTING -i eth0 -p tcp -d $routerip --dport 443 -j DNAT --to-destination $webserverip:80
This is OK
$IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp -d $webserverip --dport 80 -j ACCEPT
This is also OK.
$IPTABLES -A INPUT -i eth0 -p tcp -d $routerip --dport 443 -j ACCEPT
This doesn't matter, because no packet to port 443 will ever come to your router's INPUT table when the DNAT above is set up.
But apparently, clients still get forwarded to https, and as there is no https, they run into a timeout.
The only thing I think could be wrong is the order of rules in a PREROUTING or FORWARD chain. If you match packets by another, earlier rule and decide their fate there, they will never reach your DNAT or FORWARD rules. Try iptables -L -vnx -t nat iptables -L -vnx to see how many packets match your DNAT and FORWARD rules when you try to telnet to router's port 443 from the eth0 interface. If there are none, you are likely matching them before... -- Jure Koren, n.i.
The only thing I think could be wrong is the order of rules in a PREROUTING or FORWARD chain. If you match packets by another, earlier rule and decide their fate there, they will never reach your DNAT or FORWARD rules.
Try
iptables -L -vnx -t nat iptables -L -vnx
to see how many packets match your DNAT and FORWARD rules when you try to telnet to router's port 443 from the eth0 interface. If there are none, you are likely matching them before...
I did that and it looks good. When I start 3 requests, the appropriate rules get 3 more packets. I also did some tethereal observation on the router, the webserver, my local machine and the firewall in between. The router gets the request, PREROUTING changes the DST to what I want it to, FORWARD sends it to the webserver. The webserver gets the request, sends out a SYN-ACK, this is FORWARDed by the router, but it never reaches my firewall and therefor my local machine. So i assume it is some routing that is messed up. Is the following list chronilogically correct? request from $local SRC=$local DST=$router DPORT=443 iptables PREROUTING SRC=$local DST=$web $DPORT=80 iptables FORWARD reply from webserver SRC=$web DST=$local $DPORT=$somehighport iptables FORWARD iptables NAT SRC=$router DST=$local DPORT=$somehighport From what I know, this is how it should and seems to work. So at what point does routing and ip rules come into play here? Thanks for the help, Dominik
Dominik Klein said:
my linux router is supposed to forward https requests to the http port on my webserver.
Why do you want to do this? Even if a https request gets forwarded to http, the client won't get the expected SSL connection. So you're just delaying the error.
this was just a test with ports I know the outgoing firewall I am behind would not block the actual project will use some other ports
Why do you want to do this? Even if a https request gets forwarded to http, the client won't get the expected SSL connection. So you're just delaying the error.
participants (3)
-
Dominik Klein
-
Jure Koren
-
Michel Messerschmidt