Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My goal is to be able to connect using remote desktop on my desktop machine, to windows xp running in virtualbox on my linux server.

My setup:

  • server = debian squeeze, 64 bit, with a public IP address (host)
  • virtualbox-ose 3.2.10 (from debian repo)
  • windows xp running inside VBox as a guest; bridged networking mode in VBox, ip = 192.168.1.100
  • ufw as the firewall on debian, 3 ports are opened: 22 / ssh, 80 / apache, and 3389 for remote desktop

My problem: If I try to use remote desktop on my home computer, I am unable to connect to the windows guest. If I first "ssh -X -C" into the debian server, then run "rdesktop 192.168.1.100", I am able to connect without issue. The windows firewall was configured to allow remote desktop connections, and I've even turned it off (as it is redundant here) to see if that was the problem but it made no difference.

Since I am able to connect from inside the local subnet, I suspect that I have not setup my debian firewall correctly to handle connections from outside the LAN. Here is what I've done...

First my ufw status:

ufw status                                                                                                   
Status: active                                                                                                                          

To                         Action      From                                                                                             
--                         ------      ----
22                         ALLOW       Anywhere
80                         ALLOW       Anywhere
3389                       ALLOW       Anywhere

I edited /etc/ufw/sysctl.conf and added:

net/ipv4/ip_forward=1

Edited /etc/default/ufw and added:

DEFAULT_FORWARD_POLICY="ACCEPT"

Edited /etc/ufw/before.rules and added:

# setup port forwarding to forward rdp to windows VM
*nat
:PREROUTING - [0:0]

-A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.100
-A PREROUTING -i eth0 -p udp --dport 3389 -j DNAT --to-destination 192.168.1.100

COMMIT

# Don't delete these required lines, otherwise there will be errors
*filter

<snip>

Restarted the firewall etc., but no connection.

My log files on the debian host show this (my public ip address was removed for this posting but it is correct in the actual log):

Feb  6 11:11:21 localhost kernel: [171991.856941] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb  6 11:11:21 localhost kernel: [171991.856963] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb  6 11:11:24 localhost kernel: [171994.856701] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb  6 11:11:24 localhost kernel: [171994.856723] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb  6 11:11:30 localhost kernel: [172000.856656] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb  6 11:11:30 localhost kernel: [172000.856678] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 

Although this is the current setup / configuration, I've also tried several variations of this; I thought maybe the ISP would be blocking 3389 for some reason and tried using different ports, but again there was no connection.

Any ideas...? Did I forget to modify some file somewhere?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

I'm really not being snarky with this, but you need to do your IPTAbles "firewall" management with something better than UFW.

It's fine for desktop use, but it designed for just that and not "server grade" usage.

I would highly suggest sitting down and spending some quality time learning how NetFilter/IPTables works and becoming comfortable with using those commands directly. If you're afraid that you'll break something, making backups of your IPTables config before changes or perhaps even a basic 'Git' version control setup will help you experiment and gain confidence.

share|improve this answer
    
I disagree, while UFW may not be useful in this particular circumstance. That does not make it useless for servers outright. There are plenty of times when a simple "ufw allow http" or "ufw limit ssh" makes more sense than working with iptables manually. UFW also allows for more complex rules that show that it is at least targeted at the server market. –  Soviero Jul 18 '12 at 4:48
    
Indeed, it looks like Ubuntu got their act together and made UFW interface-aware. Not sure I'd want to depend on any IT staff that don't know Linux networking well enough to need UFW instead of iptables though. –  Magellan Jul 18 '12 at 15:47
    
I did end up using plain iptables, seems to work much better / easier than working around the quirks in UFW. –  user85116 Aug 21 '12 at 17:42
    
IPTables is daunting at first. But once you get used to it, having that level of control is rather comforting. –  Magellan Aug 21 '12 at 18:08

This solved it for me:

sudo ufw allow proto tcp from 192.168.1.100 to any port 22

The problem is that the response was being blocked. Hope it helps someone.

share|improve this answer

Not sure if you are still in need of help here. I had the exact same issue and the problem was rather basic. The target server didn't have a default gateway entry and didn't bring the replies back to the gateway. After setting the default gateway everything went fine. You can check your routing by typing route -n (with -n avoiding time consuming DNS lookup for every entry).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.