I'm having a fritzbox with vpn and fritznas set up. From inside the local network as expected there is no problem, I can access the user interface as well as mounting the samba share.
But now I'm trying this from another network (but connected to the firtzbox via the built in vpn service) and I've got a situation which is very weird.
From my laptop I can connect via vpn and bring the user interface up, but I cannot login in the user interface (with the normal user interface password) neither can I mount my samba share.
But I'm sure that the vpn connection is set up properly since ssh to machines connected to the remote fritzbox works.
And now I've tried this too from my smartphone (connecting via vpn, log into the user interface and access the samba share) and there everything is quite fine.
Any suggestions what might cause these problems on the laptop (I'd say that something in the fritzbox is set up falsely but since it works on the smartphone, it has to be something on my laptop I think)? (I have tried everything I can think of but nothing works)
With best regards and thanks in advance
PS: My OS is Arch Linux
EDIT: It gets even stranger: If I change my setup from
Laptop -> WLAN -> VPN to
Laptop -> Hotspot of my Smartphone -> VPN it works again (but slow of course since now it is over the mobilenet of the smartphone)
I am wondering how I can scan for open ports on all devices that are hooked up to the router. For example: I got 3 computer connected to router. Each computer has something going on on their localhost:3000. My aim is to find all of those opened hosts - to get the following results (ip address on local network):
10.0.0.5:3000
10.0.0.10:3000
10.0.0.19:3000
Any ideas?
If you're under linux you can use nmap command for this task, for Windows I thinks you can install it too but idk about Windows.
It seems I have this weird issue I can't really understand. I am able to connect to a remote computer (windows machine) with remote desktop perfectly but I am not be able to ping to it. When I ping I get timeout all the time. It is the same ip address and I am using the same computer, so there are no firewall issue I think. From what I know ping is using it own protocol (different than TCP and UDP) so you don't ping to a precific port
Yes it is. The system administrator, and the network administrators (of the several networks you need to use to access the remote machines), are able configure their boxes to disable ICMP. Then ping does not work, but HTTP or ssh (or whatever protocol your remote desktop uses) could work.
ICMP is often disabled for security reasons, and to lower the load on the remote computer. It makes slightly harder to find the remote host.
I am using VMWare Player 3.1.0 on Host OS Windows 7 Professional 64-bit. My guest is is SUSE Linux ES 10. My guest OS (SUSE) runs JBoss App Server which I access from host using HTTP. I used a "Bridged" connection to set up all this.
My problem:
When I am connected to network on the Host (using wired network adapter) I can connect to the http server on the Guest OS and browse the application. However, when I am disconnected from the network on Host (unplugged the wire), I cannot access to the guest OS app server and browse the application. I use the guest OS ifconfig command to find out ip address of the guest OS. This ip address does not change whether connected or disconnected. I have even tried using Wireless Data card, but that does not work either.
I have tried "NAT" as well as "Host Only" connection and rebooted the guest but it does not work either. I think for some reason the guest OS can only recognize the physical network card (which is disconnected).
I need to run this machine (my laptop) independently of the network because I use this for demo and need to be able to connect from my host OS to Guest OS.
I am not sure I understand exactly what you are trying to do, but I do know setting up a working NAT configuration will offer you the most flexibility.
Click the networking icon and select settings, Select NAT.
Follow these steps on your Unix OS
cd /etc/sysconfig/network-scripts
Make a backup of your ethernet adapter configuration
cp ifcfg-eth0 ifcfg-eth0.bak
Next modify the settings to look like the following:
DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="What ever was here on your system"br/>
NM_CONTROLLED="yes"
ONBOOT="yes"
Save your changes
Restart your network adapters
/etc/init.d/network restart
Try nslookup www.google.com
You should now be able to connect back and forth from your Windows Host and Linux guest.
theJay28
-p.s. I had screenshots, but I do not have the 10 points yet to post images.
I figured that the solution is to restart the VM after making the changes to the NetWork setting on the VMWare. I selected Network for the VM as "Host Only" shutdown the VM and started it again. After that I was able to do what I wanted to do (i.e. browse the web application on guest from the browser in the host machine) without connecting the host to the network.
So key to the solution in my case was to make the network changes and restart the VM.
Any comments suggestions welcome...
I have the Xming X Window Server installed on a laptop running Windows XP to connect to some UNIX development servers.
It works fine when I connect directly to the company network in the office. However, it does not work when I connect to the network remotely over a VPN.
When I start Xming when connected remotely none of my terminal Windows are displayed.
I think it may have something to do with the DISPLAY environment variable not being set correctly to the IP address of the laptop when it is connected.
I've noticed that when I do an ipconfig whilst connected remotely that my laptop has two IP addresses, the one assigned to it from the company network and the local IP address I've set up for it on my "local network" from my modem/router.
Are there some configuration changes I need to make in Xming to support its use through the VPN?
Chances are it's either X authentication, the X server binding to an interface, or your DISPLAY variable. I don't use Xming myself but there are some general phenomenon to check for. One test you can do to manually verify the DISPLAY variable is correct is:
Start your VPN. Run ipconfig to be sure you have the two IP addresses you mentioned (your local IP and your VPN IP).
Start Xming. Run 'netstat -n' to see how it's binding to the interface. You should see something that either says localIP:6000 or VPNIP:6000. It may not be 6000 but chances are it will be something like that. If there's no VPNIP:6000 it may be binding only to your localIP or even 127.0.0.1. That will probably not work over the VPN. Check if there are some Xming settings to make it bind to other or all interfaces.
If you see VPNIP:6000 or something similar, take note of what it says and remote shell into your UNIX host (hopefully something like ssh, if not whatever you have to get a text terminal).
On the UNIX terminal type 'echo $DISPLAY'. If there is nothing displayed try 'export DISPLAY=VPNIP:0.0' where VPNIP is your VPN IP address and 0.0 is the port you saw in step 3 minus 6000 with .0 at the end (i.e. 6000 = 0.0, 6010 = 10.0).
On the UNIX host run something like 'xclock' or 'xterm' to see if it runs. The error message should be informative. It will tell you that it either couldn't connect to the host (a connectivity problem) or authentication failed (you'll need to coordinate Xauth on your host and local machine or Xhosts on your local machine).
Opening Xhosts (with + for all hosts or something similar) isn't too bad if you have a locally protected network and you're going over a VPN. Hopefully this will get you started tracking down the problem. Another option that is often useful as it works over a VPN or simple ssh connectivity is ssh tunneling or X11 forwarding over ssh. This simulates connectivity to the X server on your local box by redirecting a port on your UNIX host to the local port on your X server box. Your display will typically be something like localhost:10.0 for the local 6010 port.
X can be ornery to set up but it usually works great once you get the hang of it.
Thanks for the help #Stephen and #Greg Castle, using it I've managed to resolve my problem.
To provide a basic guide for others (from scratch):
Using Xwindows on a Windows PC to connect to a UNIX server over a VPN
What you need to start with:
The Putty Telnet/SSH client, download putty.exe (for free) from:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
The Xming X server, download Xming (for free) from:
http://sourceforge.net/project/showfiles.php?group_id=156984
What to do:
Install both of the above on your Windows PC
From the Windows start menu select: Programs -> Xming -> Xming
Run the Putty.exe program in the location you downloaded it to
In the PuTTY configuration screen do the following:
Set the IP address to be the IP address of your UNIX server
Select the SSH Protocol radio-button
Click the SSH : Tunnels category in the left hand pane of the configuration screen
Click the Enable X11 forwarding check-box
Click the Open button
Logon as usual to your UNIX server
Check the directory containing the X windows utilities are in your path, e.g. /usr/X/bin on Solaris
Run your X Windows commands in your putty window and they will spawn new windows on your desktop
I got Xming and PuTTY working with Cisco VPN by replacing the PuTTY configuration in Connection > SSH > X11 > X display location, localhost:0.0, with VPNIP:0.0. VPNIP can be seen in the VPN statistics client address information by left-clicking on the VPN client lock icon and choose Statistics....
I didn't muck with the DISPLAY environment variable on the remote host. But, like others, I modified sshd_config on the remote host, adding these lines:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet
I have got same issue with Xming and Putty on a Windows 10 machine and found the solution here. I have overcome the problem just adding Tunnels to the session in PuTTY. But first you need to check;
sshd_config under /etc/ssh (in rhel7).
Enable X11 forwarding at left navigation pane Connections > SSH > X11
iptables under /etc/sysconfig/ (in rhel7). If ports are blocked and you have permission, open the ports for 6000. I have added below line before first reject line to open ports from 6000 to 6003. It may be more specific in your case.
-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 5901:5903,6000:6003 -j ACCEPT
Then;
Go to Connections > SSH > Tunnels in PuTTY and add a tunnel with Source Port=6000, Destination=127.0.0.1:6000 and check Remote radio button. Then click the Add button.
After your SSH connection established, set your DISPLAY variable manually with the command below:
export DISPLAY=127.0.0.1:0.0
More Information;
If you set DISPLAY variable as 127.0.0.1:1.0, it will communicate over 6001 port . In this case, you need to add another tunnel for port number 6001.
I had nothing but problems with Xming. When I could get it to work it was extremely slow (this is over a VPN). IMO X is not designed to run over slow connections its too chatty. And by slow connection I mean anything less then a LAN connection.
My solution was to use x11vnc. It lets you access your existing X11 session through VNC. I just ssh into my box through the VPN and launch:
$ x11vnc -display :0
That way I can access everything I had opened during the day. Then when I don't I just exit (Ctrl-C) in the terminal to close x11vnc.
Haven't have the exact problem, but I think you need to look at the xhost and make sure that the vpn remote is allowed to send data to the x server.
This link might help:
http://www.straightrunning.com/XmingNotes/trouble.php
You may have better luck doing X11 Forwarding through SSH rather than fiddling with your DISPLAY variable directly. X11 Forwarding with SSH is secure and uses the existing SSH connection to tunnel, so working through a VPN should be no problem.
Fortunately this is fairly straightforward with Xming. If you open your connection from within Xming (e.g. the plink option) I believe it sets up X11 forwarding by default. If you connect using another SSH client (e.g. PuTTY) then you simply need to enable X11 forwarding (e.g. 'ssh -X user#host'). In PuTTY the option is under Connection -> SSH -> X11 -> click on 'Enable X11 Forwarding'.
Make sure Xming is running in the background on your laptop and do the standard X test, 'xclock'. If you get a message like 'X connection to localhost:19.0 broken (explicit kill or server shutdown).' then Xming is most likely not running.
Also, make sure you're not explicitly setting your DISPLAY variable in any startup scripts; SSH will set up an alias (something like localhost:10 or in the example above localhost:19) for the X11 tunnel and automatically set DISPLAY to that value. Overwriting DISPLAY will obviously mean you will no longer be pointing to the correct X11 tunnel. The flip side of this is that other terminals that don't have SSH X11 Forwarding set can use the same DISPLAY value and take advantage of the tunnel.
I tend to prefer the PuTTY option but several of my coworkers use plink from within Xming.
putty + XMing - I had to set the DISPLAY environment variable manually to get things running (alongside with checking "Enable X11 forwarding" in putty - Connection/SSH/X11)
export DISPLAY=0:10.0
(it was set to "localhost:10.0", which did not work)
You have to add the Linux machine's DNS name(s) and IP address to the C:\Program Files\xming\X0.hosts file. File should contain:
LinuxBox.mydomain.com
LinuxBox
192.168.1.25
This is the right answer: https://www.slackwiki.com/X_Windows:_Remote_X_to_Windows_with_Xming