Menu
▾
▴
#115 Problems with Cisco VPN client and CoLinux ethertap
Hi all,
I noticed a problem with the Cisco VPN client and CoLinux ethertap.
My Colinux has two virtual devices:
1) A slirpd (this is used for Internet/Default GW)
2) A tun/tap devices (used for speeding up X11)
After I installed the Cisco VPN Client for Windows XP (32bit) I have some troubles. This goes away after deinstalling the VPN Client.
My ethertap device has the IP 192.168.55.40 inside CoLinux and 192.168.55.1 on the windows side. The strange thing is i can ping the 192.168.55.40 IP from windows, but the Colinux side can't ping anymore the 192.168.55.1 Windows IP. That is strange. I can also ssh in Colinux using the 192.168.55.40 IP.
Any ideas? Is this a ethertap problem?
Bye and happy hacking.
Logged In: YES
user_id=579204
Originator: NO
Does VPN cliend perhaps enable a firewall for the tap on Windows side?
Logged In: NO
Hi!
Maybe I have an idea about this problem. If you install Cisco VPN Client for Windows XP, it also installs parts of the ZoneAlarm-Firewall as the intern firewall of the VPN client, as I remember. If you have a firewall installed on Windows (not ZoneAlarm), this situation can cause many problems, because the ZoneAlarm-Firewall sometimes activates itself for whole Windows and not only for the VPN-Connection. It can go so far that you have no more network connection any more because ZoneAlarm is blocking all connection.
The only possibility you have, is searching the ZoneAlarm-Firewall driver in your system32-directory (a .sys file) and deactivate it in registry. If you have done this, and after an reboot, you can delete the driver and all other dll's from ZoneAlarm.
Cisco VPN-Client is still working, but you should not have problems any more.
Another advice with using Cisco VPN-Client and Colinux is, not using tun/tap on colinux while activating the VPN-tunnel, because you are loosing all your connections between Windows and Colinux over this connection. If you only use slirpd, everything works well.
Bye
This problem is indeed fixed by disabling the stateful firewall in the (UCLA) Cisco VPN Client via Options->Stateful Firewall (always on).
last comment give the resolution. Close this now.