thebeardedone
New Around Here
G'day folks.
Am at that point where a week of google-fu and haphazardly going from "iptables policy that makes sense" to "this doesnt make sense, but maybe it'll work", have to throw my hands up and ask for help
My situation:
{Works}
-ASUSWRT-Merlin RT-N66U_3.0.0.4
-cheapy Comcast Business modem (SMC) goes to N66U (obviously), goes to cheapy but good 8-port Asus Gbit switch, servers wired into switch.
-a static /29 block from my ISP (4 for my servers, one for my N66U
-a 1-to-1 NAT setup via iptables SNAT/DNAT
-all hosts on the LAN, whether wired or wireless, can communicate with each other via the private IP (e.g. both wired and wireless clients can connect => 192.168.1.25:25 on the mail server)
-all hosts outside my LAN (e.g. everyone else on the interwebs) can connect to my servers as intended
-for our purposes here, x.x.x.88 is the network address, x.x.x.94 the gateway, x.x.x.95 the broadcast, x.x.x.90 is the N66U, and x.x.x.89 and x.x.x.91-93 are my usable IPs (my servers)
{Buggered}
-from within my LAN, I can't connect to these hosts via their public IP
-it's as though server receives request from client, but server's response never makes it back. Specifically:
telnet from my laptop (192.168.1.142) => mail server (x.x.x.92:25), I see:
....so, it sees the N66U's br0 IP, and neither the client's private nor public IP
I pop into asuswrt-merlin via ssh, and do nc x.x.x.92:25 and it's a "connection refused"
Perhaps relevant, .91 is my web server, and nc x.x.x.91:80 yields:
Hrmm...that should be hitting my web server, not the httpd on my Merlin box.
Now some background, I did have this functional on a DD-WRT system before. I say that not for blame's sake (because, well, this is obviously user error!), but because I can't get my head around why the gander is so opposed to the goose's sauce.
My old ddwrt setup that worked, was a simple little:
Simple enough. After a bit of wrangling, I managed to port these over into nat-start and firewall-start scripts.
{nat-start}
{firewall-start}
This accomplishes the goal of opening up these servers to folks in the outside world. That part is good to go.
But of course, no connectivity from within my LAN.
Hate throwing my hands up and saying "HALP!", but I'm at that point. I've been firing different "hey, this might work" iptables commands at this thing to no avail. Happy to post my iptables-save, as that's likely useful, but would make my post even longer.
Can anyone see where I'm going wrong with this, and why this wouldn't translate over?
I still have the old DDWRT rig here, and I've been connecting to that to try and compare the two - I had this same problem back on the ddwrt setup, until i added that final masquerade rule. Netfilter is netfilter, I can't see what's missing.
For now, I'm just going to have to remember to undo my hosts file whenever I leave my network, so not the end of the world. Surprised none of the variations of this question I found seemed applicable, but I guess as I want to blindly forward all traffic to my servers, and let their netfilter rules control what accesses what, instead of simply forwarding ports, maybe that's a less-desired setup for most.
At any rate, any input much appreciated.
Am at that point where a week of google-fu and haphazardly going from "iptables policy that makes sense" to "this doesnt make sense, but maybe it'll work", have to throw my hands up and ask for help
My situation:
{Works}
-ASUSWRT-Merlin RT-N66U_3.0.0.4
-cheapy Comcast Business modem (SMC) goes to N66U (obviously), goes to cheapy but good 8-port Asus Gbit switch, servers wired into switch.
-a static /29 block from my ISP (4 for my servers, one for my N66U
-a 1-to-1 NAT setup via iptables SNAT/DNAT
-all hosts on the LAN, whether wired or wireless, can communicate with each other via the private IP (e.g. both wired and wireless clients can connect => 192.168.1.25:25 on the mail server)
-all hosts outside my LAN (e.g. everyone else on the interwebs) can connect to my servers as intended
-for our purposes here, x.x.x.88 is the network address, x.x.x.94 the gateway, x.x.x.95 the broadcast, x.x.x.90 is the N66U, and x.x.x.89 and x.x.x.91-93 are my usable IPs (my servers)
{Buggered}
-from within my LAN, I can't connect to these hosts via their public IP
-it's as though server receives request from client, but server's response never makes it back. Specifically:
telnet from my laptop (192.168.1.142) => mail server (x.x.x.92:25), I see:
Code:
tcp 0 54 192.168.1.25:25 192.168.1.1:60499 ESTABLISHED 22320/smtpd....so, it sees the N66U's br0 IP, and neither the client's private nor public IP
I pop into asuswrt-merlin via ssh, and do nc x.x.x.92:25 and it's a "connection refused"
Perhaps relevant, .91 is my web server, and nc x.x.x.91:80 yields:
Code:
# nc x.x.x.91:80
GET / HTTP/1.1
HTTP/1.0 401 Unauthorized
Server: httpd
Date: Wed, 30 Jul 2014 07:47:08 GMT
WWW-Authenticate: Basic realm="RT-N66U"
Content-Type: text/html
Connection: closeHrmm...that should be hitting my web server, not the httpd on my Merlin box.
Now some background, I did have this functional on a DD-WRT system before. I say that not for blame's sake (because, well, this is obviously user error!), but because I can't get my head around why the gander is so opposed to the goose's sauce.
My old ddwrt setup that worked, was a simple little:
Code:
WANIF=`nvram get wan_iface`
WANMASK=`nvram get wan_netmask`
ifconfig $WANIF:1 x.x.x.91 netmask $WANMASK broadcast x.x.x.95
ifconfig $WANIF:1 x.x.x.92 netmask $WANMASK broadcast x.x.x.95
ifconfig $WANIF:1 x.x.x.93 netmask $WANMASK broadcast x.x.x.95
ifconfig $WANIF:1 x.x.x.89 netmask $WANMASK broadcast x.x.x.95
iptables -t nat -I PREROUTING -d x.x.x.89 -j DNAT --to 192.168.1.43
iptables -t nat -I POSTROUTING -s 192.168.1.43 -j SNAT --to x.x.x.89
iptables -t nat -I PREROUTING -d x.x.x.91 -j DNAT --to 192.168.1.80
iptables -t nat -I POSTROUTING -s 192.168.1.80 -j SNAT --to x.x.x.91
iptables -t nat -I PREROUTING -d x.x.x.92 -j DNAT --to 192.168.1.25
iptables -t nat -I POSTROUTING -s 192.168.1.25 -j SNAT --to x.x.x.92
iptables -t nat -I PREROUTING -d x.x.x.93 -j DNAT --to 192.168.1.67
iptables -t nat -I POSTROUTING -s 192.168.1.67 -j SNAT --to x.x.x.93
iptables -I FORWARD -d 192.168.1.80 -j ACCEPT
iptables -I FORWARD -d 192.168.1.25 -j ACCEPT
iptables -I FORWARD -d 192.168.1.43 -j ACCEPT
iptables -I FORWARD -d 192.168.1.67 -j ACCEPT
iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADESimple enough. After a bit of wrangling, I managed to port these over into nat-start and firewall-start scripts.
{nat-start}
Code:
#!/bin/sh
echo 'Start' >> /tmp/000start-nat
iptables -t nat -I PREROUTING -d x.x.x.93 -j DNAT --to 192.168.1.67
iptables -t nat -I POSTROUTING -s 192.168.1.67 -j SNAT --to x.x.x.93
iptables -t nat -I PREROUTING -d x.x.x.92 -j DNAT --to 192.168.1.25
iptables -t nat -I POSTROUTING -s 192.168.1.25 -j SNAT --to x.x.x.92
iptables -t nat -I PREROUTING -d x.x.x.91 -j DNAT --to 192.168.1.80
iptables -t nat -I POSTROUTING -s 192.168.1.80 -j SNAT --to x.x.x.91
iptables -t nat -I PREROUTING -d x.x.x.89 -j DNAT --to 192.168.1.43
iptables -t nat -I POSTROUTING -s 192.168.1.43 -j SNAT --to x.x.x.89
echo 'End' >> /tmp/000start-nat{firewall-start}
Code:
#!/bin/sh
for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 0 > $i ; done
iptables -I FORWARD -d 192.168.1.80 -j ACCEPT
iptables -I FORWARD -d 192.168.1.67 -j ACCEPT
iptables -I FORWARD -d 192.168.1.43 -j ACCEPT
iptables -I FORWARD -d 192.168.1.25 -j ACCEPT
iptables -t nat -I POSTROUTING -o br0 -s 192.168.0.0/16 -d 192.168.0.0/16 -j MASQUERADEThis accomplishes the goal of opening up these servers to folks in the outside world. That part is good to go.
But of course, no connectivity from within my LAN.
Hate throwing my hands up and saying "HALP!", but I'm at that point. I've been firing different "hey, this might work" iptables commands at this thing to no avail. Happy to post my iptables-save, as that's likely useful, but would make my post even longer.
Can anyone see where I'm going wrong with this, and why this wouldn't translate over?
I still have the old DDWRT rig here, and I've been connecting to that to try and compare the two - I had this same problem back on the ddwrt setup, until i added that final masquerade rule. Netfilter is netfilter, I can't see what's missing.
For now, I'm just going to have to remember to undo my hosts file whenever I leave my network, so not the end of the world. Surprised none of the variations of this question I found seemed applicable, but I guess as I want to blindly forward all traffic to my servers, and let their netfilter rules control what accesses what, instead of simply forwarding ports, maybe that's a less-desired setup for most.
At any rate, any input much appreciated.
