IP-forwarding - Does it work? Or do I need VPN? Or what?

I hope I can make myself clear. If not, ask.

My task is, to set up a(nother) server for our server room. Access is difficult, closed doors, remote location, etc.
Therefore my idea was, to install, configure, etc. everything in my office. Since the server will have to work in the DMZ, I can't do much in my office; I have no DMZ-address here.
Therefore I was thinking of 'forwarding' the future IP-address in the DMZ, let's say 10.10.10.1/24, from a stub machine placed in the server room into my office. I wonder how to do this most favourable.
So I think port-forwarding around 10 ports with ten ssh sessions would be neither clever, nor elegant.
I wonder if it is possible to directly forward everything coming into an IP address directly instead? Or should I try VPN?

What can the people in this forum recommend?

Thanks in advance,

Uwe

You could all of the port looping in one ssh session. Do you have ssh access to the new server?

I use the Windows puTTy ssh program for similar purposes, and bind 127.0.0.2 desktop ports to the remote ports on the server. The ports get tunneled through the ssh connection; as long as the puTTy session stays up, 127.0.0.2:80 gets to the http service, etc. You can also use the Xming X-server component of the puTTy suite and run native X Windows programs on the server with the display coming back to your desktop.

Or you can use a Linux box in your office and just use ssh to do this.

The server will need to have enabled in sshd_config:
AllowTcpForwarding yes
and for X forwarding
X11Forwarding yes

Since you're presumably tunneling through your firewall(s), you should probably check this with your security doods.

Quote:

---

Originally Posted by greyhairweenie

You could all of the port looping in one ssh session. Do you have ssh access to the new server?

I use the Windows puTTy ssh program for similar purposes, and bind 127.0.0.2 desktop ports to the remote ports on the server.

---

Thanks, greyhairweenie.
You ask and tell me about all that I know. Héhé.
I like the 127.0.0.2 thingy. Could you share what you actually type as options to ssh, to redirect a plurality of ports through the same session to 127.0.0.2?? On both sides?

Uwe

You'll probably want a "SSH port forward".

Let me reiterate your description to see if I understand...

You want to build a new server that will, eventually, go into your DMZ. You don't have easy access to your DMZ. You'd like to setup a 'stub' server that catches access from outside your company to the DMZ IP address and forward that traffic to an internal address that you do have easy access to.

You seem to say you are thinking the 'stub' machine in the DMZ could do a general port forward to your private address?

Assuming you have iptables and your private IP is 10.1.2.3, you could port forward all desired ports using something like...

iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to 10..2.3:22
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 10.1.2.3:53
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.1.2.3:80

However, you would have to set up the outgoing path, as well. Since it is unlikely that traffic out from your test box will get masqueraded as from your DMZ address. This is likely to confuse your clients. You could masquerade on your test box as the DMZ address, but a correctly setup firewall should drop those packets.

Setting your test box to proxy through your 'stub' might solve your problem, but setting that up might be a bit complex and unwieldy.

If it is possible, you might want to setup a VPN between your test box on the private network and the DMZ 'stub' box. This would give your test box a private IP with a default route through the 'stub' so the 'stub' could masquerade outbound traffic. I could assume that your firewall passes IPSEC nicely and suggest using that. Or, if you have it available, you could try OpenVPN.

Setting all of this up might be a project in itself, if you haven't done this kind of thing before. It seems like a lot of work to get a test environment for one machine. It might be worth it if you will be using the same method for future projects. It might be worth it for fail-over, as well.

But I might be misunderstanding your situation and desires.

If Dustspeck's response indicates what you're trying to do, I completely misunderstood. I was thinking that the server would already be in the DMZ, that you for whatever reasons didn't have access to the service ports on it from inside. But you can still use ssh port forwarding in a single session to do what you want. Put the stub server in place, then from the real server in your office, something like:

#!/bin/bash
#set up forwarding from stub
ssh -fN \
-Rstub:443:real:443 \
-Rstub:80:real:80 \
-Rstub:25:real:25 \
-Rstub:993:real:993 \
root@stub

[Edit: Assumption is that the stub box would have the IP address that the real server will be placed on, from an outside perspective.] That would forward https, http, smtp, and imaps remote ports from the stub to local ports on the real server, which should of course already have those services listening on those ports, allowing you to test services from outside as though the real server were already on the DMZ. The stub server would need NOT to have those services listening on those ports. You can use PKI authentication and autossh to set up a persistent connection.

If I was right to start with about your intent, you'd use -L to bind local ports on your desktop. That would look like:
-L127.0.0.2:80:real-on-dmz:80 \
-L127.0.0.2:443:real-on-dmz:443 \
and so on.

Good luck. This is really not that difficult to do, and I'd infer that you have the knowledge to extrapolate what I've said to meet your requirements.

Quote:

---

Originally Posted by Dustspeck

Let me reiterate your description to see if I understand...

You want to build a new server that will, eventually, go into your DMZ. You don't have easy access to your DMZ. You'd like to setup a 'stub' server that catches access from outside your company to the DMZ IP address and forward that traffic to an internal address that you do have easy access to.

You seem to say you are thinking the 'stub' machine in the DMZ could do a general port forward to your private address?

---

Spot on. That's what I had in mind. (Of course, reverse forwarding due to the LAN being inaccessible from the DMZ.)

(To Kloschüssel: yes, I am aware of ssh port forward.)

I am well able to do a 'simple' port forward; but thought it was a good idea to ask in here, since the port forward does come with a number of encumbrances; as you pointed out.
Therefore, I was throwing a question into the ring: Instead of forwarding a dozen of ports, with a bunch of problems, could one not intercept *all* traffic from the network layer (kind of 'inside' the NIC), and forward the IP address instead (so to say)??

Quote:

---

Originally Posted by Dustspeck

Assuming you have iptables and your private IP is 10.1.2.3, you could port forward all desired ports using something like...

iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to 10..2.3:22
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 10.1.2.3:53
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.1.2.3:80

---

Not quite. Running my servers on OpenBSD (so sorry, linuxforum!) I could do the same with PF, though.
But I don't really grasp what you want to do here. Yes, the stub server is in the DMZ and has the future IP address. Let's say 10.10.10.4 in accordance to my original post. DMZ. My internal address, in my office, could then be 192.168.1.4, where the future server is placed now.
What does all that prerouting get me, since - of course - the internal LAN is not reachable from the DMZ.

Quote:

---

Originally Posted by Dustspeck

If it is possible, you might want to setup a VPN between your test box on the private network and the DMZ 'stub' box. This would give your test box a private IP with a default route through the 'stub' so the 'stub' could masquerade outbound traffic. I could assume that your firewall passes IPSEC nicely and suggest using that. Or, if you have it available, you could try OpenVPN.

---

So we are on a similar wavelength here as well. I was thinking about this, set up a VPN, worked, but didn't get me much further; for whatever reason. Because the tun-device in the stub server would still be on some address different from the real, physical, address of the stub server; and one way or another, I'd still need to forward/route all ports to that tun-address (and maybe do the same on the future server in my office; off the tun to the real address).

So that's a lot of forwarding, routing, setting, etc.

Exactly therefore my earlier question about the existence of a 'bundled' forward of a whole IP instead of port-by-port.
Since I am quite experienced with port forwarding, though I'm lousy with VPNs, I dared to drop that question, if eventually there was a way to set up a VPN, and get any traffic on eth0 (bge0, in this case, BSD), to tun0 on the DMZ end; and any traffic from tun0 on the future server in my office likewise to the address of the NIC.

Quote:

---

Originally Posted by Dustspeck

But I might be misunderstanding your situation and desires.

---

Not at all!

Uwe

Quote:

---

Originally Posted by greyhairweenie

If Dustspeck's response indicates what you're trying to do, I completely misunderstood. I was thinking that the server would already be in the DMZ, that you for whatever reasons didn't have access to the service ports on it from inside. But you can still use ssh port forwarding in a single session to do what you want. Put the stub server in place, then from the real server in your office, something like:

#!/bin/bash
#set up forwarding from stub
ssh -fN \
-Rstub:443:real:443 \
-Rstub:80:real:80 \
-Rstub:25:real:25 \
-Rstub:993:real:993 \
root@stub

[Edit: Assumption is that the stub box would have the IP address that the real server will be placed on, from an outside perspective.] That would forward https, http, smtp, and imaps remote ports from the stub to local ports on the real server, which should of course already have those services listening on those ports, allowing you to test services from outside as though the real server were already on the DMZ. The stub server would need NOT to have those services listening on those ports. You can use PKI authentication and autossh to set up a persistent connection.

---

Thanks, and everything clear until here.
My question was not so much into the direction of reverse ssh; but a more general, simpler, setup. I was kind of asking myself: "Am I the only one who wants to install, configure, test, his servers in his office; and bring them into the server room once (s)he's done?" And my answer to myself was 'no'. So there was a good chance of some ready-made software, scripts, tutorial for a generic solution; without having to fiddle with counting ports, retrieve service numbers, creating keys, preparing auto-logons, and whatnot. (Just think of it: a reboot, and one needs to restart the whole lot.)
Therefore my question of a 'catch-all', one that does something like
ssh -R 10.10.10.4:*:192.168.1.4:*
(what I called 'IP-forwarding')

Quote:

---

Originally Posted by greyhairweenie

If I was right to start with about your intent, you'd use -L to bind local ports on your desktop. That would look like:
-L127.0.0.2:80:real-on-dmz:80 \
-L127.0.0.2:443:real-on-dmz:443 \
and so on.

Good luck. This is really not that difficult to do, and I'd infer that you have the knowledge to extrapolate what I've said to meet your requirements.

---

Yes, I think I do. Could you explain what these last lines would be doing? I don't grasp their purpose, sorry.

Uwe

Code:

---

ssh -L127.0.0.2:80:real-on-dmz:80 \
-L127.0.0.2:443:real-on-dmz:443

---

These are ssh commands that set up a ssh tunnel that forwards all packets that you would send to 127.0.0.2:80 and 127.0.0.2:443 to real-on-dmz:80 and real-on-dmz:443.

But actually you would set up a forward (on your local pc) to accomplish something like:

ssh -L<future>:80:<temporary>:80

This would masquerade it to you that you are actually working locally (the server has the ip/hostname <temporary>) and you can test the server as if it was located at <future>.

But you may also could consider to just add a /etc/hosts entry that overrides the actual dns resolution of the <future> hostname to a temporary (local) IP.

Code:

---

my.future.host w.x.y.z

---

PS: this would actually simulate a host that is fully accessible from the network it is contained in, thus making it possible to do tests (fail2ban, iptables, dos counterfeiting, ..) and stuff that wouldn't be possible with ssh tunnels as these are unable to forward udp traffic.

Quote:

---

Originally Posted by udippel

Thanks, and everything clear until here.
My question was not so much into the direction of reverse ssh; but a more general, simpler, setup. I was kind of asking myself: "Am I the only one who wants to install, configure, test, his servers in his office; and bring them into the server room once (s)he's done?" And my answer to myself was 'no'. So there was a good chance of some ready-made software, scripts, tutorial for a generic solution; without having to fiddle with counting ports, retrieve service numbers, creating keys, preparing auto-logons, and whatnot. (Just think of it: a reboot, and one needs to restart the whole lot.)
Therefore my question of a 'catch-all', one that does something like
ssh -R 10.10.10.4:*:192.168.1.4:*
(what I called 'IP-forwarding')



Yes, I think I do. Could you explain what these last lines would be doing? I don't grasp their purpose, sorry.

Uwe

---

You're certainly not the only one who wants to do that, although many if not most of us have had to give it up due to remote hosting making it impractical. When I used to do it, I had the luxury of being the chief systems engineer with oversight of the entire infrastructure, and I simply had one of the jacks in my office patched onto the DMZ or other server switch segment. Had a Cisco 3750 in my office connected to that. For what you want, VPN, VLAN, or physical patching would seem to be necessary if you're not willing to identify and forward the necessary ports.

The last "-L" lines are not given in context of an ssh command, but I'm sure you see how they'd fit. They simply do what the later poster indicated, bind ports on the originating machine's 127.0.0.2 interface to the indicated ports on the remote machine's network interface such that 127.0.0.2 presents as the remote host for those services.

I have port-forward tunnels that survive reboots, re-establish after network interruptions, etc. When you've worked through it once, it's very simple to replicate, and it's a very useful skill to have.