Results 1 to 10 of 12
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Feb 2007
IP-forwarding - Does it work? Or do I need VPN? Or what?
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,
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:
and for X forwarding
Since you're presumably tunneling through your firewall(s), you should probably check this with your security doods.
- Join Date
- Feb 2007
You'll probably want a "SSH port forward".
- Join Date
- Jan 2008
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:
#set up forwarding from stub
ssh -fN \
[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:
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.
- Join Date
- Feb 2007
(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)??
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.
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.
- Join Date
- Feb 2007
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')
ssh -L127.0.0.2:80:real-on-dmz:80 \ -L127.0.0.2:443:real-on-dmz:443
But actually you would set up a forward (on your local pc) to accomplish something like:
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.
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.