Yes, Erich you are probably right. The default on the laptop would not go through the tunnel (from laptop to homefw.) But key issue: when I ping 192.168.10.13 from the home firewall, I also cannot get through. So something else needs to be done that I don't understanding at this point.
Rick. -----Original Message----- From: Erich Titl [mailto:[EMAIL PROTECTED] Sent: Saturday, December 18, 2004 6:05 PM To: Tibbs, Richard Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Openvpn problems -- again.. Tibbs, Richard wrote: >I am not sure the laptop needs a route to 192.168.10.0. >In fact, although the tunnel between homefw and officefw is "working" -- >I can ping either end of the tunnel IPs (10.1.10.1,2) from the other -- >I can't get access to the individual subnets. > >Although there is no route to 192.168.10 on the laptop, > How will the laptop route 192.168.10.0. If there is no distinct route it will take the default route which might not go through the tunnel. >the home >firewall has a route in its route table for that subnet (see below). > > >So, >the default route of the laptop takes over for those packets, and home >fw table sends them on the tunnel to office fw. > > Yes, but the default route might not go through the tunnel. >See the ping from the winxp box way at the bottom, the opposite end of >the tunnel at office fw says destination unreachable. Yet obviously >192.168.10.0 is a directly connected net to office fw. > >... >I have been following >www.shorewall.net/openvpn.html >Unfortunately that page uses a route-up script that is not displayed. So >I am guessing the config should be: > >office openvpn.conf >dev tun ># For compatability with 2.x openvpn clients/servers >tun-mtu 1500 >tun-mtu-extra 32 >mssfix 1450 >port 50001 >disable-occ >local 137.p.q.190 ># Remote peer >remote 216.x.y.89 >ifconfig 10.1.10.2 10.1.10.1 >route 192.168.1.0 255.255.255.0 ># Our pre-shared static key >secret static.key >verb 5 >mute 10 > >The route directive is what I assume the upscript does. This makes the >office route table: ># ip route sho >10.1.10.1 dev tun0 proto kernel scope link src 10.1.10.2 >192.168.1.0/24 via 10.1.10.1 dev tun0 >192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.254 >137.p.q.0/24 dev eth0 proto kernel scope link src 137.p.q.190 >137.p.q.0/24 dev ipsec0 proto kernel scope link src 137.p.q.190 >default via 137.p.q.55 dev eth0 > >on the home fw, the route directive is >route 192.168.10.0 255.255.255.0 > > This will cover the route to the office. Don't you need a route through the second tunnel to reach your laptop. Else the routing will be done outside your tunnel. > >=========================== Shorewall config ==================== ># more zones >#ZONE DISPLAY COMMENTS >net Net Internet >loc Local Local Networks >vpn1 VPN-1 Remote Subnet for IPsec Road Warrior >vpn3 VPN-3 Openvpn sub to sub >#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > >firewall: -root- ># more interfaces >#ZONE INTERFACE BROADCAST OPTIONS >net eth0 detect norfc1918 >loc eth1 detect >#loc usb0 >vpn1 ipsec0 >vpn3 tun0 >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > >firewall: -root- ># more policy >loc vpn1 ACCEPT >fw vpn3 ACCEPT >loc vpn3 ACCEPT >net vpn3 ACCEPT >vpn1 loc ACCEPT >vpn3 loc ACCEPT >vpn3 net ACCEPT >vpn3 fw ACCEPT >net all DROP ULOG >all all REJECT ULOG >#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > >tunnels: ># TYPE ZONE GATEWAY GATEWAY ZONE PORT >ipsec net 0.0.0.0/0 vpn1 >openvpn:50001 net 216.x.y.89 vpn3 >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > >=========================== from winxp =========================== >ping 192.168.10.13 > >Pinging 192.168.10.13 with 32 bytes of data: > >Reply from 10.1.10.2: Destination host unreachable. >Reply from 10.1.10.2: Destination host unreachable. >Reply from 10.1.10.2: Destination host unreachable. > > If I read this correctly, then the tunnel endpoint in your office does not know the way to the office network or rejects the packets with icmp host unreachable. Any entries in the log files? Try to trace the path of your packets using tcpdump, then you will see exactly where they enter and exit the tunnels and if they use the tunnels at all. cheers Erich ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
