Interesting, from which computer/os did you do the scan? I assume the OSes that are affected (Mageia and Mdk2010).

I'm starting to wonder if there is a routing problem...

With the above assumption in mind, could you try This should force the scan through your virtual hamachi interface.

The scan was done on the (local) Mageia.

Below showing ham0 portion of ifconfig and nmap changes:

When hamachi first initialised,

ham0 Link encap:Ethernet HWaddr 7A:79:19:C73:03
inet6 addr: fe80::7879:19ff:fec7:d303/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1404 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:1836 (1.7 KiB)

# nmap 25.199.211.3 -Pn -e ham0
Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-18 10:20 NZDT
I cannot figure out what source address to use for device ham0, does it even exist?
QUITTING!

Running command: # hamachi set-ip-mode ipv6

ham0 Link encap:Ethernet HWaddr 7A:79:19:C73:03
inet6 addr: fe80::7879:19ff:fec7:d303/64 Scope:Link
inet6 addr: 2620:9b::19c7:d303/96 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1404 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:2688 (2.6 KiB)

Running command: # hamachi set-ip-mode ipv4

ham0 Link encap:Ethernet HWaddr 7A:79:19:C73:03
inet addr:25.199.211.3 Bcast:25.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::7879:19ff:fec7:d303/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1404 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:2778 (2.7 KiB)

# nmap 25.199.211.3 -Pn -e ham0
Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-18 10:21 NZDT
Nmap scan report for 25.199.211.3
Host is up (0.000018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
631/tcp open ipp
Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds

Interesting and it's not showing vnc ports. You said firewall is down and the remote machine you're trying to connect to is XP, right?

Sure doesn't sound like a routing problem so I'm wrong on that.

Wait!? You're scanning your host??? The ip shown for ham0 after the hamachi ipv4 config is the same as the ip in the scan...have you tried scanning the machine you want to connect to?

To confirm the remote machine is XP, disabled firewall.

How's this?

# nmap 25.7.69.187 -Pn -e ham0

Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-18 18:21 NZDT
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:113 S ttl=43 id=7096 iplen=44 seq=27666763 win=4096 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:587 S ttl=53 id=56449 iplen=44 seq=27666763 win=2048 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:1723 S ttl=49 id=28743 iplen=44 seq=27666763 win=2048 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:443 S ttl=51 id=55187 iplen=44 seq=27666763 win=4096 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:110 S ttl=55 id=12207 iplen=44 seq=27666763 win=4096 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:22 S ttl=59 id=1544 iplen=44 seq=27666763 win=4096 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:199 S ttl=50 id=12275 iplen=44 seq=27666763 win=3072 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:80 S ttl=59 id=19214 iplen=44 seq=27666763 win=4096 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:8080 S ttl=46 id=19705 iplen=44 seq=27666763 win=3072 <mss 1460>
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 25.7.69.187, 16) => Operation not permitted
Offending packet: TCP 25.199.211.3:51851 > 25.7.69.187:5900 S ttl=55 id=31755 iplen=44 seq=27666763 win=4096 <mss 1460>
Omitting future Sendto error messages now that 10 have been shown. Use -d2 if you really want to see them.
Nmap scan report for 25.7.69.187
Host is up (0.000093s latency).
All 1000 scanned ports on 25.7.69.187 are filtered
MAC Address: 7A:79:19:07:45:BB (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 21.54 seconds

I cannot run nmap on Mdk2007 with -Pn -e (not valid on old version)

a quick google search yielded me this: http://seclists.org/nmap-dev/2005/q2/34

I know you mentioned that firewall is off for the remote machine but is iptables running on your client (Mageia or Mdk)?

# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:1900
ACCEPT tcp -- anywhere anywhere tcp dpt:1900
ACCEPT udp -- 192.168.1.75 anywhere udp dpt:1900
ACCEPT tcp -- 192.168.1.75 anywhere tcp dpt:1900
ACCEPT tcp -- 192.168.1.1 anywhere tcpflags:! FIN,SYN,RST,ACK/SYN
ACCEPT udp -- 192.168.1.1 anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
DROP all -- base-address.mcast.net/8 anywhere
DROP all -- anywhere base-address.mcast.net/8
DROP all -- 255.255.255.255 anywhere
DROP all -- anywhere default
DROP all -- anywhere anywhere state INVALID
LSI all -f anywhere anywhere limit: avg 10/min burst 5
INBOUND all -- anywhere anywhere
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix "Unknown Input"

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix "Unknown Forward"

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 192.168.1.4 192.168.1.1 tcp dpt:domain
ACCEPT udp -- 192.168.1.4 192.168.1.1 udp dpt:domain
ACCEPT all -- anywhere anywhere
DROP all -- base-address.mcast.net/8 anywhere
DROP all -- anywhere base-address.mcast.net/8
DROP all -- 255.255.255.255 anywhere
DROP all -- anywhere default
DROP all -- anywhere anywhere state INVALID
OUTBOUND all -- anywhere anywhere
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix "Unknown Output"

Chain INBOUND (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 192.168.1.75 anywhere
ACCEPT all -- 192.168.1.75 anywhere
ACCEPT all -- 192.168.1.75 anywhere
ACCEPT all -- 192.168.1.71 anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT udp -- anywhere anywhere udp dpt:www
LSI all -- anywhere anywhere

Chain LOG_FILTER (5 references)
target prot opt source destination

Chain LSI (2 references)
target prot opt source destination
LOG_FILTER all -- anywhere anywhere
LOG tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix "Inbound "
DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix "Inbound "
DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST
LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix "Inbound "
DROP icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix "Inbound "
DROP all -- anywhere anywhere

Chain LSO (0 references)
target prot opt source destination
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix "Outbound "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain OUTBOUND (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere

Sorry for my delayed reply. I don't know how relevant this is to resolving the vpn problem but with regards to the nmap issue I see that in your iptables you are rejecting all invalid...
However with that said I wonder if hamachi is doing this to connect to the VPN...idk. Do you have experience with Ethereal (Wireshark)?

Also is there a support forum for hamachi? and have you tried posting there? Sorry to not have a solution but this is very bizarre. I can keep coming up with ideas to diagnose the problem but I am not sure if we are going anywhere nor do I want to mislead you.

Thanks Ken. I did iptables -L on Mdk2007, and DROP does not show anywhere - everything appears "anywhere anywhere".

I have no experience with Ethereal (Wireshark) and obviously don't understand iptables. Somewhere I read that the iptables file is in /etc/sysconfig/ - it is not. I had a look at forums for hamachi - they seemed to be Windows games orientated.

Sometime ago (March 25 by coincidence) I had trouble getting miniDLNA to pass the firewall(s) and was advised to edit /usr/share/shorewall/action.Drop (and action.Reject) remming DropUPnP in each. Looking in the two files I saw dropInvalid and dropNotSyn. When I remmed these (in both files) and rebooted, vncviewer asked for a password, and I could see the remote desktop!!!

To check which one was responsible, I unremmed each in turn, and then remmed both in both files (as had been successful in last para) - never to see the remote desktop again!!

I wonder if my experiment descibed in the third para above is a clue to what is blocking my attempts to see the remote desktop. I "broke" something momentarily when I edited /usr/share/shorewall/action.Drop (and action.Reject) to allow me access, only to be healed by some other function.

A firewall problem would make sense but I'm not familiar with ShoreWall. However with that said I would be happy to take a look at your shorewall configuration. Do you see anything that may be the problem? Do you know what ports the VPN client/server uses? I'm still puzzeled by the INVALID packets error which may be our clue...in which case could you do
to see if the interface has the correct routing table?

Thank you Ken for your reply

[root@localhost john]# route -n
Kernel IP routing table
Destination --- Gateway --- Genmask --- Flags--- Metric--- Ref --- Use--- Iface
192.168.1.0 --- 0.0.0.0 --- 255.255.255.0 --- U --- 10 --- 0 --- 0--- eth0
169.254.0.0 --- 0.0.0.0 --- 255.255.0.0 --- U --- 10 --- 0 --- 0--- eth0
127.0.0.0 --- 0.0.0.0 --- 255.0.0.0 --- U --- 0 --- 0 --- 0 ---lo
0.0.0.0 --- 192.168.1.1 --- 0.0.0.0 --- UG --- 10 --- 0 --- 0--- eth0

If I do route -n on Mdk2007 I get an extra line (not present on the non functioning system):

25.0.0.0 --- 0.0.0.0 --- 255.0.0.0 --- U --- 0 --- 0 --- 0--- ham0

which relates with the hamachi 25.7.69.187 address(?)

ifconfig contains:

ham0 Link encap:Ethernet HWaddr 7A:79:19:C73:03
inet6 addr: fe80::7879:19ff:fec7:d303/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1404 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:2178 (2.1 KiB)


/etc/Shorewall.conf
# Shorewall Version 4 -- /etc/shorewall/shorewall.conf
#
# For information about the settings in this file, type "man shorewall.conf"
#
# Manpage also online at http://www.shorewall.net/manpages/shorewall.conf.html
#############################
# S T A R T U P E N A B L E D
#############################

STARTUP_ENABLED=Yes

##############################
# V E R B O S I T Y
##############################
VERBOSITY=1

#############################
# L O G G I N G
#############################
LOGFILE=/var/log/messages
STARTUP_LOG=/var/log/shorewall-init.log
LOG_VERBOSITY=2
LOGFORMAT="Shorewall:%s:%s:"
LOGTAGONLY=No
LOGLIMIT=
LOGALLNEW=
BLACKLIST_LOGLEVEL=
MACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
LOG_MARTIANS=Yes

######################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
#######################################
IPTABLES=
IP=
TC=
IPSET=
PERL=/usr/bin/perl
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHOREWALL_SHELL=/bin/dash
SUBSYSLOCK=/var/lock/subsys/shorewall
MODULESDIR=
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
RESTOREFILE=
IPSECFILE=zones
LOCKFILE=

###########################################
# D E F A U L T A C T I O N S / M A C R O S
###########################################
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"

#########################################
# R S H / R C P C O M M A N D S
#########################################
RSH_COMMAND='ssh ${root}@${system} ${command}'
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'

##########################################
# F I R E W A L L O P T I O N S
##########################################
IP_FORWARDING=Keep
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
RETAIN_ALIASES=No
TC_ENABLED=
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
CLEAR_TC=Yes
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=No
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=No
MUTEX_TIMEOUT=60
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
MODULE_SUFFIX="ko ko.gz"
DISABLE_IPV6=No
DYNAMIC_ZONES=No
PKTTYPE=Yes
NULL_ROUTE_RFC1918=No
MACLIST_TABLE=filter
MACLIST_TTL=
SAVE_IPSETS=No
MAPOLDACTIONS=No
FASTACCEPT=No
IMPLICIT_CONTINUE=No
HIGH_ROUTE_MARKS=No
OPTIMIZE=1
EXPORTPARAMS=No
EXPAND_POLICIES=Yes
KEEP_RT_TABLES=No
DELETE_THEN_ADD=Yes
MULTICAST=No
DONT_LOAD=
AUTO_COMMENT=Yes
MANGLE_ENABLED=Yes
USE_DEFAULT_RT=No
RESTORE_DEFAULT_ROUTE=Yes
AUTOMAKE=No
WIDE_TC_MARKS=No
TRACK_PROVIDERS=No
ZONE2ZONE=2
ACCOUNTING=Yes
DYNAMIC_BLACKLIST=Yes
OPTIMIZE_ACCOUNTING=No
LOAD_HELPERS_ONLY=No
REQUIRE_INTERFACE=No
FORWARD_CLEAR_MARK=
COMPLETE=No
EXPORTMODULES=Yes

#########################################
# P A C K E T D I S P O S I T I O N
#########################################
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE

Aha! It doesn't know where to route the packets...give this a try:
Actually before you try this see my Edit 2...the gateway being 0.0.0.0 perplexes me...
Remind me, the Mdk 2007 works with hamachi, right?

Edit: Interestingly I came across this which says to make the gateway the ip address of your target machine, makes more sense than 0.0.0.0
http://community.spiceworks.com/how_...n-with-hamachi
Hmm :/

Edit 2: This article may be helpful (see very bottom)
http://dougmelton.com/other-fun-stuf...hiubuntuhowto/

# route add -net 25.0.0.0 netmask 255.0.0.0 gw 0.0.0.0
SIOCADDRT: Invalid argument

Just in case, I tried (to emulate the code in the reference):

# route add -net 25.0.0.0 gw 25.7.69.187 netmask 255.0.0.0 dev ham0
SIOCADDRT: No such process

If I do "hamachi list" before starting the remote desktop:
# hamachi list
* [mageia-1] capacity: 2/5, subscription type: Free, owner: This computer
119-146-270 --- laptop --- 25.7.69.187 alias: not set

If I do "hamachi list" after starting the remote desktop:
# hamachi list
* [mageia-1] capacity: 2/5, subscription type: Free, owner: This computer
119-146-270 --- laptop --- 25.7.69.187 --- alias: not set --- 2620:9b::1907:45b --- direct --- UDP --- 192.168.1.9:1028

25.7.69.187 and 2620:9b::1907:45b are the address(es) of the remote laptop


And Yes, Hamachi + vncviewer work perfectly on Mdk2007.

Hamachi appears to be doing what it should on Mageia, ie Mageia is recognising the remote XP laptop jusl like Mdk2007 does, and the laptop recognises the presence of Mageia. It is vncviewer that cannot connect through hamachi on Mageia (except on the one occasion described 25 December).

Hmm well from my understanding ipv4 and ipv6 are incompatible...I know we looked into this earlier but there must be a way to use only one. I assume you've tried setting ip mode of hamachi to ipv4 and still wouldn't connect. Would changing the IPV6 disable setting in shorewall to YES and the ip mode setting for hamachi ipv4 resolve the issue???? I'll keep looking through the firewall config and think of other possible solutions.

Yes, I have tried hamachi in ipv4 (and ipv6 modes). I changed the IPV6 disable setting in shorewall to YES and set hamachi to ipv4, but no go.

I desparation, I did "shorewall stop" and "vncviewer" and I could see the remote desktop. Great! I then killed vncviewer, restarted shorewall. "vncviewer" again let me see the remote desktop. Again Great.

I rebooted to confirm, but could not get a vncviewer connection whether shorewall was stopped or running. (Starting shorewall reported "iptables: Input/output error." six times).