Posts Tagged ‘tab’

How to make pptp VPN connection to use IPMI port (IPKVM / Web KVM) on Debian Linux

Wednesday, July 27th, 2011

If you have used KVM, before you certainly have faced the requirement asked by many Dedicated Server Provider, for establishment of a PPTP (mppe / mppoe) or the so called Microsoft VPN tunnel to be able to later access via the tunnel through a Private IP address the web based Java Applet giving control to the Physical screen, monitor and mouse on the server.

This is pretty handy as sometimes the server is not booting and one needs a further direct access to the server physical Monitor.
Establishing the Microsoft VPN connection on Windows is a pretty trivial task and is easily achieved by navigating to:

Properties > Networking (tab) > Select IPv4 > Properties > Advanced > Uncheck "Use default gateway on remote network".

However achiving the same task on Linux seemed to be not such a trivial, task and it seems I cannot find anywhere information or precise procedure how to establish the necessery VPN (ptpt) ms encrypted tunnel.

Thanksfully I was able to find a way to do the same tunnel on my Debian Linux, after a bunch of experimentation with the ppp linux command.

To be able to establish the IPMI VPN tunnel, first I had to install a couple of software packages, e.g.:

root@linux:~# apt-get install ppp pppconfig pppoeconf pptp-linux

Further on it was necessery to load up two kernel modules to enable the pptp mppe support:

root@linux:~# modprobe ppp_mppe
root@linux:~# modprobe ppp-deflate

I’ve also enabled the modules to be loading up during my next Linux boot with /etc/modules to not be bother to load up the same modules after reboot manually:

root@linux:~# echo ppp_mppe >> /etc/modules
root@linux:~# echo ppp-deflate >> /etc/modules

Another thing I had to do is to enable the require-mppe-128 option in /etc/ppp/options.pptp.
Here is how:

root@linux:~# sed -e 's$#require-mppe-128$require-mppe-128$g' /etc/ppp/options.pptp >> /tmp/options.pptp
root@linux:~# mv /tmp/options.pptp /etc/ppp/options.pptp
root@linux:~# echo 'nodefaultroute' >> /etc/ppp/options.pptp

In order to enable debug log for the ppp tunnel I also edited /etc/syslog.conf and included the following configuration inside:

root@linux:~# vim /etc/syslog.conf
*.=debug;
news.none;mail.none -/var/log/debug
*.=debug;*.=info;
*.=debug;*.=info;
root@linux:~# killall -HUP rsyslogd

The most important part of course is the command line with ppp command to connect to the remote IP via the VPN tunnel ;), here is how I achieved that:

root@linux:~# pppd debug require-mppe pty "pptp ipmiuk2.net --nolaunchpppd" file /etc/ppp/options.pptp user My_Dedi_Isp_Given_Username password The_Isp_Given_Password

This command, brings up the ppp interface and makes the tunnel between my IP and the remote VPN target host.

Info about the tunnel could be observed with command:

ifconfig -a ppp
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.20.254.32 P-t-P:10.20.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:70 (70.0 B) TX bytes:672 (672.0 B)

One more thing before I could finally access the IPMI’s web interface via the private IP was to add routing to the private IP address via the tunnel other side IP address:

# 10.20.0.1 P-t-P IP address
ip route add 10.20.1.124/32 dev ppp0

Now logically one would thing the Web interface to login and use the Java Applet to connect to the server would be accessible but no IT wasn’t !

It took me a while to figure out what is the problem and if not the guys in irc.freenode.net ##networking helped me I would never really find out why http://10.20.1.124/ and https://10.20.1.124/ were inaccessible.

Strangely enough both ports 80 and 443 were opened on 10.20.1.124 and it seems like working, however though I can ping both 10.20.1.124 and 10.20.0.1 there was no possible way to access 10.20.1.124 with TCP traffic.

Routing to the Microsoft Tunnel was fine as I’ve double checked all was fine except whether I tried accessing the IPMI web interface the browser was trying to open the URL and keeps opening like forever.

Thanksfully after a long time of futile try outs, a tip was suggested by a good guy in freenode nick named ne2k

To make the TCP connection in the Microsoft Tunnel work and consequently be able to access the webserver on the remote IPMI host, one needs to change the default MTU set for the ppp0 tunnel interface.
Here is how:


ip link set ppp0 mtu 1438

And tadam! It’s done now IPKVM is accessible via http://10.20.1.124 or https://10.20.1.124 web interface. Horay ! 🙂

Howto remote access Windows PC which is behind Vivacom ADSL (Commtrend SmartAX MT882 router) modem with VNC server

Wednesday, May 11th, 2011

I had been assigned the not easy task to make a Windows XP Pro which is located behind an ADSL modem to be remotely accessible via VNC

The Windows is connected to the Bulgarian Vivacom Intrnet provider through their ADSL service and hence there is an ADSL router modem which is configured to disallow all inbuond connections by default.

The Windows Pro PC where the VNC server was needed to be accessible did not have a real IP address (e.g. was assigned a virtual IP address by the ADSL modem.

The exact ADSL model used to connect the computer via a lan cable to the internet was Huawei SmartAX MT882

As the device is owned by Vivacom (the ex BTK tele communication company) I did not have any admin user and pass credentials for the ADSL modem to configure the ADSL router to do a port NAT forwarding of port 5800 and 5900 used by the VNC software I installed on the PC (TightVNC)

Nevertheless the missing user and password I decided to check in google if I can find some default passwords that Vivacom ADSL modems are configured to work with

After a few minutes spend in Google I already had found few passwords which were said to work fine with the Vivacom ADSL router.
Here are the passwords I found for the Vivacom ADSL Internet modems:

ZTE ZXDSL 832
username: root
password:GSrootaccess

ZTE ZXDSL 831
username:root
password:GSrootaccess

ZTE
username:root
password:831access

Huawei SmartAX MT882
username:root
password:MT882rootaccess

ZTE ZXDSL-531b
username: root
password:warmWLspot

I tried some old school brute force techniques 😉 by trying all the passwords via the ADSL web interface located on http://192.168.1.1 (I was not sure which model the Vivacom ADSL modem is as on the router there was nothing written concerning the modem type but only the Vivacom logo was present.

After a bit of time I already knew that the ADSL modem model, user and pass was:

Huawei SmartAX MT882
-------------------------------
user: root
pass: MT882rootaccess

My next step was to configure port forwarding for the SmartAX MT882 ADSL in order to achieve from modem’s web administrator I had to follow the menus:

Advanced Setup -> Virtual Servers

ADSL virtual servers menu screen

Next in the NAT — Virtual Servers section I pressed the Add button to create new automatic redirection (port forwarding) rule.

Virtual Server port forwarding screenConfiguring ADSL SmartAX MT882 TightVNC NAT port redirection screenTightVNC requires also NAT port redirection rule for port 5900 in order to be able to connect to the VNC server behind the dsl, so analogically I added a Virtual Server NAT rule for port 5900.

Note that the private IP address of the Windows host was assigned by the ADSL router to the ip 192.168.1.3

Further on I expected the adsl port forwarding created rule would now allow me to connect to the VNC server on the pc located behind the dsl firewall, but I was wrong… even though all seemed to be configured just fine in the ADSL router still the port unmbers 5800 and 5900 were showing up as closed during nmap scan as well as a simple telnet connection to port 5800 and 5900 failed to get established.

My logical assumption was that some configured Firewall on the Windows PC is blocking port connections to 5800 and 5900 thus I decided to check the default Windows Firewall settings as a first possible cause for the vnc ports being blocked.

I did that via the Windows menus:

Start -> Settings -> Control Panel -> Windows Firewall

However weirly enought it seemed the Windows Firewall was disabled e.g. the Off (not recommended) option was set for the firewall.

A bunch of other lookup over all the running system and services on the windows hosts I have found the PC is protected by NOD32 Antivirus – Personal Firewall

The default behaviour of NOD32’s Persnal firewall was extremely restrictive and I found it’s causing a port filter of the 5800 and 5900 vnc connection ports.

To solve the filtering nod32 did I had to open NOD32 and navigate to the following menus:

Setup -> Personal Firewall -> Configure rules and Zones

In the Zone and rule setup menu config window I had to further press on:
New button to add new personal firewall rule.

In the New rule: menu I filled in the following info:
In the General tab:

Name: vnc
Direction: Both
Action: Allow

In the tab Local

I pressed over the Add Port

Number: 5800

in the Remote tab once again I had to fill in:
Number: 5800

Then to confirm settings just pressed OK

Next on I added in the same manner an allow rule for port 5900.

After this settings I restarted the NOD32 firewall to make sure the new settings takes place by pressing over the Personal firewall button Disable filtering: allow all traffic and right after enabling the firewall once again.

Now remote tightvnc connections to the Windows XP Pro pc works like a charm once again, Thanks God 😉