Frode Marton Meling wrote: >>> >> Strange... I tried with same settings as you, but I only get access to >> endians interface on Green interface. >> if I ping another server on Green I get: >> From 192.168.3.60 icmp_seq=1 Destination Host Unreachable >> From 192.168.3.60 icmp_seq=2 Destination Host Unreachable >> >> And it looks like my routing information is updated also. A route >> command says: >> 192.168.3.0 * 255.255.255.0 U 0 0 0 tap0 >> 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 >> default 192.168.3.1 0.0.0.0 UG 0 0 0 tap0 >> And 3.1 is my endian firewall.. >> >> PS! my klient is standard installed Kubuntu edgy 6.10 install. >> >>
I'm not a networking expert or anything [lucky when it gets down to this kind of problem I can pass off to a friend of mine who is] but the basic idea of how this is working is.... OpenVPN makes a tap devices when you connect to Endian that tap [/dev/tap1] is connected to the bridge device [/dev/br0] of the green network. The Bridge sees all traffic that passes across the ethernet interface [eth0]. So when a packet that is for the openvpn client hits the br0 device it gets forwarded to the tap1 device and down the tunnel to you. [This works because Endian is setup to forward packets like a router.] Knowing that how you can do a little debugging with tcpdump. First connect from your client into Endian. Then ssh into endian as root start a tcpdump like so tcpdump -i br0 | grep '<vpnclient>' where vpnclient is either the IP address or the hostname if you have /etc/hosts entries that will translate this. Now ping from the Client into the network. You should see traffic ICMP request and replies. If you see only requests it means the ping goes out the bridge but never makes it back. If you have a Unix box on the green network you can tcpdump on it also grepping for the vpnclient and see if the traffic makes it that far or not. Another useful thing to check is the ARP cache. On your client you can type "Arp -a" to see if you have the MAC address of the host you are trying to ping. You should, if not then the arp reply never got back down the tunnel. You can arp -a on endian also to see the arp address of the tap IP. With that information you can at least make guess as to what is going on. In my case we see the traffic going out the bridge and getting to the host in the green network, and the traffic leaving the host in the green network but never making it back to Endian. [Tcpdump puts your device into promiscuous mode so all traffic on the line is shown.] So I'm pretty sure that Endian is not the problem and something in the internal network is messing things up. Hope that helps, like I said when we solve this I'll post it however it is likely to be an obscure problem related to Cisco Switches. -Mike ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Efw-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/efw-user
