1

Ok, i'm still working on creating a dmz'd http server

So now I have an ethernet tunnel using ssh -w 0:0 and I have interfaces on each end which can talk to each other:

previous question


So now I'm grappling with getting this http server to be visible to the outside net. Here is the complete setup

So I create a new ec2 instance and I run the setup:

source ./HOST

scp -i green.pem server/* root@$HOST:
ssh -i green.pem root@$HOST ./setup

it in turns runs the setup on the remote machine:

apt-get update
apt-get install telnet

echo 1 | tee /proc/sys/net/ipv4/ip_forward
echo "PermitTunnel yes" >> /etc/ssh/sshd_config
/etc/init.d/ssh restart

then I initiate the ssh connection:

sudo ./runserver $HOST:

HOST=$1
ssh -i green.pem root@$HOST -w 0:0 -o Tunnel=ethernet -o ServerAliveInterval=60

then inside of that ssh term I start routing the iptables forwarding:

#####
# server routing
# bring up the tap
ifconfig tap0 up
# route all traffic for 192.168.2.* through it
ip route add 192.168.2.0/24 dev tap0

#####
# server iptables
REMOTE_INTERNAL_IP=$1

iptables -F
iptables -t nat -F

### end init firewall .. Start DMZ stuff ####
# forward traffic between DMZ and LAN
iptables -A FORWARD -i eth0 -o tap0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tap0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Route incoming port to DMZ server 192.168.2.1
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8000 -j DNAT --to-destination 192.168.2.1:8000
iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to $REMOTE_INTERNAL_IP
### End DMZ .. Add other rules ###

finally on the client i add the routes and port forwarding


##########
# client
HOST=$1

# bring up the tap
ifconfig tap0 up
# put an ip on it so we can listen
ifconfig tap0 192.168.2.1
# add an explicit route for our ssh
ip route add $HOST via 192.168.1.1 dev eth0

# make the tap the default routing
ip route replace default dev tap0
# remove the default link
#ip route del 192.168.2.0/24 dev tap0  proto kernel scope link src 192.168.2.1

and I start the web server

python -m SimpleHTTPServer

when I do a telnet 192.168.2.1 from either server it passes through fine. but if I do a telnet to $THE_REAL_IP it does not work.

if I put a MASQUERADE iptables rule, then it functions fine, but I'm doing to this to avoid MASQUERADE. I want to have the origin IP stay on the packet.


Any ideas what I'm doing wrong?

-----


more information

-----


Ok so now I have tried a whole lot more sets of attempts. And still nothing works.

The one I thought might work would be adding this to the client:

# these should route packets back to tap0
ip rule add from 192.168.2.0/24 table 42
ip route add default dev tap0 table 42

Because this should put a forced rule for everything that is written for 192.168.2.1 should go back through that tap0 interface. But it doesn't work unfortunately.

Also I tried associating an ip with the tap0 on the remote side.

ifconfig tap0 192.168.2.5

And this seems interesting because now I don't need to set up routing, the system seems to do it almost automatically:

#####
# server routing
# bring up the tap
ifconfig tap0 192.168.2.5
ifconfig tap0 up
# route all traffic for 192.168.2.* through it
ip route add 192.168.2.0/24 dev tap0


#####
# server iptables

iptables -F
iptables -t nat -F

# forward traffic between DMZ and LAN
iptables -A FORWARD -i eth0 -o tap0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tap0 -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Route incoming port to DMZ server 192.168.2.1
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8000 -j DNAT --to-destination 192.168.2.1:8000
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

### End Server ####

#############################
#############################

##########
# client
echo 1 | tee /proc/sys/net/ipv4/ip_forward

# bring up the tap
ifconfig tap0 up
# put an ip on it so we can listen
ifconfig tap0 192.168.2.1

# these should route packets back to tap0
# but they actually don't make any difference
#ip rule add from 192.168.2.0/24 table 42
#ip route add default dev tap0 table 42

3
  • I am super stuck. If anyone has any clues I would be grateful. Basically I think the packs are getting across, but not coming back. But they should because I have that "ip route replace default" which should send the packets over, and then they should be picked up and forwarded to out eth0 on the remote... no? Mar 23, 2013 at 21:09
  • Ok I've been researching and researching and I think somehow this: policy based routing is going to com into place.. of course they left out enough information that I will need to research for another hour to even know if it is what I should do.. :-( Mar 23, 2013 at 21:20
  • ok, so. I've installed this rule set on the local side: ip rule add from 192.168.2.0/24 table 42 and ip route add default dev tap0 table 42 ... they appear to function ... but still the 8000 webserver is not visible from the outside.. which makes me think now that the problem is on the remote end. not the client side. Mar 23, 2013 at 22:19

2 Answers 2

1

I realise you stated that you want to keep the original IP address hitting your Python server, but you might be taking the wrong approach here. It's standard practice to pass through the original IP address via HTTP in the X-Forwarded-For header. Most web frameworks will pick up this header and use in place of the original IP address if it's specified.

If you wanted to go down that road, all you'd need is a front end web server. It's a good idea to have a front end, anyway: it's more secure because no-one has direct access to your app server, and you can easily implement services like HTTPS and caching without taking more CPU cycles on the app server. Something like Nginx would do the trick beautifully.

2
  • Interesting. I wish I knew about this earlier actually. Although some of what I'm doing is raw tcp (not webserver) I might be able to change this over to websockets. Mar 24, 2013 at 1:11
  • it turns out I can't convert a key component to webserver/websocket. Mar 26, 2013 at 10:29
0

If you use DNAT rather than MASQUERADE then you should keep the source IP address as-is on the incoming packets.

Of course with DNAT, as the source address is not altered, you need to tbe careful to make sure the other end knows to send response packets back the same way - in your case back down the tunnel instead of over the public interface which will be the default gateway.

2
  • 1
    yah, I'm doing DNAT.. the problem is the packets aren't coming back :-).. If I stick the MASQUERADE on then the packets come back, but they lose IP information. Mar 23, 2013 at 21:19
  • I would just like to clarify that I have no idea whether the packets are coming back or not. I'm completely stumped actually. Mar 24, 2013 at 0:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .